#Feasibility verdict — a restaurant CRM with its own POS

Want this without the jargon? Read 00 — The whole thing in plain words instead — two pages, same conclusions.

TL;DR

• Technically: yes, and there is nothing unsolved in it. Every hard part — offline-first order state, exactly-once printing, semi-integrated card payments, fiscal signing, device fleet ops — is a known-solution problem. The risk is not "can this be built", it is how much of it must exist before anyone can legally be invoiced.
• The honest size is 125 engineer-months to a sellable v1, not a hackathon and not a year. With a 3.5-effective-FTE bootstrapped team that is MVP at month 17 and a sellable product at month 31 — the brief's "3 engineers, 24 months, ~EUR 900k" does not produce this product and must be re-framed as 5 engineers, 36 months, EUR 1.8–2.4M.
• Commercially it hinges on two facts that cost under EUR 40k and about four months to test — before a line of code. (1) Will CZ counter-service chains pay ≥EUR 89/Site/month? (2) Will an acquirer put ≥25 bps of payment residual in writing with no merchant-ownership clause? If either is no, stop. Nothing in engineering fixes either one.
• Own the POS or don't do this. A CRM riding someone else's POS has no switching cost, churns 40–60%/yr, clears 3–37% gross margin through middleware and can be cut off by the incumbent at will. The CRM is why the first hundred Customers buy; the POS and the payment contract are why the next seven hundred stay.
• The uncomfortable part is the end state, not the build. The bootstrapped path reaches ~220 Sites and ~EUR 475k ARR at month 47 while still burning ~EUR 500k/yr against a breakeven at ~800 Sites. Capital to breakeven is EUR 3.0–3.5M over 5–7 years, and the month-47 options are a third raise, a Series A that needs metrics this path won't have, or a sale at 3–6× ARR — roughly the money put in.

#1. What was asked, and the direct answers

#2. The verdict, stated precisely

Feasible — conditionally, and the conditions are commercial, not technical.

Three separate feasibility questions get three different answers:

Therefore the recommendation is not "build it" or "don't". It is: spend four months and under EUR 40k proving A1 and A2 before committing EUR 2M and three years. That is the whole decision. See 07 §2 (P0) for what those four months contain.

#3. The recommended shape, in one paragraph

Build the full POS. Sell it CRM-first. Czechia only. Counter-service chains of 2–8 Sites in Prague and Brno. Ukraine is the engineering and support base, not the revenue thesis. No second paid market before 50 paying Sites in the first. Counter-service and single-Station first is what makes the number work: it removes table plans, coursing, seat splits, transfers and waiter handhelds, and takes the offline core from 48–58 eng-months to 17–20. Chains of 2–8 Sites rather than single cafés because the feature that closes deals — holdout-based incremental revenue — is statistically undetectable below ~1,500 treated Guests and would tell a single café to cancel. Full canon of binding decisions: Canon.

What that buys, in numbers: list price EUR 79 POS + EUR 39 CRM + EUR 25/Station KDS, landing at EUR 110–130/Site/month subscription, plus 60–90 bps gross payment spread on the 30–40% of Sites where the terminal lease can be broken. Against EUR 2,200–3,200 fully-loaded CAC, EUR 550–1,400 install, 22–55 hours of onboarding labour (16–34 with AI menu ingestion) and EUR 40–55/Site/month of support falling to EUR 25–32 once the AI tier-0 agent is live.

#4. The six decisions this document is asking for

On D7, the one decision made inside this study rather than inherited from it: full v2 does not fit S1's second phase, so it was split into v2 core (what P3 ships) and v3 (P4 and later). The cut falls on full-service — a different ICP than the counter-service beachhead — rather than on the growth engine. Even after the split the phase models at 63.5 against 65 engineer-months, so the contingency is thin and the lever to restore it is named rather than assumed: see 07 §5.1.1.

#5. Pros, cons and difficulties — the compressed version

The case for — the POS is a commodity that is bought for the CRM; payments residual makes a EUR 118 subscription behave like EUR 250; a small AI-assisted team genuinely does compress the code (B ≈ 1.50×, C ≈ 1.35×) and AI menu ingestion attacks the single biggest onboarding cost; Czechia is a rare zero-fiscalisation EU market; and the exit path is real and priced (orderbird → Nexi, EUR 130–140M for ~14,000 clients).

The case against — the compression is 0% on certification queues, field sales, physical installs, RMA logistics and trust, which is most of the cost; support cost per Site starts above SaaS gross margin and only the payments residual rescues it; first-cohort churn of 40% means the first twenty Customers are a research expense; restaurants fail at 20–30%/yr independently of product quality; and the bootstrapped end state is an option, not a return.

The five things that actually make this hard (full treatment in 08):

1. Exactly-once printing and Coordinator epoch fencing. Double-fired kitchen tickets cost the Customer money and destroy trust faster than downtime. Harder than any consensus problem in the system.
2. Fiscalisation as a calendar, not a codebase. Certification queues, homologation bodies and per-merchant registration clocks do not respond to headcount.
3. Support economics. 2–4 tickets/Site/month for the first six months, at hours restaurants keep (nights, weekends), against a EUR 118 subscription.
4. Onboarding labour. 22–55 hours per Site of human menu building is the hidden unit-economics killer; AI takes ~40% off it, not 80%.
5. The founder becoming the weekend on-call rota at 60–100 Sites, which is how small POS companies stall — an engineering-throughput failure, not a cash failure.

#6. The next 120 days (P0 Foundations)

No production code. Five artefacts, and any one of them failing changes or ends the plan.

Two of these five are commercial, one is legal, one is a phone call, one is a rig with a power switch. None of them is software. That is the finding.

#7. How to read the rest of this deliverable

#8. What would change this verdict