Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · restaurant sprint
Your own ordering and bookings, off the aggregators in 30 days.
Your menu, your bookings, your customer data, your margin. Commission-free ordering that belongs to the restaurant instead of a platform.
Quick answer
A restaurant app with online ordering, table reservations and payments can be designed, built and live in 30 days for a fixed $2,500. That covers the customer menu and ordering flow, bookings, payments, and a kitchen or front-of-house view. POS integration depends on your POS and is scoped separately.
The plan
Day one to day 30, written down.
You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.
- 1
Days 1–3
Scope lock
Service model first: dine-in, pickup, delivery, or all three, and how bookings actually run on a Saturday night. Menu structure and modifiers get agreed here too.
- 2
Days 4–12
Design
The menu and ordering flow, designed for someone standing outside deciding where to eat. Then reservations and the staff-facing views.
- 3
Days 13–24
Build
Menu, cart, checkout, payments, reservations and the order pipeline into the kitchen. Staging goes up early so your team can place real test orders.
- 4
Days 25–28
Service test
Run it through an actual service — orders landing during a busy hour is a different test from orders landing during a demo.
- 5
Days 29–30
Launch
Payments live, QR codes printed if you want them, staff trained, and your ordering link on your own site and socials.
What $2,500 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Restaurants losing a third of every order to an aggregator
Groups with several sites and no single place to see bookings
Owners who have never once been given their own customer list
Real situations
Five ways this shows up, and what actually fixes it.
Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.
Situation 1
Losing a third of every order to an aggregator
A restaurant relies on delivery aggregators for most of its online orders and watches roughly a third of each ticket disappear in commission, even from repeat customers who already know the restaurant.
Commission-free ordering for pickup and delivery captures the regulars directly — the aggregator stays useful for new-customer discovery only.
Situation 2
Several locations, no single view of bookings
A restaurant group with multiple sites has no shared way to see reservations, covers or orders across locations, so every site effectively runs its own disconnected process.
Multiple sites run under one dashboard, each with its own menu, hours and zones, giving ownership a single view across the group.
Situation 3
Never once been given the restaurant's own customer list
Years of orders have gone through aggregators that keep the customer relationship — names, contact details, order history — entirely to themselves.
Every order builds a real customer list in the restaurant's own database, which is arguably the single biggest reason to stop routing regulars through a platform.
Situation 4
A busy Saturday night breaks the current reservation process
Table bookings are managed by phone and a paper diary, and a busy Saturday reliably produces double-bookings or a hostess stand that can't keep up.
Table reservations with covers, sittings and turn times are built around what actually happens on the busiest night, not a quiet Tuesday.
Situation 5
Wants QR table ordering but isn't sure it fits the service style
A restaurant owner has seen QR ordering elsewhere and wants it, but hasn't confirmed whether it actually suits their style of service.
QR table ordering is included when it fits, and the scoping call is explicit about when it doesn't — it works for casual dining and badly for fine dining.
The honest part
When 30 days is the wrong answer.
A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.
Deep two-way integration with an unusual or legacy POS. Some integrate cleanly, some genuinely do not, and I will check yours before quoting rather than after.
Full inventory and stock-depletion accounting across multiple kitchens — a different system with a different number.
Loyalty programmes with tiers, points economies and partner redemption. A simple repeat-customer view fits; a points economy does not.
Inside the 30 days
- Digital menu with photos, modifiers, allergens and sold-out toggles
- Ordering for pickup and delivery, with your own zones and fees
- Table reservations with covers, sittings and turn times
- Payments and optional deposits on bookings, through Stripe
- A kitchen or front-of-house view for incoming orders and covers
- QR codes for table ordering, if that suits your service
- Your customer list and order history — yours, not a platform's
- Source code, design files and 30 days of support at handover
Quoted as one number before day one. A week running long is mine to absorb.
Outside the line
- Deep two-way integration with an unusual or legacy POS. Some integrate cleanly, some genuinely do not, and I will check yours before quoting rather than after.
- Full inventory and stock-depletion accounting across multiple kitchens — a different system with a different number.
- Loyalty programmes with tiers, points economies and partner redemption. A simple repeat-customer view fits; a points economy does not.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
It replaces the commission on customers who already know you, which is most of the value. Aggregators are a discovery channel worth keeping for new customers; what you should not be doing is paying 30% on the regulars who would have ordered from you anyway.
Other sprints
30 days from now, this could be live.
A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.