#C03 — Business Reality Check: attacking the market, economics and GTM research
Reviewer posture: investor/operator who has watched vertical-SaaS-plus-payments plans succeed and fail. I am attacking r09 (market/economics), r06 (CRM) and r07 (integrations) specifically.
Date: 2026-08-18. Labels: [verified] = checked with a source this session; [known] = training data; [estimate] = reasoned guess.
Verification performed this session: Toast FY2025 10-K figures, CZ foodservice establishment counts, NL CBS horeca counts, Adyen platform minimums, SumUp POS pricing, Viva.com ISV partner program.
#Verdict
The research is unusually good. r09 is the best of the three: it correctly identifies that this is a payments business, correctly kills the open-source-base fantasy, correctly refuses to subsidise hardware, and correctly names "the last 20%" as the thing that eats founders. r07's "land-and-replace, use importers not connectors" is the single best strategic idea in the whole set. r06 is technically excellent and commercially naive.
But the economic model is optimistic in four places that compound multiplicatively, and one of them is a factual error that would embarrass you in a fundraise:
- CAC is understated ~2x because it excludes onboarding, install, travel and dead deals.
- Support is understated ~1.8x because the ticket rate is a steady-state number applied to a startup's first 24 months, and the FTE floor assumes zero absence.
- The CZ+NL beachhead recommendation silently doubles the support wage line for half the sites and creates two of everything with no operational adjacency.
- The whole 8.1x LTV/CAC rests on Adyen for Platforms IC++ at 200 sites, which is the least likely commercial outcome in the document, and the one alternative most likely to say yes (Viva.com's ISV program) is not mentioned once.
Stack those and S1's peak capital need moves from EUR 850–950k to EUR 1.5–1.8M, and "bootstrapped" stops being an accurate word. Probability of S1-as-written reaching Y3 alive is not 45–55%; I put it at 20–30%. Probability of the narrowed version I propose in §6 reaching Y3 alive: 40–50%, at roughly half the capital.
The project is not dead. It is scoped 2x too wide and priced against the wrong second country.
#Corrections (claim → correction → confidence)
#C1. Toast's cost of customer acquisition is wrong by 2.6x, in the direction that hurts you
- Claim (r09 §3.1): "Toast added ~30,000 net locations in 2025 against sales & marketing spend in the USD 1.3–1.5B range
[estimate]— ~USD 45k of S&M per net add." - Correction: Toast's FY2025 sales & marketing expense was USD 511M (FY2024: USD 412M), per the FY2025 10-K. That is ~USD 17.0k of S&M per net location added, and a third-party CAC tracker puts Toast's FY2025 CAC at ~USD 19k/location.
[verified — sec.gov/Archives/edgar/data/1650164/000165016426000057, averagecac.com] - Why it matters: the doc uses USD 45k as "the ceiling of what a mature field-sales machine costs." The real number is 2.6x lower, which means the incumbent benchmark is harsher, not softer. A mature US field-sales machine acquires a USD 12.5k/yr-ARR location for USD 17k — a 16-month payback at Toast's margins. If Toast can only get to 1.4x ARR-to-CAC with 4,000 salespeople and a brand, your EUR 1,200 CAC on a EUR 828/yr SaaS site (1.45x) is not conservative, it is identical to Toast's and Toast is selling a USD 1.19M-GPV location. Confidence: high (verified).
#C2. Toast take-rate basis is mixed
- Claim: "USD 195B GPV at a 48 bps payments take rate", "payments USD 986M".
- Correction: FY2025 GPV was USD 195.1B, payments take rate 48 bps, and fintech net take rate 58 bps
[verified, businesswire FY2025 release]. 48 bps × 195.1B = USD 936M, not 986M. The 58 bps figure includes Toast Capital and other fintech. Quote 48 bps for a payments-only comparison and 58 bps if you are arguing "everything a POS can monetise off the payment flow". Confidence: high (verified). Minor in size, fatal in a due-diligence session.
#C3. NL market size is 70% overstated if you use the headline CBS number
- Claim (r09 §4.6): NL is "the best Western-EU entry point and it is under-modelled."
- Correction: CBS reports
69,000 food-and-beverage establishments, but the composition is 27k event catering + 16k restaurants + 16k other eateries (snack bars, lunchrooms, fast food, ice cream) + 8k bars/cafés40k sites**, of which maybe 60% run a real POS rather than a Zettle reader. Czechia: 43.5k "restaurants & takeaways businesses" (IBISWorld) vs 29.8k mapped restaurant/eatery locations[verified, cbs.nl]. Event caterers are not POS buyers. NL's POS-relevant universe is **[verified, conflicting sources]— use ~30k as POS-relevant. Confidence: medium-high. Both markets are big enough for 830 breakeven sites; neither is big enough to be careless about.
#C4. The Teya conflict in Czechia is stated twice and never connected
- Claim (r09 §4.6): "CZ: Build. Partner: Teya/Nexi referral. Competitors Storyous/Dotypos are both acquirer-owned and consequently slow."
- Correction: Teya (ex-SaltPay) owns Storyous and holds a majority in Dotykačka — the two CZ POS incumbents you intend to displace
[known]. Teya is therefore not an available payments referral partner in CZ; referring merchants to you is referring them away from Teya's own POS. r09 lists Teya as the CZ payments partner in §4.3, §4.6 and gate G3 ("sell to Teya, Nexi, Worldline…"). The single most-named CZ partner in the document is structurally unavailable. This removes the cheapest payments on-ramp from the recommended beachhead and pushes you to Nexi, Worldline, Global Payments (via ČSOB/KB) or Viva.com. Confidence: high on the ownership, high on the consequence. Verify with one phone call before month 3.
#C5. "Adyen for Platforms IC++ from month 20" is the least likely assumption in the plan
- Claim (r09 §2.2, §3.6, §4.3): IC++ delivers ~3x the residual of blended; move to Adyen for Platforms by month 15–20; the LTV/CAC table's 8.1x row depends on it.
- Correction: Adyen imposes a minimum monthly invoice (commonly cited ~EUR 120 at merchant level and materially higher for platforms) and is widely described as not viable for small businesses and early-stage platforms; IC++ eligibility is a sales conversation, not a signup
[verified-ish, multiple 2026 review sources; get it in writing]. A 200-site CEE platform doing ~EUR 60–90M annualised GMV is at the very bottom of what Adyen for Platforms courts. The missing alternative: Viva.com's ISV Partner Program — the ISV sets its own markup per transaction, Viva collects it and credits the partner's account monthly, across 24 European markets, with 100+ certified software providers in 19 countries and Android terminal + SoftPOS app integration[verified, viva.com/developer.viva.com]. That is precisely the "set your own spread, one contract, all of CEE" structure r09 assumes only Adyen provides, and Viva is far more likely to sign a 50-site ISV. Nuvei, Payrix, Silverflow and Teya's own ISV programme belong in the same table. r09's payments decision tree naming only Adyen/Stripe/Nuvei/Payrix is an omission that changes the go/no-go. Confidence: high that the omission matters; medium on Viva's exact economics — get a term sheet.
#C6. "SaaS-only CEE is 1.7x LTV/CAC" — it is worse, which strengthens the conclusion
- Claim (r09 §3.6): CEE café SaaS-only = EUR 2,054 LTV / EUR 1,200 CAC = 1.7x, 28-month payback.
- Correction: the EUR 1,200 CAC excludes (a) onboarding labour EUR 264–984 (the doc's own §3.3), (b) the install day, (c) the ~15–25% of signed deals that never go live or churn inside 90 days, whose full cost is absorbed by the survivors, (d) demo hardware and travel. Fully-loaded CAC for a single-site CEE café in years 1–2 is EUR 2,200–3,200
[estimate]. That puts SaaS-only at 0.65–0.95x and payments-attached at 3.5–5.1x, not 8.1x. Confidence: high on direction, medium on magnitude. The conclusion ("do not do SaaS-only") survives and gets stronger; the "8.1x" headline does not survive.
#C7. The 4.2-FTE 24/7 support floor is a theoretical minimum, not an operable one
- Claim (r09 §3.4): "168 hours/week needs 4.2 FTE bare."
- Correction: 4.2 assumes 40h/FTE, zero leave, zero sickness, zero training, and a lone person on a Sunday 03:00 shift. With 25 days statutory leave (CZ), ~8 days sick, and no lone-night-shift, genuine single-language 24/7 needs 5.8–6.6 FTE
[estimate]. r09's 5.5-FTE-at-500-sites number is therefore the coverage floor with essentially no throughput headroom, exactly as the doc says — but the doc then prices it as if 5.5 is achievable and sufficient. Confidence: high. Either budget 6.5 FTE or explicitly sell 07:00–01:00 coverage with a paid premium tier for 24/7, which is what I would do.
#C8. CZ+NL costs are modelled at CZ wages
- Claim (r09 §6.1, §6.3): S1 support at EUR 2,500/mo loaded; recommendation is "CZ + NL, with UA as the engineering and support base."
- Correction: a Dutch-speaking support FTE is EUR 4,200–5,200/mo loaded
[estimate], and you cannot serve NL restaurants from Kyiv in Dutch. At the model's own 5.5-FTE coverage floor, NL support alone is EUR 23–29k/month — more than S1's entire Y1 payroll of EUR 227k spread over 10 months — before the first Dutch euro of revenue. Adding NL also adds: a second VAT/entity setup, a Dutch DPA-grade privacy review, a second accounting-export format (Exact/Twinfield/AFAS, not Pohoda), a second acquirer, a second installer network, and a second set of hardware import/RMA logistics. CZ+NL is not one plan; it is two companies with a shared repository. Confidence: high.
#C9. "Buy a distressed 300–800-site vendor" cannot be an S1 move
- Claim (r09 §4.5, §0.5): "the strongest non-obvious move" at EUR 1,500–4,000/site.
- Correction: EUR 600k–1.6M exceeds S1's entire modelled peak capital need (EUR 850–950k). It is an S2/post-Series-A move only. Worse, the value framing is one-sided: you also buy their support obligations, a legacy Windows/on-prem estate, staff on local contracts, and a migration at 60–75% retention — i.e. you pay EUR 1.6M for ~250–300 retained sites plus a certification, or EUR 5,300–6,400 per retained site, which is within sight of orderbird's strategic EUR 9,300–10,000. Confidence: high. Keep the idea; move it to the S2 section and re-price it per retained site.
#C10. The G2 fallback ("pivot to CRM overlay") is not a viable fallback
- Claim (r09 §6.1 gate G2): if you cannot sell POS repeatably, "pivot to CRM/loyalty overlay on existing POS. 8 eng-months, EUR 25–45/site/mo, no fiscal exposure, no hardware, no 24/7."
- Correction: r07's own §4.1 shows that overlay economics are 3–37% gross margin via middleware and only work with direct connectors, which carry 0.35–0.6 eng-months/yr each of maintenance and existential platform risk. And the churn number is wrong: SMB marketing tools churn at 40–60%/yr, not POS's 20–30%, because cancelling a loyalty tool costs the restaurant nothing and cancelling a POS closes the restaurant. At 45% churn, EUR 45 ARPU, 70% GM, LTV ≈ EUR 840 against a EUR 600–1,000 CAC. That is not a pivot, it is a slower death with a smaller team. The honest G2 fallback is: sell the codebase and team to Nexi/Teya/Worldline/SumUp, or narrow to first-party online ordering (§6.3 below). Confidence: high.
#C11. r07's 3x identity-coverage gap is real on checks and overstated on value
- Claim (r07 §3): CRM-only gets 10–25% of checks; own-POS gets 45–70%; "that factor-of-three is the entire product difference."
- Correction: identified guests are not a random sample. Loyalty members visit 1.5–2.5x more often than non-members and spend 10–25% more per check
[known, retail/hospitality norm]. So 24% of checks identified is roughly 35–45% of revenue under management, and 52% of checks is65–75%. The value gap is **1.7–2.0x, not 3x**. Confidence: medium-high. The strategic conclusion (own the POS) still holds — but not on this argument. The argument that actually holds is C10's: CRM-only has no switching cost.
#C12. r06 "the CRM is the only defensible part" is backwards
- Claim (r06 §0): the CRM is the only defensible part of the product.
- Correction: every CRM feature in r06 is copyable in 9–15 months by any funded competitor, and r09 §1.3 admits the bundle is "a packaging wedge, copyable in 12 months by anyone who notices." What is not copyable is 800 sites whose staff are trained, whose menu is configured, whose printers are cabled, and whose card acceptance settles through your contract. Defensibility in this category is installed base × switching cost × payment contract, and the CRM is the reason the first 100 buy, not the reason the next 700 stay. Confidence: high. This reframing matters because it changes what you protect: protect the payment attach and the install quality, not the loyalty feature list.
#C13. Card-linked identity is high-quality and low-penetration
- Claim (r06 §2.1): card-linked auto-recognition = "near 100% of enrolled guests' card payments," listed as "the endgame."
- Correction: correct per-transaction, misleading per-base. EU consumer enrolment rates for card-linking in loyalty run 3–12% of members
[estimate]because it requires a deliberate "give us your card" act that most guests refuse. At 20,000 members that is 600–2,400 card-linked guests. Confidence: medium. Keep card-linking in v1.2, not v1.1, and never let it into an ICP or pricing argument.
#C14. Startup-cohort churn ≠ steady-state churn
- Claim (r09 §3.2): 20–30% gross logo churn, 4.0-year life used in LTV.
- Correction: the doc uses the optimistic end (25%) for a product that has never run a Saturday. First-cohort churn for an immature POS runs 35–50% in year 1 — this is the "one bad Saturday night = churn" mechanism the doc itself names in r07 §9.1. Model cohort 1 at 40%, cohort 2 at 30%, converging to 22–25% by cohort 4. Applied to S1's Y2 cohort, you lose 70–95 of the 620 exit sites the model retains at Y3. Confidence: high on direction.
#C15. r07's importer build order contradicts r09's beachhead
- Claim: r07 §9.4 sequences importers as Poster → iiko/Syrve → r_keeper (all UA-oriented), and ranks Dotypos/Storyous 4th, "defer to market entry."
- Correction: r09 recommends CZ as the beachhead. In CZ the two systems you are ripping out are Dotypos and Storyous, not Poster and r_keeper. If CZ is the beachhead, the Dotypos and Storyous importers are v1 items, not deferred ones. Confidence: high — this is an internal inconsistency between the two documents that will produce a wrong sprint plan. The migration importer is the best idea in the whole research set; point it at the right competitor.
#Underestimated effort
| Item | Doc figure | My figure | Why |
|---|---|---|---|
| Fully-loaded CAC, CEE single site, Y1–2 | EUR 1,200 | EUR 2,200–3,200 | + onboarding EUR 264–984, + install day, + 15–25% dead-deal absorption, + travel, + demo kit. AE at EUR 4,500/mo closing 5/mo = EUR 900 raw; at a 20–25% demo-to-close rate the funnel above it costs another EUR 900–1,400 |
| Onboarding hours/site | 16.5–41h manual / 10–24.5h with AI | 22–55h manual / 16–34h with AI | The table omits travel (2–4h round trip), the go-live shift (a second person on site for the first service), and the ~30% of sites needing a return visit. r01 also warns networking is 20–35% of the hardware bill and unbudgeted — remediation happens on install day |
| Install cost/site, CZ | not costed | EUR 550–1,400 (CZ) / EUR 1,100–2,200 (NL/DE) | 5–8 on-site hours × 2 people for a full-service go-live; NL/DE contractor rates EUR 55–95/h |
| Support FTE at 500 sites | 5.5 | 8–11 | Ticket rate: 0.7/site/mo is a mature-product number. New POS installs run 2–4 tickets/site/month for the first 6 months, decaying to 0.8–1.2. At a blended 1.4 and 500 sites you have 700 tickets/mo, not 350 |
| Support cost/site/mo at 500 | EUR 27.50 | EUR 40–55 (CZ wages) | Consequence of the above. Against EUR 69 SaaS ARPU that is negative gross margin on the SaaS line alone — the payments residual is not an upside, it is the only thing keeping the site solvent |
| On-call tax on engineering | not modelled | 15–25% of eng throughput from ~150 sites | A 3-engineer team carrying the dinner-service pager loses ~0.5–0.7 eng-months per calendar month. This is the actual mechanism by which small POS companies stall — velocity, not cash |
| S1 Y1 opex | EUR 75k | EUR 110–140k | Two-country legal/entity/VAT, insurance (Tech E&O + Cyber EUR 8–25k/yr — buy it before customer #1), device lab EUR 6–12k capex (r01/r04), travel for a field motion |
| S1 peak capital need | EUR 850–950k | EUR 1.5–1.8M | Stack C6 (CAC 2x), C7/support (1.8x), C14 (cohort churn), C8 (NL wages), and the doc's own open-question-4 sensitivity (EUR 1.3M at EUR 95 ARPU). "Bootstrapped" is not the right word for this plan |
| Chain sales cycle, 5–20 sites | 3–6 months | 9–14 months signed-to-fully-deployed | Chains run a one-site pilot for a full quarter before rollout. Your Y2 chain revenue lands in Y3 |
| Time to first full-price non-network customer | implied ~M7 | M11–15 | Y1 revenue of EUR 5.4k in the model is friends-and-design-partners revenue. Do not read it as validation |
| Hardware SKU rot | not modelled | 1–2 eng-months/yr forever | Sunmi/Elo refresh SKUs every 24–36 months; your certified matrix and install runbooks decay with them |
| Payments attach rate, Y3 | 45% | 30–40% blended | Nobody models that the merchant's existing terminal is on a 36–48 month acquirer lease with EUR 300–900 early-termination fees. Attach is realistically 70–85% on new openings and 20–30% on displacement wins. Your attach rate is mostly a function of your new-opening share |
#Over-engineering to cut
r06's 55 eng-months to CRM v1 is the number that breaks S1, and roughly 40% of it is enterprise-shaped work sold to a 3-site café chain. Concrete cuts:
| Component | Doc | Cut to | Saving | Rationale |
|---|---|---|---|---|
| Identity graph with probabilistic matching, Jaro-Winkler, union-find clusters, review queue | 4.0 | 1.2 | 2.8 | For 2–8 site CZ chains the entire matching problem is "same phone number." Ship deterministic phone + email + loyalty ID. Revisit at 500 tenants |
| Promo rules engine: DSL → portable bytecode, Rust/WASM core, per-platform evaluators | 5.0 | 2.0 | 3.0 | Counter-service needs ~8 rule types. Hardcode them behind a config schema with one shared JSON spec. Keep the 500-case golden corpus — that is the part that earns its keep |
| LAN Bloom-filter gossip of spent vouchers | ~0.8 (inside item 5) | 0 | 0.8 | r06's own arithmetic: cross-site double-spend loss is EUR 14/year on 500k vouchers. Building mDNS gossip — which r04 says will fail in production anyway — to save EUR 14/yr is indefensible |
| Journey/flow engine with branching + visual builder | 4.5 | 1.5 | 3.0 | Ship the six named flows as configurable templates. The visual builder wins RFPs you are not in yet |
| BTYD/CLV modelling | 1.5 | 0 | 1.5 | r06 admits it is junk below 6 months history / 500 repeat guests. Ship "trailing 12m spend + days since last visit" |
| Card-linked identity (PAR + 2 PSPs) | 2.5 (v1.1) | defer to v1.3 | 2.5 | See C13: 3–12% enrolment. Also gates on whether your PSP surfaces PAR at all |
| Full T3 multi-station LAN sync (r04) | 34 | 13 (T0 single-station) | 21 | For counter-service coffee/bakery/fast-casual this is not a compromise, it is the correct architecture |
| Aggregator connectors ×4 (r07) | 11–15 | 1.5 (HubRise, resold) | ~11 | HubRise at EUR 27–35/site has a first-class customer+loyalty model [verified]. Resell a "delivery module" at EUR 39–49/site: positive margin, one integration, and you can say "we connect to 100+ systems" on day one. Build Glovo natively only when HubRise's coverage costs you a named deal |
| Subscription billing & metering (r09 item 1) | 2.5 | 0.8 | 1.7 | Stripe Billing until you have multi-entity invoicing across three countries |
| Partner/reseller portal (r09 item 8) | 2.0 | 0 | 2.0 | The doc itself says "premature at <200 sites." Then do not put it in v1 |
| Growth analytics in-app (r09 item 10) | 1.5 | 0.5 | 1.0 | Postgres + Metabase. In-app analytics is a feature for your investors, not your customers |
| Total identified cut | ~50 eng-months |
One thing I would NOT cut, against the grain: the AI tier-0 support agent with device telemetry (r09 item 7, 3.0 eng-months). r09 credits it with 30–45% ticket deflection and stops there. The bigger prize is unmodelled: an agent that reads printer/terminal/sync telemetry and files the ticket before the restaurant calls converts the 24/7 coverage floor from "a human on a phone at 22:00" to "a human reviewing a queue at 09:00." That is the difference between 6.5 FTE and 3 FTE + escalation — EUR 9–11k/month at 500 sites, or ~EUR 120k/yr, for a 3 eng-month build. It is worth 10x AI menu ingestion and should be a v1 item, not a v1.5 item.
One thing I would cut that the docs treat as sacred: the promise of 24/7. Sell 07:00–01:00 local, 7 days, as standard, and 24/7 as a paid tier at +EUR 25/site/mo. Restaurants are not open at 04:00. The docs let the 168-hour figure drive the cost model without ever asking whether the customer is awake.
#Missing failure modes
F1 — The founder becomes the support rota and engineering stops. At 60–100 sites a 3-person team is on the pager every Friday and Saturday night. This is how small POS companies actually die: not out of cash, out of velocity. The first support hire must land at ~40 sites, not 150, and must be budgeted as a product cost, not an overhead. Neither r09's headcount table (0.5 support in Y1) nor r06/r07's effort tables reflect this.
F2 — Teya owns your competitors in your beachhead. See C4. Your obvious CZ payments referral partner owns Storyous and Dotykačka. Verify in month 1; if confirmed, CZ payments must come from Nexi, Worldline, ČSOB/KB via Global Payments, or Viva.com, and your payments-attach timeline slips a quarter.
F3 — The merchant's terminal is already on a 36–48 month lease. Early-termination fees of EUR 300–900 mean you cannot attach payments to a displaced site for up to four years. Nobody models this. It caps payments attach on displacement wins at 20–30% and makes new openings disproportionately valuable — which should reorder your entire lead-gen strategy toward permitting data, restaurant-supply distributors, and interior fit-out firms.
F4 — FX exposure on a EUR cost base with CZK/PLN/UAH revenue. You bill in local currency and pay AWS, fiskaly, Twilio and your acquirer in EUR/USD. A 10% CZK depreciation removes ~7 points of gross margin. Annual CPI-linked price indexation must be in the MSA from contract #1; CZ SMBs will resist it and you must not fold.
F5 — Staff turnover at the customer is the real support driver. Restaurant front-of-house turnover is 60–100%/yr. Every cashier who leaves takes your training with them, so your ticket volume is a function of their churn, not your site count. This is the strongest possible argument for extreme UI simplicity and for in-app onboarding a 19-year-old completes in 12 minutes. Budget it as a product feature (~1.5 eng-months), not a PDF. It is absent from all three documents.
F6 — The first big chain becomes the roadmap. r09 names "enterprise gravity" as a failure mode without a defence. The defence is a written rule: no bespoke work below EUR 60k of committed annual contract value, and every custom request is either priced as professional services at EUR 900/day or refused in writing.
F7 — Model A controllership forecloses the network product. r06 correctly picks per-tenant silos, but never draws the commercial consequence: with model A you can never offer a cross-brand consumer wallet, which is the only thing that makes guests actually join. In UA you will compete with UDS, which is a consumer network. Decide whether you are a tool or a network before you set pricing, because the answer changes the guest-facing brand, the app strategy and the DPA.
F8 — Uninsurable and unenforceable liability. Tech E&O does not cover fiscal fines levied on the software producer (Spain, per r03) and it does not reliably cover a customer's lost revenue if a local court declines to enforce your consequential-loss carve-out. A CZ B2B liability cap is not automatically enforceable against a Dutch customer under Dutch law. Get a local-law review per market, not one template.
F9 — Single-point engineering risk in a UA-based team. r09 gives war/staffing risk one clause. Give it a number: losing one of three engineers to mobilisation is a 33% capacity cut with no weeks-scale hiring pipeline and a bus-factor-1 on the offline sync core. Mitigate structurally: place engineer #3 or #4 outside UA, and require a written, tested handover doc for the fold/ledger code from month 6.
F10 — AI-written money code hits a maintainability cliff. Not mentioned anywhere. A 3-person team producing AI-assisted code at 2–3x normal volume with no senior reviewer hits a comprehension wall around 80–120k LOC, and the specific danger zone is r04's deterministic fold and r06's loyalty ledger. Mandate: anything that touches money is written twice — implementation by AI, property-based test suite by a human who did not write the implementation — or it does not ship.
F11 — Competitors respond and the packaging wedge closes. r09 admits the POS+CRM bundle is "copyable in 12 months by anyone who notices." Dotypos already prices SaaS down as card turnover rises — i.e. their model is already "free software if you process with us," which is the endgame you are heading toward. Your EUR 119–149 bundle is priced against a competitor whose effective software price for a card-heavy venue is near zero. This is not a hypothetical response; it is the current price list.
#What I would do instead
#6.1 The narrowest defensible beachhead
Czechia only. Prague + Brno. Counter-service coffee / bakery / fast-casual chains of 2–8 sites. One 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."
Why each constraint:
| Constraint | Reason |
|---|---|
| Czechia only, not CZ+NL | Zero fiscalization (0.25 eng-months per r03), one language, one wage level, one acquirer, one installer pool, everything drivable in 3 hours. C8 kills CZ+NL on support wages alone |
| Prague + Brno, ~2 districts first | Reference density beats reference count. 15 sites in Prague 7 outsells 15 sites scattered nationally, because restaurateurs ask their neighbours and because your installer's travel time collapses |
| 2–8 site chains, not single sites | r06's own power analysis: below ~1,500 treated guests campaigns are statistically undetectable, so the attribution engine — your killer feature — actively tells a single-site café to cancel. Chains also cost ~0.5x per site to support (they have an ops person) and pay for central reporting |
| Counter-service only | Removes table plans, course firing, seat-level splits, waiter handhelds. Collapses r04 from 34 to 13 eng-months and r08's surface list by a third |
| That specific JTBD | It is measurable, it is unavailable from Dotypos/Storyous, and it is the one thing the owner cannot solve with a spreadsheet |
Addressable reality check: ~30k CZ POS-relevant sites [verified-ish]; the segment (counter-service, 2–8 sites, Prague/Brno) is maybe 1,200–2,000 sites. Only 16–26% of any installed base is genuinely in play per year (new openings 8–12% + ownership changes 5–8% + acute-pain switchers 3–6%) [estimate], so your annually-contestable market in the beachhead is 200–500 sites. Winning 60–100 of them by M24 is a credible, checkable plan. Winning 620 sites across CZ+NL by M36 is not.
On "why would they rip out a working POS": they mostly would not, and you should stop trying. Restaurants switch at exactly four moments — new opening/refit, forced migration, ownership change, acute failure. Your entire Y1–Y2 pipeline should be built on the first and third: relationships with fit-out contractors, restaurant-equipment distributors, commercial landlords and the Prague trade-licence register. Displacement selling to a happy incumbent customer is a 6-month cycle with a 10% win rate; selling to a site that opens in six weeks is a 3-week cycle with a 40% win rate. Budget accordingly, and add one CAC line nobody models: buy out the incumbent's remaining contract term (CZK 3,000–15,000) and eat it.
Contrarian alternative worth more than r09 gives it — Belgium. r03 documents a forced GKS 2.0 migration wave with published cohort deadlines through 2028 and only 13 certified software suppliers. That converts "why would they rip out a working POS" from an objection into a legal requirement with a date on it. The EUR 20–50k / 6–12 month certification is the moat, not the obstacle — it is exactly the kind of cost that money and patience solve and that a competitor cannot AI-accelerate. r09 files this under "funded scenario only." For S2 specifically, I would rank Belgium above Germany: a smaller prize, but a dated, non-repeatable window with a 13-vendor field beats an open field in the most crowded market in Europe. If you take it, certification must start in Q1 of year 1 to catch the 2027–2028 cohorts.
On Ukraine: r09 dismisses UA as a proving ground because of the EUR 30–60 ARPU ceiling. That is the wrong lens. What matters is contribution margin against a cost base in the same currency. CZ: 5.5 FTE × EUR 2,500 ÷ 500 sites = EUR 27.50 = 40% of a EUR 69 ARPU. UA: 5.5 FTE × EUR 1,100 ÷ 500 = EUR 12.10 = 30% of a EUR 40 ARPU. Ukraine is structurally cheaper to serve than Czechia, has zero product certification, gives API access from monobank/PrivatBank within hours with free PRRO and free terminals (r02 [verified]), and blackout resilience is a differentiator nobody else builds. The real objections to UA are FX/war risk on revenue and that you cannot raise or exit on UA-only ARR — say those, not the ARPU ceiling.
#6.2 Phase 0 before any code (weeks 1–8, ~EUR 12–18k)
- 40 discovery calls with Prague/Brno 2–8 site counter-service operators. Capture: current POS, monthly spend, acquirer and rate, contract end date, and one open question — "what did you have to look up in a spreadsheet last month that your POS should have told you?"
- Written payments term sheets from Viva.com, Nexi, Worldline, Global Payments (ČSOB/KB), Nuvei, and Adyen. Threshold: ≥25 bps residual, no "we own the merchant" clause, no volume minimum you cannot hit by month 18. If none clears, stop — the economics do not exist and no amount of engineering fixes that.
- Confirm the Teya conflict (C4) with one direct call.
- Test price with money, not opinions. Put a real order form and a EUR 200 refundable deposit in front of 20 of the 40. Deposits, not LOIs.
- Kill gate: fewer than 8 of 40 will place a deposit at ≥EUR 89/mo → do not write code.
#6.3 If Phase 0 fails, the honest alternative is not "CRM overlay"
It is first-party ordering + loyalty for delivery-heavy concepts. Own the ordering channel (web + QR + Telegram/Viber mini-app) and you get 100% identity on 20–40% of revenue without touching the POS, plus an ROI pitch with a hard number: aggregator commission 25–35% vs your 0%. No fiscalization, no hardware, no 24/7 floor, no install day, a 2–4 month time to first revenue (r07 §9.1), and it is a legitimate Trojan horse into POS later. This is Flipdish's actual origin. Both r06 and r07 treat own-channel ordering as a data source rather than as the wedge; it is the wedge.
#6.4 Kill criteria
Written so that a third party can check them without asking you.
Month 6 — "does it survive a kitchen"
| Signal | Pass | Fail action |
|---|---|---|
| Sites live and unattended (no founder on site) through 4 consecutive Saturdays | ≥3 | Stop |
| Engineer manually repaired production data in the last 30 days | 0 times | Stop — not shippable |
| Median support tickets/site/week by week 6 post-install | ≤3 | >6 → stop |
| Full service run with WAN deliberately cut, reconciled to the cent | ≥1 demonstrated | Not demonstrated → the offline claim is marketing; descope to cloud-only and re-price |
| Signed deposits at ≥EUR 89/mo from non-friends | ≥10 | Stop |
| Written payments term sheet ≥25 bps, no merchant-ownership clause | ≥1 | Stop before writing any payments code |
Month 12 — "can we sell it repeatably"
| Signal | Pass | Fail action |
|---|---|---|
| Paying sites | 40–60 | <30 → stop |
| Share of sites from outside the founder network | ≥60% | <40% → the motion 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 (incl. onboarding + install) | <EUR 2,000 and falling QoQ | Flat or rising → the motion does not scale |
| Median discount off list price | <20% | >25% → your price is wrong, not your salesperson; re-baseline the model |
| Tickets/site/month | <1.2 | >2.0 → support cost model is broken; freeze sales and fix the product |
| Weekends covered without a founder or engineer on the pager | ≥1 full weekend | Never achieved → F1 is already happening |
| Median first-demo to go-live | <45 days | >90 days → the sales motion does not scale to a small team |
| Referenceable chain of ≥4 sites live | ≥1 | 0 → the ICP is wrong |
| Payments attach on Q4 new logos | ≥30% | <20% → the entire LTV thesis is unproven at M12, cut burn immediately |
Month 18 — "are the unit economics real"
| Signal | Pass | Fail action |
|---|---|---|
| Paying sites | 120–180 | <90 → wind down or sell the team |
| Contribution margin per site = ARPU − support − hosting − fiscal COGS − payments COGS | > EUR 25/site/mo | ≤0 → stop; more sites make it worse, not better |
| Net revenue retention | >95% | <85% → the product is not sticky and payments will not save it |
| Share of new logos from referral/channel | ≥25% | 100% founder-led outbound → CAC never bends; this is a job, not a company |
| Competitor response survived | ≥1 observed and survived | Lost ≥3 deals to a competitor's new loyalty feature → your only moat was packaging (C12) |
| Runway at current burn, no new revenue assumed | ≥9 months | <6 → raise now on worse terms or stop now on your own terms |
Hard stops, 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.
#6.5 The strongest honest case FOR doing it
I have been hard on the numbers. Here is what survives, and it is more than generic pessimism would allow:
- The payments annuity is real and the EU cap cuts both ways. IFR compresses interchange for you and for every competitor equally. Meanwhile CEE SMB street rates are 1.3–1.9% against a 0.51% + EUR 0.135 cost base. The gross spread available to a POS-with-payments in CZ/PL is 60–90 bps, which on a EUR 350k venue is EUR 1,600–2,600/yr — 2–3x the SaaS line, at ~100% incremental margin, recurring. No CRM-only company, no analytics company and no reservations company can touch it. r09's core claim is correct and it is the reason to do this at all.
- Nobody is defending CEE, and the defenders are structurally weakened. Toast, Square, SpotOn and Clover are absent. Every regional incumbent is acquirer- or PE-owned — Storyous→Teya, Dotykačka→Teya, orderbird→Nexi, Gastrofix→Lightspeed. That reliably produces frozen roadmaps, annual price increases, cut support and demotivated salespeople. A market full of locked-in, annoyed customers whose vendor stopped shipping is the single best substrate a fast small team can inherit, and it has a shelf life of maybe 4–6 years.
- Offline-correct loyalty plus holdout attribution is a genuinely differentiated pair, and the second half is nearly free. r06 item 11 is 2.5 eng-months. Walking into a renewal with "your loyalty programme generated EUR 4,120 of incremental gross margin last quarter, measured against a randomised control group" is an argument literally no CEE competitor can make. In a market of sceptical buyers, arriving with a number is disproportionately powerful — and it is also the honest answer to "is this worth the fee."
- The migration importer neutralises the hardest objection in POS sales. r07 §9.4 is right and undersold: 1.5–2.5 eng-months, no partner approval on public APIs, zero ongoing maintenance, and it converts "I'll lose 3 years of history" into a 30-minute onboarding step. Build the Dotypos and Storyous importers before launch (C15).
- A 3x labour-cost advantage on the two costs that do not scale. This business's fundamental problem is that support and field ops are linear. A UA/CEE cost base runs support at EUR 1,100–2,500/mo loaded against EUR 4,200–5,200 in Amsterdam or Berlin. Nobody headquartered in Western Europe can profitably serve a EUR 55/mo café. You can. That is the most durable structural advantage available in this category, and it is the one AI does not give your competitors.
- AI genuinely changes one thing the docs undercount: multi-country operating cost. Not the build — r09 is right that it is only ~30% on code and ~13% of burn. But localisation at EUR 3–6.5k for 8 locales (r08), AI-drafted support macros per language, and AI tier-0 with device telemetry collectively remove the permanent multi-country opex that historically stopped small European POS vendors at one country. That unlock did not exist in 2019 and it is the honest reason to believe a 2026 attempt can go where orderbird and Storyous did not.
- The exit is real, named and priced. orderbird → Nexi at EUR 130–140M for ~14,000 clients; Gastrofix → Lightspeed at ~EUR 80M; Storyous and Dotykačka → Teya. Every payments and POS strategic in Europe is buying distribution. A 1,500–3,000-site CEE POS with payments attached has 4–6 named buyers, which is a better exit landscape than almost any other vertical SaaS niche. At 60–80% founder ownership on EUR 1.5M of capital, a EUR 40–80M outcome is a life-changing result — and it does not require winning Europe.
The bet, stated plainly: you are not building Toast. You are building a EUR 1.5M-capital, 60–100-person-years attempt to assemble 1,500–3,000 CEE counter-service sites with payments attached, into a market whose incumbents have stopped shipping, and to sell it to Nexi, Teya, Worldline or SumUp in years 6–9 for EUR 40–90M. That is a good bet. It is not the bet r09 models, which is a EUR 850k-capital two-country plan reaching EUR 982k ARR — that one loses.