#Roadmap, Team and Budget

TL;DR

• This is the only document in the deliverable that carries timeline and money. Every date, headcount, EUR figure, eng-month and gate metric lives here. Sibling docs describe what we build (02 — System architecture, 03 — Hardware, peripherals and the device fleet, 04 — Payments, fiscalisation, privacy and security, 05 — The CRM Product and Scope Tiers, 06 — Integrations); if one of them states a date or a cost, this file overrides it.
• S1 is 5 engineers over 36 months on EUR 1.8–2.4M, not 3 engineers over 24 months on EUR 900k. Reconciled scope is 125 eng-months for the S1-cut v1 against ~126 eng-months of realistic S1 capacity. There is no slack. Starting 2026-09-01: MVP Feb 2028 (M17), v1 sellable Apr 2029 (M31), 40–60 paying CZ Sites at that gate.
• Two numbers decide the company, and both are answerable before a line of code: ≥8 of 40 Prague/Brno operators placing a EUR 200 refundable deposit at ≥EUR 89/Site/month (A1), and ≥1 written payments term sheet at ≥25 bps residual with no merchant-ownership clause (A2). Both are due at the P0 exit, 2027-01-31. Neither passing means do not write code.
• Non-engineering headcount is not overhead, it is the product. First support hire at Site #40, field/install person at Site #10, onboarding/menu-build specialist from the first paid install, a named compliance owner from M0. Skipping any of these is how the founder becomes the Saturday-night pager and engineering velocity goes to zero at ~60 Sites.
• Cost per Site to sell and turn on is EUR 2,750–4,600 all-in (CAC EUR 2,200–3,200 + install EUR 550–1,400), against EUR 110–130/Site/month of subscription revenue (POS+CRM+KDS, canon §5.4). That is a 21–35 month payback on SaaS alone. Payments residual is what makes it 8–14 months, which is why A2 is a stop-gate, not a nice-to-have.
• Peak capital through M47 is EUR 1.8–2.4M; capital to breakeven is EUR 3.0–3.5M over 5–7 years and ~800 Sites. These are two different numbers and only the first one is usually quoted. On the mid case cumulative net burn is ~EUR 2.44M at M47 (Aug 2030) — at the ceiling of canon's band, not inside it — and FY5 is now modelled (§7.1–§7.2): M59 exits at ~320 Sites and ~EUR 749k ARR, still burning ~EUR 481k/year, ~EUR 2.92M cumulative. M47 is a financing event, not an exit; §7.4 names the three end states. Say this to investors before they model it themselves.

#1. The calendar

Start date: 2026-09-01 = M0. Month index → calendar month, used identically in every table below.

Fiscal years in this document run Sep→Aug: FY1 = M0–M11, FY2 = M12–M23, FY3 = M24–M35, FY4 = M36–M47, FY5 = M48–M59 (modelled in §7.1–§7.2 because the capital question is not answerable without it).

#2. Phase plan

Phase names, durations, cumulative eng-months and exit-gate criteria are canonical and reproduced verbatim. Costs, headcounts and "what we learn" are derived here.

#P0 — Foundations · S1 M0–M4 (Sep 2026 – Jan 2027) · S2 M0–M3

#P1 — Design-partner pilot · S1 M5–M17 (Feb 2027 – Feb 2028) · S2 M4–M9

#P2 — First paying market, Czechia · S1 M18–M31 (Mar 2028 – Apr 2029) · S2 M10–M18

#P3 — Second market + payments attach · S1 M32–M46 (May 2029 – Jul 2030) · S2 M19–M30

#P4 — Scale or sell · S1 M47+ (Aug 2030+) · S2 M31+

Hard stops, any phase, any time: a fiscal or tax defect that causes a Customer to be fined · a breach of Guest PII · two consecutive quarters in which support headcount grows faster than Site count.

#3. Milestone table (start 2026-09-01)

#4. Reconciled engineering effort per domain

