#Pros, cons, difficulties and risks
TL;DR
- The case for is one sentence: a 60–90 bps payment spread on a market whose incumbents stopped shipping, served from a cost base one third of Amsterdam's.
[verified]on the spread,[known]on the incumbents. Everything else — the CRM, the AI, the offline core — is how you get to the payment contract, not why the business works. If assumption A2 (≥25 bps residual, no merchant-ownership clause) fails at P0, there is no version of this that clears 1.0× LTV/CAC and you should stop. See 04 — Payments, fiscalisation, privacy and security. - The case against is also one sentence: 125 eng-months of correctness-critical work stands between you and a product a stranger will pay for, and the brief's 24-month, 3-engineer, EUR 900k framing is off by roughly 2× on capital and 12 months on calendar. The canonical bootstrapped plan is 5 engineers, 36 months, peak capital EUR 1.8–2.4M through M47 — and, the number that usually gets left out, EUR 3.0–3.5M of capital to breakeven, over 5–7 years and ~800 Sites. 35–45% probability of reaching Y3 alive
[estimate]. M47 is not the finish line; it is a third financing event (R29). See 07 — Roadmap, Team and Budget. - The three things most likely to actually kill this, in order: (1) support cost per Site exceeds gross margin before the AI tier-0 agent lands (A20); (2) the payments residual never materialises on acceptable terms (A2); (3) the founder becomes the weekend on-call rota at 60–100 Sites and engineering velocity goes to zero. None of the three is a technology problem.
- The hardest technical problem is not distributed consensus; it is exactly-once side effects at a printer nobody can query. Second is that Android has no rollback, so a Thursday build with a print-routing bug can only be mitigated by a flag that already existed. Both are cheap to design for and catastrophic to retrofit.
- We are consciously trading breadth for survivability everywhere: one country, one segment, one Station per Site, one printer SKU, one PSP, buy every fiscal signature — and, as of the P3 capacity reconciliation, full service (table service, coursing, seat splits, the handheld waiter app) moves out of v2 core and into v3, i.e. P4 and later. Each of those trades away a market we could have had; together they are the only reason 125 eng-months is reachable at all, and the full-service cut is the only reason P3 fits its 58–65 eng-months.
- Kill criteria are written so a third party can check them without asking us. Fewer than 8 of 40 Prague/Brno operators place a EUR 200 deposit → do not write code. No written payments term sheet at P0 exit → stop. Contribution margin per Site ≤ EUR 0 at P2 exit → stop; more Sites make it worse.
Scope: this document owns the honest argument, the risk register, the tradeoffs and the kill gates. Architecture is in 02 — System architecture, hardware in 03 — Hardware, peripherals and the device fleet, payments/fiscal/privacy in 04 — Payments, fiscalisation, privacy and security, CRM scope in 05 — The CRM Product and Scope Tiers, connectors in 06 — Integrations, effort and money in 07 — Roadmap, Team and Budget, the verdict itself in 01 — Feasibility verdict.
#The honest case for building this
Seven reasons. None of them is "the market is large".
1. The payment annuity is real, is bigger than the software line, and is ~100% incremental margin. CEE SMB street rates run 1.3–1.9% against a ~0.51% + EUR 0.135 cost base; the spread available to a POS that owns the merchant relationship is 60–90 bps gross [verified]. On a EUR 350k/yr Site that is EUR 1,600–2,600/yr [estimate] against the EUR 110–130/mo subscription line (POS + CRM + KDS; the payments residual and messaging are on top of it, not inside it) — 2–3× the subscription, recurring, at near-zero marginal cost. Net payments gross profit modelled per Site per year: Poland EUR 1,620, Germany EUR 670, Ukraine EUR 0 to us [estimate]. The EU interchange cap compresses this for us and for every competitor equally, so it is not an advantage that erodes. No CRM-only, analytics or reservations vendor can reach it.
2. Nobody is defending CEE, and every defender is structurally weakened. Toast, Square, SpotOn and Clover are absent. Storyous → Teya, Dotykačka → Teya (majority), orderbird → Nexi, Gastrofix → Lightspeed [known]. Acquirer- and PE-owned POS vendors reliably produce frozen roadmaps, annual price rises, cut support and demotivated sales. A market full of locked-in, annoyed Customers whose vendor stopped shipping is the best substrate a small fast team can inherit — and it has a shelf life of maybe 4–6 years [estimate] before someone else takes it.
3. A 3× labour-cost advantage sits on exactly the two costs that never scale. Support and field ops are linear in Site count forever. A loaded CZ support FTE is ~EUR 2,500/mo against EUR 4,200–5,200 in Amsterdam or Berlin [estimate]; the Ukraine engineering and support base is cheaper again. Nobody headquartered in Western Europe can profitably serve a EUR 110/mo café. This is the most durable structural advantage in the plan and it is the one AI does not hand to competitors.
4. Owning the POS is the only way to own identity, and identity is what the CRM sells. A CRM overlay sees 24% of Checks; owning the order flow gets 30–38% at v1 if A4 holds, 22–28% if it does not — and **52% only at v2 core**, once guest web ordering, the QR PWA and Wallet passes ship [estimate]. Quoting 52% to a v1 prospect is a churn generator, not a rounding error; the arithmetic is in 05 — The CRM Product and Scope Tiers §3.2. On revenue-under-management the gap is narrower still — identified Guests visit 1.5–2.5× more often and spend 10–25% more, so 24% of Checks ≈ 35–45% of revenue, 30–38% ≈ ~45–55%, and ~52% (v2 core) ≈ 65–75% 1.2–1.4× value gap at v1, widening to 1.7–2.0× at v2 core, not 3×**. The decisive argument is not coverage: it is that a CRM overlay has no switching cost and churns at 40–60%/yr [known] — a **[known] while a POS churns at 20–30%, and clears only 3–37% gross margin through middleware.
5. Holdout-based incrementality is a differentiated claim that costs almost nothing to build. Walking into a renewal with "your loyalty programme generated EUR 4,120 of incremental gross margin last quarter, measured against a randomised Holdout" is an argument no CEE competitor can currently make, and it is the honest answer to "is this worth the fee". It also disciplines the product: the same power analysis that makes the claim credible is what tells us the ICP is 2–8 Site chains, because below ~1,500 treated Guests the effect is statistically undetectable [estimate]. Scope detail in 05 — The CRM Product and Scope Tiers.
6. Czechia removes the single largest category-killer: the certification queue. Zero fiscalisation since 1 Jan 2023 [known], no producer liability, no local entity, one language, widest Stripe Terminal reader roster in CEE [verified], everything drivable in three hours. The hard rule — enter only markets whose time-to-first-legal-invoice is under 60 days — converts market selection from a ranking exercise into a filter, and it is the reason a first legal invoice is a ~5-month problem rather than a ~21-month one. See 04 — Payments, fiscalisation, privacy and security.
7. The exit is named, priced and plural. orderbird → Nexi at EUR 130–140M for ~14,000 clients [verified]; Gastrofix → Lightspeed at ~EUR 80M [known]. Every European payments and POS strategic is buying distribution. A 1,500–3,000-Site CEE base with payments attached has 4–6 named buyers — better than almost any vertical SaaS niche. At 60–80% founder ownership on EUR 1.8–2.4M of capital, a EUR 40–90M outcome in years 6–9 [estimate] is life-changing and does not require winning Europe.
#The honest case against
Seven reasons. These are the ones that should make you put the deck down.
1. The arithmetic of the brief does not close, and no amount of AI fixes it. Reconciled scope is 125 eng-months for the S1-cut v1 (168.5 full — canon §5.1's 167 domain roll-up plus the 1.5 eng-months for in-app staff self-onboarding funded into Full on 2026-08-18). S1 delivers ~42 eng-months/year at 3.5 effective FTE after the on-call tax, so ~126 over 36 months. The brief asked for a sellable POS+CRM from 3 engineers in 24 months on ~EUR 900k. That is off by ~2× on capital and ~12 months on calendar. Worse, the AI multipliers are uneven by design — B ≈ 1.50×, C ≈ 1.35×, D ≈ 1.25×, A ≈ 1.10× — and the offline core, the fiscal work and the correctness-critical CRM ledger are exactly the rows AI barely touches. Certification queues, field sales, physical installs, RMA logistics and trust compress by 0%.
2. Support cost can exceed gross margin, and you will not know for 18 months. New POS installs run 2–4 tickets/Site/month for the first 6 months, decaying to 0.8–1.2; blended 1.4 for the first 24 months [estimate]. At 500 Sites and CZ wages that is EUR 40–55/Site/month against the canonical EUR 110–130/Site/month subscription line (POS + CRM + KDS only) — and the subscription alone is then thin or negative, with the payments residual not an upside but the only thing keeping the Site solvent. The AI tier-0 agent takes it to EUR 25–32 [estimate], but it is 2.5–3.0 eng-months inside Domain H's 8.0 (canon §5.1; the rest of Domain H is billing, the payments-partner integration, the onboarding tool and contracts) and it lands late in a plan where everything lands late. A20 is the assumption that decides breakeven.
3. Restaurant staff turnover means your ticket volume is a function of their churn, not your Site count. Front-of-house turnover runs 60–100%/yr [known]. Every cashier who leaves takes the training with them. There is no version of this where support load decays the way a normal SaaS support curve decays, and the only real mitigation is a UI so simple a 19-year-old is productive in 12 minutes. That is a product cost, not a documentation task, and it is now a decided one: in-app staff self-onboarding is funded at 1.5 eng-months in v1 Full (Domain C), deferred in the S1 cut, and named as the first Full item the S1 cut repays if A20 trips at the P2 gate (canon §4, decided 2026-08-18). The residual risk is therefore not "unfunded" — it is that the S1 cut trains staff without it through the whole of the pilot and the first paying market (M17–M31), which is exactly the window in which A20 is measured (R2).
4. You are selling into a market that mostly does not want to switch. Restaurants change POS at exactly four moments: new opening or refit, forced migration, ownership change, acute failure. Displacement selling to a content incumbent Customer is a 6-month cycle at a ~10% win rate [estimate]. Annually contestable market in the beachhead is 200–500 Sites out of ~30,000 CZ POS-relevant Sites [estimate]. And the terminal lease blocks the money: 36–48-month acquirer contracts with EUR 300–900 early-termination fees cap payments attach on displacement wins at 20–30% (A21).
5. The incumbent's effective software price for a card-heavy Site is already near zero. Dotypos prices SaaS down as card turnover rises [known] — i.e. "free software if you process with us" is not a future competitive response, it is the current price list. Our EUR 118/Site bundle is priced against that. The packaging wedge (POS + CRM in one) is copyable in 9–15 months by any funded competitor [estimate]; what is not copyable is 800 Sites with cabled printers, trained staff and settlement flowing through our contract. Which means the moat only exists after you have already survived the hard part.
6. Producer-side liability is uninsurable and asymmetric. Spain's LGT art. 201 bis fines the software producer per product per exercise — not the merchant — and the 29 Jul 2025 producer deadline was not postponed by RD-ley 15/2025 [verified]. Germany's Kassennachschau reaches the merchant through § 379 AO plus turnover estimation, and France's art. 1770 duodecies CGI reaches the merchant with the éditeur's attestation behind it. The amounts, their statutory basis, their legal-confidence grade and the counsel owner for each live in one place — 04 — Payments, fiscalisation, privacy and security §4.2 — and are not restated here. What matters for the risk view is the shape: two of the three land on our Customer and reach us only through indemnity and reputation; the Spanish one lands on us, is the reason Spain is a permanent exclusion, and sits at legal confidence M — a fine amount at M does not belong in a board pack or an investor deck. Tech E&O at EUR 8–25k/yr for EUR 1–2M cover [estimate] does not cover regulatory fines levied on us. One fiscal defect that fines a Customer is a hard stop in this plan, not a bug ticket.
7. Two people and one country of concentration risk. Losing one of three engineers to mobilisation is a 33% capacity cut with no weeks-scale hiring pipeline and a plausible bus-factor-1 on the fold [estimate]. The plan also depends on hiring 2 senior Kotlin/Android engineers in 8 weeks (A15); if that fails, the entire client stack reopens at +5.5 eng-months plus 0.15–0.25 eng-months/quarter forever. And the founder is 0.4 eng-FTE, the sales motion, the payments negotiation and the first support rota simultaneously. The most likely cause of death is not a wrong decision; it is the founder running out of hours in month 14.
The way this actually dies, drawn once. Not one catastrophic decision — a compounding loop that starts with a schedule slip and ends with a founder doing support instead of selling.
The loop has exactly three cut points, and all three are in the plan on purpose: scope discipline (the S1 cut at 125 eng-months, never the full 168.5), the first support hire at Site #40, and the AI tier-0 agent in v1 rather than v1.5. Removing any one of them re-closes the loop.
#The ten hardest technical problems
Ranked by the cost of getting them wrong, not by intellectual difficulty. Design detail lives in 02 — System architecture; this table is the risk view.
| # | Problem | Why it is hard | What naive teams do | Our approach | How we know we are failing |
|---|---|---|---|---|---|
| 1 | Exactly-once at the printer | The printer is the only irreversible side effect in the system and it cannot be queried for "did you print job X". Every push protocol has an irreducible ambiguity window between send and ack | Blind resend on reconnect. A reconnect storm across 200 Sites on one Friday = 40 duplicate Tickets per kitchen, EUR 3–15 of comped food per duplicate, EUR 10–40k in one evening [estimate], and chefs permanently reverting to verbal call-out | Intent log → send → verify queue, every print job stamped with the Coordinator epoch, never a blind resend; monotonic per-Station Ticket number printed on the paper as the human dedupe primitive; per-Station ordering by fire time with a backlog cap ("40 Tickets queued — print all / print summary?") | Duplicate-Ticket reports in support tags >0.5% of Sites/week; any Site where staff have taped a "check the number" note to the printer; verify-queue depth alarms firing more than once per Site per month |
| 2 | Coordinator epoch reuse after a whole-Site power cut | Devices boot in arbitrary order and elect at max(persisted_epoch). If the epoch fsync did not land — and on cheap eMMC it frequently does not — two Devices legitimately believe they hold epoch N and the fencing token stops fencing | Store the epoch, assume fsync, ship. This is the exact mechanism behind the month-10 double-fire | Coordinator identity derives from (persisted_epoch, boot_id, monotonic_start); a claim needs majority ack from reachable peers or cloud confirmation; in a 2-Device Site with no WAN the election loser freezes print dispatch for 60 s. ~0.4 eng-months [estimate] | The divergence detector reports two epochs live in one Site, ever. This is a P1 regardless of customer impact |
| 3 | fsync is a lie on the hardware we resell | The whole intent-log design assumes durability. On cheap Android eMMC and SD cards, fsync returning is not the same as data being on media | Never test it. Discover it in month 14 as "orders sometimes vanish after a power cut" | A7: week 3 of build, write intent, cut power at 1,000 random offsets on the smart PDU, count survivors, per certified SKU. If it lies, the printed Ticket number becomes the only dedupe primitive and print health rises +1.0 eng-months | Any survivor count below 100% on a certified SKU. The test is binary and it is run before the architecture is trusted |
| 4 | Business Day, clock skew and the wrongly-dated Check | A Device with a dead RTC coin cell boots with a wrong date and stamps the most fiscally consequential field in the system. Every Check that shift lands in the wrong Daily Close, and in fiscalised markets on the wrong fiscal day. It also permanently mis-prices happy hour, because unit_price_minor is snapshotted and never recomputed | Stamp business_date from the device wall clock and add ReassignBusinessDay as an admin repair — treating a systemic failure as an exception | Business Day is leased from the Coordinator, like Check numbers. A Device more than 5 minutes from Coordinator HLC-physical time may take orders but may not close or tender. The fiscal adapter refuses to sign outside a trusted-time threshold. ~0.3 eng-months [estimate] | Any ReassignBusinessDay event in production. Any Daily Close whose Check set changes after close |
| 5 | The deterministic fold staying commutative as the business rules grow | The fold is easy to write and hard to keep permutation-invariant. Every rule added later — a Service Charge applying after Comp but before Discount, per-seat tax on a split Check — forces re-derivation of the absorbing and commuting properties across the whole conflict table. That iteration lands in months 4–14, not weeks 1–16 | Let an AI agent write the fold. It will satisfy P1–P3 and quietly violate P4 (permutation invariance) by iterating a hash map, and it looks correct in review | The property suite is written by a human before the fold exists, and the fold is accepted only by the property suite, never by review. Anything touching money is implemented with AI assistance and property-tested by a human who did not write the implementation. Domain A is costed at 16.0 eng-months for the S1 cut, with a 1.10× multiplier, not 1.5× | A property test is weakened or @Ignored to make a feature ship. A single divergence in production with no reproducing seed. Owner P&L short ~1% with no explanation — by then you have already lost the account |
| 6 | Android has no rollback, so the mitigation must pre-exist the incident | INSTALL_FAILED_VERSION_DOWNGRADE; uninstall/reinstall wipes app-private storage and destroys the unsynced Check journal. At 19:40 on a Friday with 180 Sites mid-service, a forward-fix is 2–5 h and ships at 01:00 | Ship the risky path unflagged and plan to "push a hotfix" | Every risky path behind a remotely-flippable flag evaluated offline from a signed, monotonically-versioned config bundle the Device refuses to downgrade, with last-known-good cache. Kill switch = 2 minutes to mitigation. Release freeze Thu 12:00 → Mon 10:00. Cohorts lab → 3 friendly Sites → 10% → 40% → 100%, 24 h soak spanning a dinner service at each step | Any P1 whose mitigation required a build. Any flag added during an incident. Any release that shipped Thursday after 12:00 |
| 7 | Payment terminal ownership and the unknown state | A semi-integrated reader that receives a second collectPaymentMethod while the first is presented can cancel the first after the card was tapped and before the app sees a result — an authorisation exists at the PSP with no local Payment. This is the worst state the system can reach. Separately, SCA soft-declines (online_or_offline_pin_required) are guaranteed on every PIN transaction, not rare [verified], and CZ's ~CZK 500 contactless CVM floor [known] makes PIN the common path, not the fallback | Render the soft-decline as "declined", staff re-run, Guest charged twice. Treat two Devices driving one reader as "annoying, self-limiting" | Terminal ownership is a lease with the same fencing epoch as print dispatch; payment_attempt has an explicit unknown state never rendered as "failed"; idempotency key on {check_id, attempt_seq}; soft-declines classified in-flight and filtered before reconciliation matching; nightly PSP reconciliation by idempotency key surfaces orphans | Any Guest-reported double charge. A decline-rate dashboard reading ~50% (that is soft-declines leaking into reporting, and it will generate an escalation from every Customer in week one) |
| 8 | Erasure and consent across offline Devices | GDPR erasure against an append-only event log replicated to Devices that may be offline for weeks. Retrofitting it is a rewrite of the sync core — the research calls it a 3-month nightmare, and it is the item every chain's security questionnaire asks about | Defer erasure to "when a DSAR arrives". Then discover the fiscal store, the analytics replica, the ESP and every Device each hold a copy | Guest PII in a separate crypto-shreddable store keyed by guest_id; the financial log holds only guest_id; erasure tombstones replicate over the same sync channel with per-Device ack tracking and per-Device revocable data keys, from commit one; rendered Ticket bitmaps never persisted beyond a 24 h retry window. Costed at 5–6 eng-months, not 3.0 | A DSAR that cannot be closed within 30 days. Any Device that acknowledges a tombstone it did not apply. Any rendered bitmap older than 24 h in the print outbox |
| 9 | On-Device event-log growth and the "slow on Fridays" report | A busy Site produces 100–170k events/day at 40–120 events/Check and ~1,400 Checks/day [estimate]. 90 days of that under SQLCipher on a 2 GB device is 9–15M events; replay-from-empty takes minutes; cold start blows the 1.5 s budget | Keep 90 days on-device "for support". Ship. Receive an unfalsifiable "it's slow on Fridays" in month 9 at your best Customer | On-Device retention is 7 days of closed Checks plus all open Checks, hard alarm at 500 MB, cloud is the archive. Replay/force-resync/audited surgical repair pulled forward to month 5, before pilot Sites | Any Device DB over 400 MB. Cold start p95 over 1.5 s on the slowest certified SKU. Any support call answered with "we'll need to look at the logs" that takes more than 20 minutes |
| 10 | Install-day reality: networks, provisioning and the 20% that miss the happy path | Writing the fleet agent is the cheap part. The cost is the provisioning failure taxonomy — Device already set up (Device Owner permanently unavailable), captive-portal Wi-Fi, WPA2-Enterprise, DPC download blocked by the Site firewall, an OEM ROM without the 6-tap QR path, zero-touch not enabled by the reseller. And an ISP router swap can re-IP the whole Site, invalidating every persisted peer and printer address | Budget the 25–35 minute happy path. Discover that networking is 20–35% of the hardware bill and the Customer budgeted none of it | Router (Teltonika RUT241) and a validated AP are a hard requirement of the install, not a recommendation — refuse to install without them, or owe 1.5–2.0 eng-months of cloud-relayed peer path nobody costed. Printers get a cable; Wi-Fi printers are "unsupported, best effort". Peers key on device_id + cert fingerprint with cloud rendezvous on subnet change. Domain D costed at 10.0 eng-months for the S1 cut | Install day exceeding 8 on-site hours more than 20% of the time. More than 30% of Sites needing a return visit. Any install that proceeded without the router |
Honourable mentions that did not make the ten but will cost you a week each: nightly ISP CPE reboots at 03:00–04:00 colliding with the OS update window and triggering an election storm inside a late bar's Business Day; a KDS socket in CLOSE_WAIT that looks alive to the app and dead to the kitchen (hence the 45 s heartbeat-age full-screen state change); split-payment concurrency at 22:30 producing a correct OVER_TENDERED state and a terrible experience; SET LOCAL app.org_id issued outside a transaction under PgBouncer, which turns RLS from a backstop into false confidence.
#The five hardest non-technical problems
#1. Certification and the calendar you do not control
The rule that generates the market list is time-to-first-legal-invoice under 60 days. It admits CZ, UA, NL, UK, DE, AT, FR (self-attest) and excludes PL-via-GUM (6–12 months, PLN 50–150k [estimate]), BE (6–12), PT (3–6 + entity), SK, HU, GR — and permanently excludes Spain on producer liability [verified]. The trap is not cost, it is sequencing: start certification at month 12, spend 9 months of authority calendar, reach first revenue at month 21 with 3 months of runway, and you cannot pivot because the dossier binds a software version you may no longer deploy over. This is why fiscal logic lives in a slow-release, separately-versioned module, and why we buy every signature (FiscalProvider behind fiskaly / Deutsche Fiskal / EFSTA / Checkbox / a GUM-homologated printer partner). The argument for buying is co-defendant risk transfer, not price — a vendor with its own certification in the chain is a named party in any dispute, which is worth 11–25% of ARPU on its own. Detail in 04 — Payments, fiscalisation, privacy and security.
#2. Field sales into a market that switches four times a decade
Fully-loaded CAC in CZ, Y1–Y2: EUR 2,200–3,200 [estimate], including onboarding, install day, travel, demo kit and absorption of the 15–25% of signed deals that never go live. For calibration, Toast — 4,000 salespeople, a brand, a USD 1.19M-GPV average Site — spent on the order of USD 500M of S&M for roughly 30,000 net adds in FY2025, i.e. ~USD 17k per Site [estimate]. No filing was loaded for this: it is quoted from recollection of public commentary, the per-Site figure is our own division, and it must be checked against Toast's 10-K before it appears in a deck. It is used here only as an order-of-magnitude ceiling argument — a mature field-sales machine at ~1.4× ARR-to-CAC is the benchmark, not the ceiling. Consequences we accept: Prague + Brno first, 2 districts, because 15 Sites in Prague 7 outsell 15 scattered nationally; pipeline built on new openings and ownership changes (fit-out contractors, equipment distributors, the trade-licence register) rather than displacement; a CAC line nobody models — buying out the incumbent's remaining contract term at CZK 3,000–15,000 and eating it [estimate]; and chain deals that take 9–14 months signed-to-fully-deployed, so Y2 chain revenue lands in Y3.
#3. Support hours, and the honest answer to "24/7"
The 168-hour figure drives the cost model in every plan we reviewed, and nobody asks whether the Customer is awake. We sell 07:00–01:00 local, 7 days, as standard, and 24/7 as a paid tier at +EUR 25/Site/month. Genuine single-language 24/7 needs 5.8–6.6 FTE once 25 days statutory leave, ~8 sick days and no lone-night-shift are priced [estimate] — a coverage floor that exists at 50 Sites and at 500, which is why the first 300 Sites are the most expensive Customers we will ever have. At 500 Sites: 8–11 FTE, or 3 plus escalation with the AI tier-0 agent reading Device telemetry and filing the ticket before the restaurant calls. That agent is worth ~EUR 120k/yr at 500 Sites for a 2.5–3.0 eng-month build inside Domain H's 8.0 eng-months (canon §5.1 — Domain H also carries billing, the payments-partner integration, the onboarding tool and contracts, so it is not an 8-eng-month support agent) [estimate], and it is a v1 item, not a v1.5 item. First support hire lands at Site #40, not Site #150 — because the alternative is the founder on the pager every Friday and Saturday, which is how small POS companies die: out of velocity, not out of cash.
#4. Onboarding labour, which is the real product
22–55 hours manual per Site, 16–34 hours with AI menu ingestion — a ~40% reduction, not the 80% the demo suggests [estimate]. Install cost per Site in CZ: EUR 550–1,400, 5–8 on-site hours × 2 people, plus network remediation the Customer did not budget. AI menu ingestion from PDF/photo with citations, confidence scoring and a human review UI that never auto-publishes is in MVP precisely because it attacks the largest single line of CAC. The Dotypos migration importer is worth more than it looks: it converts "I'll lose three years of history" from the hardest objection in POS sales into a 30-minute onboarding step, for 1.00 eng-months (canon §5.1 Domain I; the owning document is 06 — Integrations §2.2, where the 1.00 is load-bearing for Domain I's 4.0 S1-cut total) with no partner approval required. Its dangerous edge is A-provenance laundering: the importer sets marketing suppression by provenance and the segment builder cannot clear it, or the first winback SMS goes to people who only ever ordered through an aggregator, with the Customer's name on the complaint and our infrastructure underneath.
#5. Trust and liability, which is bought before it is earned
A POS is a system a stranger hands their business to. Concrete exposures and the operational answer:
| Exposure | Size | Answer |
|---|---|---|
| Lost revenue during an outage on a peak night | 120-cover Site on New Year's Eve: EUR 15–40k [estimate] | Offline-first is the insurance policy. It converts a lawsuit into an SLA credit. Budget it as a product line |
| Contractual liability | Cap at 12 months of fees paid, exclude consequential loss | Standard and generally enforceable B2B in the EU, but you cannot contract out of gross negligence; a CZ cap is not automatically enforceable against a foreign Customer — local-law review per market, not one template |
| Merchant fiscal fine caused by our defect | DE and FR amounts, statutes and legal-confidence grades: 04 — Payments, fiscalisation, privacy and security §4.2. Both land on the merchant and reach us through indemnity | Indemnity carve-outs, a tested Daily Close / export suite, and a certified middleware vendor in the chain as co-defendant |
| Producer-side fiscal fine | ES, levied on us as producer. Amount, statute and grade in 04 §4.2 — currently legal confidence M, untested against a non-resident producer | Not insurable. The only mitigation is not selling into Spain, which is a permanent scope exclusion. Do not quote the amount outside 04 until counsel raises it to H |
| Guest PII breach | GDPR up to 4% of turnover; realistically a EUR 20–200k incident for an SMB SaaS [estimate] | Crypto-shreddable PII store, no PAN ever, and a hard stop in the kill criteria |
| Insurance as a procurement gate | Tech E&O + Cyber, EUR 1–2M limit: EUR 8–25k/yr [estimate] | Bound at P0 exit, before Customer #1. Every chain asks for the certificate |
| The fiscal archive after churn (A24) | Unpriced and unbounded — DE §147 AO retention runs 8–10 years [known] | Define and price the handover artefact before Customer #1. Nothing in the research models holding a churned merchant's archive for a decade |
#Risk register
Likelihood is a probability over the next 36 months [estimate] unless marked. Impact is stated in the currency that matters — EUR, eng-months, or "company".
| # | Risk | Category | Likelihood | Impact | Early-warning signal | Mitigation | Owner |
|---|---|---|---|---|---|---|---|
| R1 | No acquirer/ISV gives ≥25 bps residual without a merchant-ownership clause (A2) | Commercial | 30% | Company. SaaS-only CEE is 0.65–0.95× LTV/CAC | Two term-sheet conversations stall past 6 weeks; every draft contains "we own the merchant" | Six parallel approaches from month 1 (Viva.com ISV first [verified], then Nexi, Worldline, Global Payments via ČSOB/KB, Nuvei, Adyen). Hard gate at P0 exit | Founder |
| R2 | Support cost/Site exceeds contribution margin (A20) | Financial | 45% | EUR 40–55/Site/mo against the EUR 110–130/Site/mo subscription line (POS+CRM+KDS) → breakeven never | Blended tickets/Site/month >1.4 at 30 Sites; support headcount growing faster than Site count for one quarter | Instrument from Site #1; AI tier-0 with telemetry in v1 (2.5–3.0 of Domain H's 8.0); in-app staff self-onboarding is funded in v1 Full and is the first Full item the S1 cut repays if this trips at P2; freeze sales and fix the product if breached | Support owner |
| R3 | Founder becomes the weekend on-call rota; engineering velocity → 0 | People | 55% | 15–25% eng throughput lost from ~150 Sites; the usual cause of death | Any weekend where an engineer or founder is on the pager after Site #40 | First support hire at Site #40; field/install hire by Site #10; both budgeted as product cost | Founder |
| R4 | Cohort-1 gross churn lands at 40% and does not converge | Commercial | 50% (cohort 1 at 40% is the planned case) | ~25–35 Sites lost off the 220-Site M47 path (07 §7.1 ramp: 20 / 75 / 220 at FY2/FY3/FY4 exit) | ≥3 of the first 20 Sites gone by P2 | Design-partner pilot with an engineer on site for early services; unattended-Saturday gate before scaling | Founder |
| R5 | ARPU tests below EUR 89/Site/month (A1) | Commercial | 25% | Breakeven slips to Q4-Y5, peak capital ~EUR 2.6M | Fewer than 8 of 40 discovery calls place a EUR 200 deposit | Do not write code. Re-run at EUR 95 or pivot to first-party ordering + loyalty | Founder |
| R6 | Print double-fire across the fleet on one Friday | Technical | 35% | EUR 10–40k of comped food in one evening [estimate] + churn + chefs abandoning the printer | Verify-queue depth alarms; any Site reporting a duplicate Ticket | Epoch-fenced intent log, verify queue, printed Ticket numbers, backlog cap. See problem #1 | Eng lead |
| R7 | Fold divergence loses ~1% of Check value; owner blames staff theft | Technical | 25% | Account lost permanently + word of mouth in a market that runs on it | Production divergence detector fires; owner's weekly P&L short with no cause | Human-written property suite before the fold; divergence detector with automatic pseudonymised log bundle upload | Eng lead |
| R8 | Two senior Kotlin/Android engineers not hired in 8 weeks (A15) | People | 30% | Stack reopens: +5.5 eng-months + 0.15–0.25/quarter forever | Fewer than 6 qualified candidates in the pipeline by week 4 | Start sourcing pre-P0; React Native is the named fallback with a costed reversal path | Founder |
| R9 | Loss of an engineer to mobilisation | People | 30% | 33% capacity cut, bus-factor-1 on the fold | Mobilisation policy changes; any single-owner module with no tested handover | Place engineer #3 or #4 outside UA; written, tested handover for fold/ledger from month 6 | Founder |
| R10 | CZ reintroduces a cash-register obligation (A11) | Compliance | 15% before 2029 | +2.5–3.5 eng-months and a certification calendar we do not control, in the only market with revenue | Legislative proposal reaching first reading | Quarterly compliance review; FiscalProvider interface already in MVP so CZ becomes an adapter, not a rewrite | Compliance owner |
| R11 | The neutral "join here" line in an e-receipt is obchodní sdělení in CZ (A4) | Compliance | 30% | v1 blended identity capture falls from 30–38% to 22–28%; the ~52% figure is v2 core and arrives 15 months later either way; the CRM value case weakens at exactly the first renewal | Czech counsel hedges rather than opines | EUR 3–5k counsel opinion by M2; consent-gated dual Receipt renderer already in v1 scope | Compliance owner |
| R12 | Guest PII breach | Compliance | 10% | GDPR exposure; hard stop in the kill criteria | Any unauthorised access to the PII store; any Device holding un-shredded PII past retention | Crypto-shreddable store, per-Device revocable keys, zero PAN, self-hosted observability with no PII in logs | Eng lead |
| R13 | Fiscal archive obligations for churned Customers (A24) | Compliance | 60% that it is unpriced at Customer #1 | Unbounded multi-year availability obligation | The first churn where the Customer asks for their archive | Define and price the handover artefact before Customer #1; export format is the migration importer run in reverse | Compliance owner |
| R14 | Stripe Terminal pricing, availability or CZ reader roster changes | Platform | 20% | Adapter swap 2–4 eng-months + a hardware re-certification cycle | Regional availability table changes; reader EOL notice | PaymentTerminal port never leaks provider identity; Adyen Terminal API is the named hedge and the only confirmed PAR source [verified] | Payments owner |
| R15 | Managed Google Play / OEM store policy blocks a release mid-incident | Platform | 25% | A P1 whose only mitigation is a flag that must already exist | Any policy warning on the listing; review latency creeping past 24 h | Kill switches as the primary mitigation path; release freeze; staged cohorts. Android rollback does not exist | Eng lead |
| R16 | Certified hardware SKU rot (Sunmi/Elo refresh every 24–36 months) | Platform | 90% | 1–2 eng-months/yr forever + install runbook decay | Distributor EOL notice; a SKU shipping with a new ROM | 0.25 eng-months/quarter re-certification budget, forever; second CI rig at EUR 8–10k by M12 | QA |
| R17 | Anthropic API price, availability or model-deprecation change | Platform | 35% | AI spend EUR 0.30–1.50/Site/mo is small; the onboarding cost model depends on ingestion working | Deprecation notice; latency regression on the ingestion path | One internal ai-gateway, nothing else imports the SDK; per-feature global spend cap requiring a human to raise it; manual menu entry always remains a supported path | Eng lead |
| R18 | HubRise acquired or repriced (A16) | Platform | 25% | Build Glovo natively +3.5 eng-months or drop the delivery module | Ownership change; margin below 50% at EUR 27–35/Site | Delivery is a v3 resold module (moved out of v2 core in the P3 capacity reconciliation), never a v1 dependency, so the exposure sits behind the P3 gate entirely. The Omnivore → Olo → Thoma Bravo sequence is the precedent | Founder |
| R19 | Google Business Profile API allowlist refused (A14) | Platform | 40% | Review management degrades to manual paste; no engineering workaround | No response 8 weeks after the M1 application | Apply in M1; drop from v1 sellable if not granted by M6 | Product |
| R20 | Payments attach on displacement wins below 20% (A21) | Commercial | 35% | LTV thesis requires new openings >50% of pipeline | Contract-end dates captured on discovery calls cluster 2029+ | Capture "acquirer + rate + contract end date" on every call; reorder lead-gen to fit-out contractors and the trade-licence register; budget contract buy-outs | Sales |
| R21 | Competitor bundles CRM into POS at near-zero effective price | Commercial | 60% | The packaging wedge closes in 9–15 months | Losing ≥3 deals to a competitor's new loyalty feature | Compete on installed base × switching cost × payment contract, not features. Holdout attribution is the hardest feature to copy credibly | Founder |
| R22 | Enterprise gravity: the first chain becomes the roadmap | Commercial | 45% | 5–15 eng-months of bespoke work off the critical path | Any unpriced custom request accepted verbally | Written rule: no bespoke work below EUR 60k committed ACV; every custom request priced as professional services at EUR 900/day [estimate] or refused in writing | Founder |
| R23 | Extension raise at M20 fails (S1) or the Series A term sheet does not exist (S2) | Financial | 40% (S1) / 50% (S2) | S1 runs out at ~M26 mid-build; S2 must switch to a profitability plan | Two months of investor meetings with no second call | S1: pre-seed EUR 900k–1.1M + extension EUR 900k–1.3M planned from day one. S2: freeze hiring, one country, EUR 3M ARR breakeven by M40 | Founder |
| R24 | FX: EUR/USD cost base against CZK revenue | Financial | 50% of a ≥10% move | ~7 points of gross margin on a 10% CZK depreciation [estimate] | Rolling 90-day FX drift >5% | Annual CPI-linked price indexation in the MSA from contract #1, and do not fold when CZ SMBs push back | Founder |
| R25 | Hardware working capital, DOA and RMA drag | Financial | 40% | The achievable 10–13% gross margin (cost + 15% is a 13.0% margin on revenue before freight, spares and DOA) evaporates entirely; spares tie up cash | RMA/DOA above 4%; spare pool below 1 per 25 live units | Sell at cost + 15%, never subsidise; 5–8% in-region spare pool; 2–4% RMA reserve; branded bundle of OEM-branded devices so CE/GPSR/WEEE/CRA stay with the OEM | Ops owner |
| R26 | Sub-merchant KYB stalls or merchant negative balance (A23) | Financial | 40% | EUR 15–40k/yr bad debt at 300 Sites [estimate]; a signed Customer who cannot take cards for 9 days is a churn event | >10% of applications stalled on documentation | Ops owner (not an engineer) on onboarding; rolling reserves; delayed payout on prepaid sales | Ops owner |
| R27 | AI-written money code hits the maintainability cliff | People | 35% | Comprehension wall at 80–120k LOC [estimate], in the fold and the loyalty ledger specifically | Review latency rising; "I don't know why this works" in a PR thread | Money code: implementation AI-assisted, property suite by a human who did not write it. Measured per sprint against the reconciled work-breakdown (A22) | Eng lead |
| R28 | Effort re-baselines upward mid-build | Financial | 45% | v1 sellable slips past M31; runway is consumed by scope, not by sales | Two consecutive sprints below the reconciled work-breakdown burn rate | Re-baseline the effort plan and do not re-forecast the revenue (A22). Cut to the S1 tier, never to the property suite or the device lab | Eng lead |
| R29 | M47 is a third financing event, not breakeven — peak capital ≠ capital to breakeven | Financial | 70% over 60 months that a third raise or a sale is required [estimate] | 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. The modelled S1 mid case at M47 is ~220 Sites and ~EUR 475k ARR, still burning EUR 450–550k/yr. The three exits from that state are a third raise on worse terms, a Series A that requires S2-shaped metrics S1 will not have, or a strategic sale at 3–6× ARR ≈ EUR 1.4–2.9M — i.e. roughly the capital invested, for six years of two people's lives | FY5 absent from the board pack at M36; trailing-12-month net burn still above EUR 450k at M42; new-logo rate below ~12/month for two consecutive P3 quarters; any investor conversation in which "breakeven in year 5" is stated without the EUR 3.0–3.5M attached | Model FY5 explicitly before the M20 extension raise and say the number out loud in that raise — investors will model it themselves otherwise. Treat the P3 exit gate (payments residual invoiced on ≥30% of new logos) as the decision point between financing again and running for the P4 sale. Do not close the gap by re-forecasting revenue upward (A22) | Founder |
| R30 | Full service is deferred to v3, so every full-service prospect is unsellable until after ~150 Sites | Commercial | 60% that it costs named deals inside 36 months | Table service (courses, seats, splits by item/seat, merges, transfers, floor plan), the handheld waiter app and the customer-facing display are out of v2 core. The full-service half of the CZ market stays with the incumbent for 3+ years; a counter-service Customer who grows into table service churns rather than upgrades; the "one vendor as you grow" line is not available to us | >25% of qualified pipeline disqualifying on "do you do table service"; any design partner adding table service and asking for it; A8 tripping (>40% of the beachhead running 2+ Stations) | Qualify on counter-service in the first sales call, not the fourth. A8 stays the named reversal trigger (T2 into v1 at +9.0 eng-months, MVP slips ~3 months). What is not cut is the part P3's own exit gate rests on: T2 LAN multi-station and identity capture both stay in v2 core | Founder |
| R31 | v1 identity capture lands below 30% and the CRM renewal argument does not close until v2 core | Commercial | 40% | The EUR 39/Site/mo CRM line is sold on identity coverage. At 22–28% (A4 false) a 2–8 Site chain has too few treated Guests for the holdout report to reach significance, and the first renewal happens ~15 months before guest ordering, the QR PWA and Wallet passes ship at P3 | Median capture below 30% across the first 20 Sites at 90 days post-install; attribution reports whose confidence interval spans zero; renewals asking "what did I actually get" | Sell 30–38% at v1 and never ~52% (05 §3.2); POS phone capture, SMS e-receipt and QR join all land in MVP/v1; if capture stalls at 20 Sites, guest ordering + QR PWA is the first v2-core item pulled forward, funded out of the v3 list | Product |
| R32 | P3 has no slack: v2 core is 58–65 eng-months against 65 available in M32–M46 | Financial | 55% | Cumulative 190 eng-months at P3 exit is a ceiling, not a plan. Any P2 spillover, any repayment of a deferred Full item, or any second-market surprise pushes the P3 exit past M46 — and with it the payments-attach proof the whole LTV thesis rests on | Two consecutive P3 sprints below the reconciled work-breakdown burn rate; the UA or PL fiscal integration over budget by >30% at its halfway mark; any v3 item quietly reappearing in a P3 sprint plan | Nothing enters v2 core without something leaving it for v3 in the same written decision — the v3 list is the release valve and it is published, not implied. Re-baseline effort, never revenue (A22) | Eng lead |
| R33 | Second-market entry (UA PRRO via Checkbox/Vchasno, PL kasa-online printer partner) slips or a partner is unavailable | Compliance | 35% | P3's exit gate needs 150–250 Sites while CZ's annually contestable market is only 200–500 — so the Site count depends on two markets we have not entered. A partner refusal or a PL homologation surprise converts a 15-month phase into a 21-month one and lands inside R29's burn window | No signed Checkbox/Vchasno agreement and no GUM-homologated printer partner by M34; any partner quote above the modelled fiscal COGS; PL partner unable to name a homologated SKU we can resell | Sign both partners during P2, not P3; FiscalProvider keeps each market an adapter rather than a rewrite; if PL slips, UA carries the Site count alone and the P3 gate moves to the bottom of the 150–250 band with the burn cut to match | Compliance owner |
| R34 | Single certified printer SKU: EOL, ROM change or a supply gap on the Epson TM-m30III | Platform | 45% | Every Site ships with one printer SKU. An EOL notice or a 10-week lead-time gap stops installs, not just development, and re-certifying a replacement is inside R16's 0.25 eng-months/quarter only if it is planned, 1.0–1.5 eng-months if it is an emergency | Distributor lead time past 4 weeks; any TM-m30III firmware revision appearing in the wild; a second SKU requested by a Customer before we have one | Hold a 5–8% spare pool in-region, keep a named second SKU pre-qualified in the device lab at all times (the qualification, not the stock), and never let the install runbook assume a single firmware revision | Ops owner |
| R35 | PCI scope drifts from the semi-integrated, zero-PAN posture into full SAQ D | Compliance | 20% | The zero-PAN architecture is what keeps PCI at EUR 20–40k one-off plus ~0.3 eng-months per quarter ongoing (04 §8, inside Domain E's 11.0). One keyed-PAN feature, one screenshot of a card number in a support tool, or one MOTO request accepted for a chain moves us into an assessment we have neither budgeted nor staffed | Any ticket or feature request containing a card number; any request for keyed/MOTO entry from a chain deal; any support tool able to display more than the last four digits | Zero PAN is an invariant, not a preference: refuse keyed entry in writing at the point of sale, scrub logs at ingestion, and price any exception as a EUR 60k+ ACV professional-services item before agreeing to it | Payments owner |
#Tradeoffs we are consciously making
Every row is a market, a feature or a capability we are giving up on purpose. The right column is what buys it back.
The one that deserves its own paragraph, because it was decided late and it costs us a segment: full service moves to v3. P3 for S1 has 65 eng-months and the v2 tier as originally scoped is +86.5 → +96.5 — that +86.5 → +96.5 remains the canonical figure for full v2, which only S2 can carry. Table service and the handheld waiter app serve a different ICP than canon §1's "counter-service only, single-station first", and they cannot be funded before the counter-service base is at ~150 Sites. The two things that are load-bearing for P3's own exit gate are kept in v2 core: Site count (T2 LAN multi-station plus the two second markets, UA and PL) and identity capture / CRM renewal (guest web ordering, the QR PWA, Wallet passes — the things that take capture from 30–38% to ~52%). Cutting either of those would break a thesis this deliverable states as proven elsewhere. Cutting full service does not; it costs us prospects, not arguments. What we actually give up is stated in the table below and carried as R30, not buried in a footnote.
| Chose | Over | What we give up | Reversal trigger |
|---|---|---|---|
| Own the POS | CRM overlay on incumbent POS | 12–18 months of time-to-first-revenue, and a much smaller build | Never. Overlay churns 40–60%/yr [known] and clears 3–37% GM through middleware |
| Czechia only | CZ + NL, or CZ + PL | The largest CEE market (PL) and the best Western-EU entry (NL) for 2+ years | 50 paying CZ Sites, then UA, then PL at P3 |
| Counter-service, single Station (T0) at v1 | Full-service, multi-Station (T2/T3) | Table plans, coursing, seat splits, transfers, waiter handhelds — and every full-service prospect, now not just through v1 but through v2 core as well (see the row below) | A8: if >40% of the beachhead runs 2+ Stations, T2 moves into v1 sellable at +9.0 eng-months and MVP slips ~3 months |
| v2 core at P3 (58–65 eng-months) | Full v2 in one phase | Everything moved to v3, i.e. P4 and later: table service and the handheld waiter app · customer-facing display · Apps-on-Devices (our POS on Stripe S700/S710) · the HubRise-resold delivery module and any native Glovo connector · cashback and subscriptions · DE+AT with fiskaly / Deutsche Fiskal · the second cell and data residency. Concretely we give up the full-service ICP for another ~2 years, the delivery-aggregator story, the DACH market, and the "one device does everything" hardware story | S2-scale funding. S2 ships full v2 in the same phase because it carries ~132 eng-months/yr; S1's P3 carries 65. Individually: A8 for table service, a signed enterprise contract for the second cell, A10 for DE/AT |
| 2–8 Site chains | Single-Site cafés | The largest count of prospects by far | Never in v1. Below ~1,500 treated Guests the attribution feature tells a single Site to cancel |
| Buy fiscal signing | Build national implementations | EUR 10–15/register/month in DE/AT [verified] = 15–25% of a EUR 59 ARPU (hence: price DE at EUR 89–129, never 59) | A10: no multi-country quote under EUR 8/register/mo at 500 registers → DE/AT deferred out of the plan entirely |
| Semi-integrated payments, zero PAN | Integrated / own EMV L2-L3 | Any product that needs keyed PAN entry; the "one device does everything" story until Apps-on-Devices, which is now v3 | Never. L3 is 5–8 eng-months per acquirer per country plus a bank's quarterly test slot |
| Resell commodity hardware at cost + 15% | Manufacture, or subsidise hardware | 10–13% gross margin after freight, spares and DOA instead of 40%+, and no control over SKU roadmaps | Never in v1–v3. Manufacturing pulls CE/GPSR/WEEE/Battery Reg/CRA producer duties onto us |
| Kotlin everywhere at the counter and in the money engine | TypeScript everywhere | Shared code with the React back office; a slightly cheaper backend hiring pool; ~10% of the AI-assist multiplier on backend CRUD | A15 fails → React Native, +5.5 eng-months |
| Bespoke event-envelope sync | PowerSync / Firestore / Realm | ~2 eng-months, and a vendor's operational maturity | PowerSync adoptable as opaque transport only if the event log stays the wire format (FSL → Apache-2.0 since 2026-05-31 [verified]) |
| Raster-only printing | Text fast path | 2–4× slower per Ticket; a 40-line kitchen Ticket on a TM-U220II goes ~0.8 s → ~2.5 s [estimate] | The first Customer who measures it. In exchange we delete the entire CP852/1250/866/1251 code-page matrix, which is where CEE bleeds |
| 07:00–01:00 support as standard | 24/7 as standard | The "we're always there" line in the deck | 24/7 exists as a paid tier at +EUR 25/Site/mo |
| Self-hosted Hetzner, one EU cell | AWS eu-central-1, multi-region | Enterprise data-residency answers; a second cell for DR — now a v3 item, so the answer to a residency question is "not before P4" for the whole of the bootstrapped plan | A signed enterprise contract that funds the second cell. Capacity planning is horizontal only — CCX repriced +113–176% on 15 Jun 2026 and any rescale reprices [verified] |
| Deterministic identity only | Probabilistic matching | Some duplicate Guest records and cashier lookups | 500 tenants and a labelled evaluation set. A false merge is a reportable personal-data breach |
| Brand Vouchers | Gift cards / stored value | A feature every prospect asks for | Never. SPV/MPV VAT, national expiry law, breakage under IFRS 15, the PSD2 Art. 37(2) limited-network counter — three legal opinions before a line of code |
| Integrate reservations, scheduling, payroll | Build them | Bundle completeness in RFPs we are not in | Never |
#Failure modes with real consequences
Six scenarios, each with the operational answer. These are rehearsed, not hypothetical.
1. A bug closes a Site on New Year's Eve. A 120-cover Site loses a full service: EUR 15–40k of revenue [estimate], and the owner tells every other owner in his WhatsApp group. Operational answer: offline-first is the product-level insurance — orders, kitchen, cash and Receipts keep working with no internet, so a cloud outage is not a Site outage. The SLA defines "outage" as cloud unavailability that prevents Check capture, which if offline mode works almost never happens; credit is 10% of the monthly fee per 4 h of qualifying outage, capped at 100% of the monthly fee. Contractual liability capped at 12 months of fees, consequential loss excluded, and we do not pretend that cap survives gross negligence. The honest sales claim is fixed: "orders, kitchen, cash and receipts keep working with no internet; card payments depend on your acquirer." We never claim store-and-forward card auth, because we do not build it (A9).
2. A fiscal export is rejected by an auditor. In CZ this cannot happen at v1 because there is no fiscal component — which is precisely why CZ is the first market. In DE/AT at P3 it can: an auditor plugs in a stick during a Kassennachschau and expects an export in minutes plus a Verfahrensdokumentation. Operational answer: the signing vendor (fiskaly / Deutsche Fiskal) is in the chain as a co-defendant, not as a cost line; the export suite has golden-file tests per regime and a compliance test harness in v1 scope; a templated Verfahrensdokumentation ships as a product artefact. Fiscal Document numbers are allocated only by the certified fiscal component, never by our code — an app-allocated "fiscal" number that gaps during an outage is how this becomes an accountant's problem, then a tax authority's problem, then a 2–5 month re-certification cycle at EUR 5–20k [estimate]. If a defect of ours fines a Customer, that is a hard stop in the kill criteria, not a support ticket.
3. A sync bug loses a night of sales. The owner's P&L is short ~1.2%, he fires a server, and six weeks later he works out it was the POS. Operational answer: three layers. (a) The property suite — P1/P3/P4/P7/P8 as human-written tests before the fold exists — stops the class of bug in CI. (b) The production divergence detector fires from telemetry, with automatic pseudonymised event-log bundle upload, so we learn it from a graph, not from a restaurateur. (c) Site replay into the simulator turns "the totals were wrong last Friday" from a two-day archaeology exercise into a 20-minute investigation. That path is pulled forward to month 5, before pilot Sites, because Customers #1–20 are exactly the cohort that finds fold bugs. We do not get that account back, so the whole design is aimed at never reaching step one.
4. The kitchen gets 40 duplicate Tickets across 8 Sites on a Friday. Chefs stop trusting the printer and revert to verbal call-out; the product is now decorative even though it is running. Operational answer: epoch-fenced print dispatch, intent-log → send → verify (never blind resend), monotonic printed Ticket numbers as the human dedupe primitive, per-Station ordering by fire time, and a backlog cap that asks before draining 40 queued Tickets. Post-incident, the coordinator election that produced two epochs is a P1 in its own right regardless of customer impact.
5. A Guest is charged twice, or a card is charged with no Payment on the Check. Two mechanisms, both guaranteed rather than rare: an SCA soft-decline rendered as "declined" so staff re-run [verified], and a second Station grabbing the reader after the card was tapped. Operational answer: payment_attempt has an explicit unknown state that is never rendered as "failed"; *_pin_required is classified in-flight; the acquirer transaction reference is persisted forever and refunds are always referenced; terminal ownership is an epoch-fenced lease; nightly PSP reconciliation by idempotency key surfaces orphans within 24 h. Cashier-facing copy is written for the ambiguous case before the feature ships, because the cashier is the one standing in front of the Guest.
6. A platform revokes a connector and strands every Site at once. An API Documentation License Agreement is a unilateral, amendable click-through; the realistic outcome is de-certification with 30 days' notice, not litigation [known]. Operational answer: our MSA states from the first invoice that third-party connector availability is not warranted, is excluded from the SLA and is never a condition of the subscription; if a platform revokes access we owe migration assistance, not refunds. ~EUR 3–5k of drafting, in the template before invoice #1. Related and decided in writing: the in-parcel "win your customers back from Glovo" QR and an aggregator connector cannot both be safe — we ship connectors, so that feature does not exist. See 06 — Integrations.
#Kill criteria
Written so a third party can check them without asking us. These are the canonical phase gates from 07 — Roadmap, Team and Budget, stated here as stop conditions. S1 months in brackets.
P0 exit — Foundations (M4). Before any production code beyond the fold and its property suite.
| Signal | Pass | Fail action |
|---|---|---|
| Prague/Brno operators placing a EUR 200 refundable deposit at ≥EUR 89/Site/mo, out of 40 discovery calls | ≥8 | Do not write code. Re-model at EUR 95 ARPU (breakeven Q4-Y5, peak capital ~EUR 2.6M) or pivot to first-party ordering + loyalty |
| Written payments term sheet: ≥25 bps residual, no merchant-ownership clause, no volume minimum unreachable by M36 | ≥1 | Stop. The economics do not exist and no engineering fixes it (A2) |
| Czech counsel opinion signed: e-receipt join line, loyalty T&C under Art. 7(4), VAT on points redemption | Signed | Ship the fiscal-only Receipt template and re-model v1 capture at 22–28% instead of 30–38% (the ~52% figure is v2 core either way) |
| Teya/Storyous/Dotykačka ownership conflict confirmed by direct call (A3) | Confirmed | If Teya is available, the on-ramp gets cheaper — not a stop |
Device lab standing; fsync power-cut test run on every certified SKU (A7) | Run, results recorded | Not a stop, but print health rises +1.0 eng-months and the intent log is no longer trusted alone |
| Kotlin-vs-TypeScript engine decision recorded as an ADR; one reconciled work-breakdown replacing the nine appendix tables | Both done | Stop until done. 12–18 eng-months of double-counted work is unresolvable after code exists |
| Tech E&O + Cyber bound | Bound | Not a stop; a procurement gate that blocks chain deals later |
P1 exit — Design-partner pilot (M17). "Does it survive a kitchen."
| Signal | Pass | Fail action |
|---|---|---|
| CZ design partners live, invoiced and VAT-charged | 5 | <3 → stop |
| Sites running unattended (no founder or engineer on site) through 4 consecutive Saturdays | ≥3 | Stop |
| Manual production data repairs by an engineer, trailing 30 days | 0 | Stop — not shippable |
| Full service run with WAN deliberately cut, reconciled to the cent | ≥1 demonstrated | The offline claim is marketing. Descope to cloud-only and re-price |
| Median tickets/Site/week by week 6 post-install | ≤3 | >6 → stop |
P2 exit — First paying market (M31). "Can we sell it repeatably, and are the unit economics real."
| Signal | Pass | Fail action |
|---|---|---|
| Paying CZ Sites | 40–60 | <30 → stop |
| Share from outside the founder network | ≥60% | <40% → this is a personal network, not a business |
| Gross churn on the first-20 cohort, annualised | <20% | ≥3 of the first 20 gone → product failure. Stop; do not "sell harder" |
| Fully-loaded CAC | <EUR 2,000 and falling QoQ | Flat or rising → the motion does not scale |
| Tickets/Site/month | <1.4 | >2.0 → freeze sales and fix the product |
| Contribution margin per Site = ARPU − support − hosting − fiscal COGS − payments COGS | >EUR 25/Site/mo | ≤0 → stop. More Sites make it worse, not better |
| Referenceable chain of ≥4 Sites live | ≥1 | 0 → the ICP is wrong |
| Median discount off list | <20% | >25% → the price is wrong, not the salesperson |
| Runway at current burn, no new revenue assumed | ≥9 months | <6 → raise now on worse terms, or stop now on your own terms |
P3 exit — Second market + payments attach (M46). Payments residual invoiced on ≥30% of new logos; 150–250 Sites; NRR >95%; support cost/Site/month <EUR 40. The scope being gated is v2 core (58–65 eng-months: T2 LAN multi-station, UA and PL fiscal, guest ordering + QR PWA + Wallet passes, card-linked identity, Brand Vouchers, WhatsApp/Viber, segmentation and journeys, the payments-attach machinery including the residual/margin ledger, plus repayment of the deferred Full items P3 depends on) — not full v2. Anything on the v3 list appearing in a P3 sprint plan is itself a gate failure. Failing the payments-attach line at P3 means the LTV thesis is unproven with the capital already spent — cut burn immediately and run for the P4 sale.
And the gate nobody writes down: what M47 actually is. Passing every line above still leaves the mid case at ~220 Sites, ~EUR 475k ARR and a EUR 450–550k/yr burn, against EUR 3.0–3.5M of capital needed to reach breakeven at ~800 Sites. So the honest P3 gate has a second question next to the first: is there a fundable story for the next EUR 1M, or is this the moment to sell? Decide it at M42, with FY5 modelled, not at M47 with two months of runway. See R29.
Hard stops, at any time, in any phase, regardless of every other metric:
- A fiscal or tax defect of ours that causes a Customer to be fined.
- A breach of Guest PII.
- Two consecutive quarters in which support headcount grows faster than Site count.
What "stop" means, honestly. At P0 it means keeping EUR 900k. At P1 it means selling the team, or narrowing to first-party ordering + loyalty for delivery-heavy concepts — not pivoting to a CRM overlay, which is a slower death with a smaller team at 40–60% churn and EUR 840 LTV against a EUR 600–1,000 CAC [estimate]. At P2 or later it means the P4 exit early: sell to Nexi, Teya, Worldline or SumUp at 3–6× ARR — on the modelled M47 mid case (EUR 475–600k ARR) that is EUR 1.4–2.9M, i.e. approximately the capital invested. That is the outcome to compare a third raise against, honestly, rather than the EUR 40–90M in six-to-nine years that only exists on the far side of another EUR 1M. Every one of those is a better outcome than 18 more months of hope, and each is only available if the kill gate is checked on time by someone other than the founder.