Independent UK restaurants hand 14% to 30% of every online order to Deliveroo, Uber Eats and Just Eat. On £10,000 a month of online sales that is £1,400 to £3,000 leaving the business every month — recurring, forever, and very often on customers the venue introduced itself.
We have published our full product and engineering proposal for Vesopa Order: a commission-free ordering channel built directly into the till our venues already run. Native apps for Android and iOS, scan-to-order QR codes at the table, and every order landing straight on the till.
| Download the full plan — PDF, 13 pages |
Why we are building it
The competitor here is not another till vendor. It is the aggregator commission that every restaurant owner already resents — and it is the number this product is sold against.
Here is what a venue doing £10,000 a month of online orders actually pays, by route:
| Route | Monthly cost | Per year |
|---|---|---|
| Uber Eats (they deliver) | £3,000 | £36,000 |
| Deliveroo (typical) | £2,700 | £32,400 |
| Just Eat (self-delivery) | £1,400 | £16,800 |
| Vesopa Order | ≈£200 + subscription | ≈£2,400 + subscription |
Even measured against Just Eat's cheapest tier, the venue keeps roughly £14,000 a year. A Vesopa venue ordering through its own app and its own QR codes pays card processing and its existing Vesopa subscription. That is the entire pitch — and it is a pitch a salesperson does not need to be technical to win.
We are not replacing the aggregators. They bring discovery — new customers who did not know the venue existed — and we cannot. What we replace is the repeat order: the regular who already knows the venue and is being charged 27% to reorder from it.
Three channels, one till
All three sell the same menu, price it with the same rules, and land in the same place on the till. They differ only in how the customer arrives and how the food leaves the building.
Table ordering (QR)
The customer scans the QR code on their table, the menu opens in their phone browser with no app to install, and the table number comes from the code rather than being typed. They pay online, or add it to the table tab and settle at the counter. The order joins the existing bill on the floor plan.
Takeaway and collection
Ordered in the Vesopa app or on the venue's own site, with a collection time drawn from real kitchen capacity. Always paid up front, so there are no no-shows, and a push notification when it is ready. This is the highest-margin online order there is: no courier, no commission.
Delivery
The address is checked against the venue's delivery zone, the fee is set by zone or distance, and the order is assigned to a driver from the till. The customer follows the status; the driver marks it delivered.
The whole app is judged on one number: how many taps from opening it to having paid. The target is a repeat customer reordering their usual in under fifteen seconds, and every screen is arranged around that. Which is why "Your usual" sits first on the menu, sold-out items are greyed rather than hidden, and Apple Pay or Google Pay is the primary button — wallet payment roughly halves checkout abandonment against typing in a card number.
Eight weeks, in five phases
| Phase | Weeks | What it delivers |
|---|---|---|
| 0 — Foundations | 1–2 | Order channels in the data model, server-side pricing, live push to the till, the till Orders tab |
| 1 — QR table ordering | 2–4 | Scan-to-order mini-site, per-table QR codes, pay online or at the counter. First venue live at week 4. |
| 2 — Mobile apps | 3–7 | Android and iOS apps for takeaway, accounts, payments, tracking, push. Submitted to both stores at week 7. |
| 3 — Delivery | 5–7 | Delivery zones, fees, driver dispatch view, live status for the customer |
| 4 — Own domain and hardening | 7–8 | The venue's own domain and branding, trial-venue support, store-review buffer |
The phases overlap deliberately — that is what makes eight weeks possible, and it is the plan's main assumption. Phase 2 begins once phase 0 has settled the API it depends on, so the app and web tracks then run side by side rather than end to end. Store review and venue menu onboarding run alongside and are not development weeks.
Most of this is extension, not invention
We already own the hard part. Vesopa runs the till, the menu, the pricing rules, the floor plan and the card payments. What we do not yet own is the moment the customer decides what to eat — and that is what this adds.
- The menu and catalogue already exist. The ordering menu is the till menu, so there is one place to change a price.
- Multi-venue tenancy already exists. Every read and write is scoped per venue, and the ordering API inherits that for free.
- The floor plan already exists. Every table has an identity, so a QR code is a signed token for a row that is already there.
- The live socket to the till already exists. It pushes catalogue changes today; we add order events to the same channel.
- Kitchen ticket printing already exists, including a layout that prints a TAKEAWAY header.
The genuinely new work is the customer-facing front ends, and making the order flow run towards the till as well as away from it.
Where Vesopa earns
- Subscription uplift. Ordering is a paid module on top of the existing per-till subscription — predictable, recurring, and priced off money the venue is already saving.
- Payment processing. Online orders route through our existing card relationship, on the same rails as the card machine.
- Retention. A venue whose customers have its app installed and its QR codes on the tables does not change till vendor casually.
There is a defensive case too. Square, Zonal, Lightspeed and Toast all ship online ordering with their tills. A UK EPOS vendor without it is increasingly disqualified from tenders before the demo — so this is as much about not losing deals as about winning new revenue.
What is in the document
The full proposal runs to fourteen pages and does not skip the uncomfortable parts. It covers:
- The commercial case in detail, with the published aggregator rates it is measured against
- The App Store publishing decision — one Vesopa app with a venue picker, and why Apple's guideline 4.2.6 rules out the obvious alternative
- Screen-by-screen product design for the consumer app, and what is explicitly out of scope
- The architecture, and which existing systems are extended rather than rebuilt
- Security, GDPR exposure and how pricing stays identical between the app and the till
- A ranked risk register — twelve risks, their impact, and what we do about each
- The four decisions needed in week one, and the two items with external lead times that sit on the critical path
| Read the full proposal — PDF, 13 pages |
Direct link if your browser does not open the download.
Vesopa Order — Product and Engineering Proposal, 28 July 2026. Commission figures are published ranges for UK independents as of July 2026 and vary by contract; they are indicative and not quotations. The eight-week schedule is a proposal and rests on the assumptions set out in the document. App screens are indicative layouts, not final design.