Canonical (canon §5.1), reproduced verbatim. Double-counting between the nine appendices is removed and the critics' upward revisions are applied. Do not re-derive these; do not add appendix headlines to them.

Two rows moved after this table was first reconciled, and both are carried here rather than hidden: Domain C Full is 36.5, not 35.0, because in-app staff self-onboarding (1.5) was funded into v1 Full as the named A20 mitigation — deferred in the S1 cut, so the 125 is unchanged; Domain I post-v1 is +10.5, not +9.0, because the HubRise-resold delivery module moved to v3 while the Ukrainian migration importers stayed in v2 core (06 — Integrations §2.2). Full therefore totals 168.5 and full v2 +96.5.

The "full v2 delta (S2)" column is full v2 — the S2/Full figure. S1's P3 ships v2 core at 58–65 eng-months (63.5 modelled) and defers the rest to v3; the per-domain split of the +86.5 is in §5.1.1, and it is the only place in this document where the canonical column is decomposed.

AI-assist multipliers are already baked in above and are stated per domain so nobody re-applies them: D ≈ 1.25× · A ≈ 1.10× · B ≈ 1.50× · C ≈ 1.35× · E/F/G legal-and-correctness rows ≈ 1.0–1.10×. Certification queues, field sales, physical install, RMA logistics and trust compress by 0%.

#5. Eng-months → calendar time, honestly

#5.1 S1 — bootstrapped

Effective engineering capacity is 3.5 eng-FTE average after a 15–25% on-call tax from 150 Sites onward → **42 eng-months/year, ~126 over 36 months**. That is the whole budget. The S1-cut v1 is 125.

The founder contributes 0.4 eng-FTE, not 1.0. Five headcount engineers from M13 net out to 4.9 effective in P2 and 4.3 in P3 because of on-call, interviews, install-day escalations and the fact that the person who wrote the fold is the person the restaurant reaches at 21:40 on a Saturday. [estimate]

Why the brief's S1 fails arithmetically: 3 engineers × 24 months at 3.5 effective FTE is ~84 eng-months against a 125 eng-month v1. The gap is 41 eng-months — more than the entire MVP client-app domain. There are exactly three honest resolutions and canon picks the first: (a) 5 engineers over 36 months on EUR 1.8–2.4M; (b) POS-only with no CRM beyond a loyalty ledger; (c) first-party ordering + loyalty for delivery-heavy concepts as a wedge. (b) and (c) are not the product in this brief.

#5.1.1 What P3 actually fits: v2 core vs v3

P3 has 65 eng-months of S1 capacity (M32–M46, above). Canon's full v2 delta is +86.5 → +96.5. Full v2 does not fit and never did; the reconciliation is not a re-estimate, it is a scope split. Canon §4's v2 tier is split into v2 core — what P3 ships — and v3 — P4 and later. [estimate] on every per-domain line below; only the canon column is canonical.

63.5 modelled against 65 available. That leaves 1.5 eng-months of contingency, which is not enough — the two country-entry queues (A12 GUM homologation, A13 PRRO certification) compress by 0% and are historically where this class of plan slips. This is a real and stated thinness, not a rounding artefact: it appeared when Domain I was restated from +9.0 to +10.5 after the HubRise-resold delivery module moved to v3 and the three Ukrainian migration importers — Poster, r_keeper, iiko/Syrve, which are how Ukraine entry actually wins Sites — were costed properly by 06 — Integrations §2.2. The named contingency lever, to be pulled at the P3 planning gate and not silently: defer the r_keeper importer (1.5) to v3, restoring ~3 eng-months of float, because it is the least load-bearing of the three (r_keeper's CEE installed base is the oldest and the most likely to be replaced rather than migrated). Canon's 190 cumulative at P3 exit is capacity, and it stands; cumulative scoped work is 188.5.

Three consequences a reader should not have to derive:

1. The +86.5 → +96.5 delta is not deleted. It is re-labelled: it is the full v2 figure and it is the S2/Full number. S2's P3 (M19–M30, 12 months at ~11 eng-FTE ≈ 132 eng-months) carries it whole in the same phase, on top of a v1 that already shipped Full.
2. The S1 cut is repaid where v2 core depends on it, and only there. Five of canon's "Full only" P2 deferrals are pulled into P3 at ~10 eng-months because v2 core cannot ship without them — the injected-fault simulator suite (T2 LAN), the segmentation query-builder UI and the multi-channel adapters (WhatsApp/Viber, journeys), the residual/margin ledger (payments attach, and the M18 gate already calls out its absence), and Polish i18n (Poland entry). The rest stay deferred, including in-app staff self-onboarding unless A20 pulls it forward (§10).
3. What was cut is the full-service product, not the growth engine. Table service and the handheld waiter app serve a different ICP than canon §1's counter-service-only, single-station-first shape and cannot be funded before the counter-service base is at 150 Sites. P3's exit gate turns on Site count and on identity capture / CRM renewal, and both are kept: T2 LAN plus the two second markets carry the Sites, guest ordering + QR PWA + Wallet passes carry identity capture from v1's 30–38% (A4 true) toward **52% (v2 core)**. Cutting either of those would break a thesis this deliverable states as proven elsewhere; cutting full-service does not.

#5.2 S2 — funded

Effective capacity 11 eng-FTE → ~132 eng-months/year, i.e. 11/month once ramped.

S2 buys 9 months of calendar, not a different product. The MVP arrives 8 months earlier and the Full v1 13 months earlier; the compliance queues, the install day, the sales meeting and the Saturday escalation are identical.

#6. Org chart per phase

Loaded monthly cost per role. "Loaded" = gross + CZ employer contributions (24.8% social + 9.0% health [known]) or the UA contractor equivalent.

#6.1 S1 headcount by phase

On the P0 engineer count: this table starts P0 at 2→3 engineers, not canon §5.2's "3 rising to 5 by M13". The 2→3 ramp is what the hiring reality of A15 (two senior Kotlin engineers signed by M2) actually supports, and P0's 14 eng-months are computed off it in §5.1. Canon §5.2 is being amended to "2 engineers at M0 rising to 3 by P0 exit and 5 by M13"; this document is the source for the ramp.

The four non-engineering roles a POS company cannot skip, and what happens if you do:

#6.2 S2 headcount

Canonical: 22 → 34 → 55 across FY1–FY3. 13 product engineers + 2 designers + 1 QA + field ops + sales + support at the P1 mark, growing sales and support roughly 2× per year thereafter. The engineering core is the same size as S1's twice over; the delta beyond that is entirely go-to-market and support, which is the correct shape — S2 is not buying a better product, it is buying nine months and a second country.

#7. Five-year P&L sketch — S1 (bootstrapped)

All figures EUR thousands. [estimate] throughout unless the line is a canon §5.4 input, which is marked.

#7.1 Site and revenue ramp

The third row is not canon's ARPU and must never be quoted as one. Canon §5.4's EUR 110–130/Site/mo is subscription only — POS + CRM + KDS. The row above is total recurring revenue per Site: subscription plus KDS Stations beyond the first, plus messaging, plus the payments residual that canon §5.4 lists separately (PL EUR 1,620/Site/yr, DE EUR 670). FY4's EUR 180 is therefore not a 38% breach of a EUR 130 ceiling; it is EUR 115–125 of subscription plus ~EUR 35 of residual plus messaging and KDS attach. Any deck slide that shortens it to "blended ARPU EUR 180" is misquoting canon.

FY5 is modelled because the capital question is not answerable without it (§13 row 5). It re-forecasts nothing upward: Site growth slows to ~1.45×/year (220 → 320), per-Site recurring revenue rises EUR 180 → 195 on payments attach alone, and new-Site hardware volume falls with the slower ramp. On these numbers the mid case reaches canon's EUR 550–750k band only in FY5 — roughly a year later than canon's M44–M48 window (§7.4).

Payments residual assumes EUR 1,200/Site/year net at ~45 bps on ~EUR 262k of CZ card volume per Site [estimate], anchored against canon's verified Poland figure of EUR 1,620 and Germany EUR 670. Attach begins at M32 (P3), reaching 35% blended in FY4 — inside canon's 30–40% Y3 band, and capped by A21 (36–48-month terminal leases with EUR 300–900 early-termination fees on displacement wins).

#7.2 Cost and burn

Hardware gross margin is 12%, not 18%. The pricing rule is canonical — sell at cost + 15% — and cost + 15% is a 13.0% margin on revenue before freight, spares and DOA, so the achievable band after them is 10–13%; 12% is the mid. An 18% blended GM is arithmetically unreachable under the rule. The correction costs ~EUR 19k of FY4 gross profit (329 → 310) and ~EUR 3k/EUR 7k in FY2/FY3, and it pushes mid-case cumulative burn at M47 from EUR 2.41M to EUR 2.44M — i.e. the mid case now sits at the ceiling of canon's EUR 1.8–2.4M peak-capital band, ~EUR 40k through it, rather than inside it. Treat EUR 2.4M as the floor of the ask.

Infrastructure per canon: EUR 6.90–7.90/Site/month at 100 Sites, EUR 5.40–6.80 at 1,000 — 3–8% of revenue, never the constraint. AI spend EUR 0.30–1.50/Site/month steady state plus EUR 0.50–3.00 one-off per onboarding. MDM EUR 5.5/Site/month. Fiscal signing COGS in CZ is zero — that is the entire reason Czechia is the beachhead.

#7.3 Margin structure at FY4 (140 average Sites)

#7.4 The honest sensitivity — this is where the plan is fragile

Canon's S1 Y3 exit ARR of EUR 550–750k is bound to the third year of revenue = M44–M48 (mid-2030) — calendar year 4 from company start, year 3 from the first invoice at M17. Read canon's "Y3" that way and nowhere else. Against that window: this document's mid case, EUR 475k of exit ARR at M47 on 220 Sites, is the modelled base. Canon's EUR 550–750k is the stretch, and it reconciles with canon's own P3 gate of 150–250 Sites only at the top of both bands — 230–280 Sites × EUR 190–225/Site/month of total recurring revenue (not subscription ARPU). Only the high case reaches it inside the window; the mid case reaches it a year late, in FY5.

Say this out loud in the raise. FY5 is now modelled (§7.1–§7.2) and it does not close: the mid case exits M59 at ~320 Sites and ~EUR 749k ARR, still burning ~EUR 481k/year, ~EUR 2.92M cumulative. Canon's EUR 1.8–2.4M is peak capital through M47, not capital to breakeven. Capital to breakeven is EUR 3.0–3.5M over 5–7 years and ~800 Sites. The two reconcile only if Site growth after M46 runs ~2.5×/year at a contribution margin above EUR 60/Site/month; the mid case runs ~1.45×. Probability of reaching Y3 alive: 35–45% [estimate, canon §5.2].

M47 is a financing event, not an exit. There are exactly three end states for S1 and the founder should choose which one is being underwritten before the extension raise, not after:

1. A third financing round. EUR 0.6–0.9M on the low case, EUR 1.0–1.5M to actually reach breakeven, priced off EUR 475–600k of ARR growing under 2×/year. This is the base case and it is a down-round-shaped conversation.
2. A Series A. Requires S2-shaped metrics — EUR 1.2–1.6M ARR, >2×/year growth, channel-sourced logos — which the S1 path does not produce by M47. Do not plan on it.
3. A strategic sale at 3–6× ARR. On EUR 475–600k of ARR that is EUR 1.4–2.9M — roughly the capital invested. A return of capital, not a return on it. The EUR 40–90M outcome in §12 is a years 6–9 event and only exists on the far side of end state 1.

#8. Three-year P&L sketch — S2 (funded)

Cumulative EUR 13–15M over 3 years and Y3 exit ARR EUR 4.5–5.5M, both canonical. The binary event is the financing gate: EUR 15–25M Series A term sheet at M20 (May 2028) on EUR 1.2–1.6M ARR. If that term sheet does not exist, S2 switches immediately to a profitability plan — freeze hiring, one country, EUR 3M ARR at breakeven by M40 (Jan 2030). Probability of reaching Y3 alive: 30–40% [estimate, canon §5.3].

Fiscal signing COGS enters S2's P&L the moment DE/AT appear in the chain: EUR 10–15/register/month [verified in canon] = 15–25% of a EUR 59 ARPU. Price DE at EUR 89–129, never EUR 59.

#9. Go-to-market: the first 20 Customers

Geography: Prague and Brno, two districts first. Segment: counter-service coffee / bakery / fast-casual chains of 2–8 Sites. Job to be done: "I own four cafés, I cannot tell you which of my regulars stopped coming, and I cannot tell you which of my four managers is discounting." Reference density beats reference count — 15 Sites in Prague 7 outsells 15 scattered nationally, because restaurateurs ask their neighbours and because the installer's travel time collapses.

Restaurants switch POS at exactly four moments. Build the entire Y1–Y2 pipeline on the first and third.

The funnel to 20, and what it costs [estimate throughout]:

Two line items nobody models and both belong in CAC: buying out the incumbent's remaining contract term (CZK 3,000–15,000 = EUR 120–610) and absorbing the 15–25% of signed deals that never go live. Canon's fully-loaded CAC of EUR 2,200–3,200 already contains both.

What the first 20 are sold on, in order: (1) the Dotypos migration importer — "you keep three years of history, it is a 30-minute step"; (2) holdout-based incremental revenue at renewal — a number no CEE competitor can produce; (3) offline: "orders, kitchen, cash and receipts keep working with no internet; card payments depend on your acquirer." Never claim store-and-forward card. See 05 — The CRM Product and Scope Tiers and 06 — Integrations for what those features actually are.

Pricing, canonical: POS EUR 79/Site/mo + CRM EUR 39/Site/mo + KDS EUR 25/Station/mo. Target subscription revenue per Site (POS+CRM+KDS) EUR 110–130/Site/mo; downside case EUR 95. That is what canon §5.4's band means — payments residual and messaging sit on top of it and are reported as total recurring revenue per Site (§7.1), never folded into an "ARPU" figure. Median discount off list above 20% means the price is wrong, not the salesperson.

#10. Onboarding and menu build: cost per Site, and the plan to automate it

At EUR 16–24/h loaded: manual EUR 350–1,320/Site, with AI EUR 256–816/Site. Savings ~EUR 250/Site. Install day is separate and larger: EUR 550–1,400/Site in CZ — 5–8 on-site hours × 2 people, plus network remediation the Customer did not budget (networking is 20–35% of the hardware bill).

The ROI of AI ingestion is not the EUR 250. It is time-to-first-transaction — moving from "three weeks out, our queue is full" to "next Tuesday" is worth more in close rate than the labour saved.

Automation roadmap, all inside canonical scope:

In-app staff self-onboarding for a new cashier: funded in v1 Full at 1.5 eng-months, deferred in the S1 cut. Front-of-house turnover is 60–100%/yr, so ticket volume is a function of the Customer's staff churn, not our Site count, and 08 calls this the only real mitigation. Which plan gets it, and when: S2 ships it at M18 inside the Full v1. S1 does not have it at the P2 exit — it is one of the "Full only" deferrals, and the earliest S1 slot is P3, where it competes with the five deferral repayments v2 core already needs (§5.1.1) against ~6 eng-months of contingency. The trigger to pull it forward is A20: if the M24 gate shows tickets/Site/month above 1.8 with staff churn named as the driver, it moves into P2 at +1.5 eng-months against the 125, and something else in the S1 cut comes out. Do not leave this floating to the P3 planning meeting — see 08 — Pros, cons, difficulties and risks.

#11. Support model and its cost

Standard coverage is 07:00–01:00 local, 7 days. 24/7 is a paid tier at +EUR 25/Site/month. Restaurants are not open at 04:00, and letting the 168-hour figure drive the cost model is how the SaaS line goes gross-margin-negative.

Ticket rate, canonical: 2–4/Site/month for the first 6 months post-install, decaying to 0.8–1.2; use 1.4 blended for the first 24 months. Hardware causes ~45% of all tickets — 03 — Hardware, peripherals and the device fleet owns that share and the EUR 25–43/Site/month hardware-ops model built on it — and ~60% of hardware tickets are printing, i.e. ~27% of all tickets.

The 4.4–5.0 FTE floor for 07:00–01:00 coverage exists at 50 Sites and at 500 [estimate]. You are paying for coverage, not throughput — which is exactly why the first 300 Sites are the most expensive Customers this company will ever have, and why the AI tier-0 agent with device telemetry is a v1-sellable item and not a v1.5 item. An agent that reads printer, terminal and sync telemetry and files the ticket before the restaurant calls converts the coverage floor from "a human on a phone at 22:00" to "a human reviewing a queue at 09:00" — worth EUR 9–11k/month at 500 Sites. The agent itself is 2.5–3.0 eng-months inside Domain H's 8.0 (S1 cut) — the same domain also carries Stripe Billing, the payments-partner integration, the onboarding workflow tool and the MSA/DPA/SLA contracts. Quote it as 2.5–3.0, not as 8.0 and not as 3.0 flat; 08 — Pros, cons, difficulties and risks uses the identical figure.

A20 is the assumption that decides breakeven: blended ticket rate ≤1.4/Site/month through the first 24 months, instrumented from Site #1. Above that, support cost per Site exceeds EUR 55 against EUR 110–130 of subscription revenue — freeze sales and fix the product.

#12. Decision gates and kill criteria

Written so a third party can check them without asking us. Month numbers are the S1 calendar (start 2026-09-01); the S2 equivalent month is in brackets. These re-anchor the appendix critique's gate months onto the canonical phase calendar — the criteria are the critique's, the dates are canon's.

#M6 — Mar 2027 [S2: M4] · "is the money code real?"

#M12 — Sep 2027 [S2: M7] · "does it survive a kitchen?"

#M18 — Mar 2028 [S2: M10] · "can we sell it to strangers?"

#M24 — Sep 2028 [S2: M14] · "are the unit economics real?"

Financing gates, restated: S1 — pre-seed EUR 900k–1.1M before P0 (by Jan 2027), extension EUR 900k–1.3M at the P2 entry gate (Mar–May 2028), and — on the mid case, not only on the low case — a third round of EUR 0.6–1.5M in FY5, because peak capital through M47 (EUR 1.8–2.4M) is not capital to breakeven (EUR 3.0–3.5M, §7.4). S2 — EUR 7M before P0, and a EUR 15–25M Series A term sheet at M20 (May 2028) on EUR 1.2–1.6M ARR, which is binary.

Realistic exit: EUR 40–90M strategic sale in years 6–9 to Nexi, Teya, Worldline, SumUp or Lightspeed. Anchor: orderbird → Nexi, EUR 130–140M for ~14,000 clients [verified in canon]. At 60–80% founder ownership on the EUR 3.0–3.5M this path actually costs to get to breakeven, that is a life-changing outcome that does not require winning Europe. Note the arithmetic in the other direction: selling at M47 instead, at 3–6× ARR on EUR 475–600k, returns EUR 1.4–2.9M — approximately the capital invested (§7.4).

#13. Where this plan is most likely wrong

Risk treatment, mitigations and the full assumption register live in 08 — Pros, cons, difficulties and risks; the go/no-go verdict this budget supports is in 01 — Feasibility verdict.