Development Agency
Contact Sign in Get a project quote

Service

Online food ordering development

For takeaway and restaurant owners, dark kitchen operators and multi-outlet brands who want their own ordering channel built around their kitchen's real capacity, delivery area and drivers, rather than renting a marketplace that owns the customer and takes a cut of every order.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A takeaway on a Friday night is a capacity problem dressed as a menu.

  • Orders arrive from two marketplace tablets, the phone and the counter at once, and nothing coordinates them.
  • The kitchen accepts every order because the tablets make it easy to say yes, so the quoted forty minutes becomes eighty, the drivers are sent out with three cold bags, and the one-star reviews land on the marketplace page the business does not control.
  • The marketplace holds the customer's name, address and order history; the business sees a ticket and pays commission on it.

Where it gets harder

Delivery zones are a guess.

  • A postcode three miles out is accepted because the map on the tablet does not know about the river, and the driver loses half an hour.
  • Modifiers go wrong: extra sauce on a dish that cannot take it, a half-and-half pizza the till cannot represent, a meal deal that the kitchen reads as three separate items.
  • A brand with four outlets routes by whichever tablet the customer happened to find, so one kitchen drowns while another is quiet.
  • Refunds for a missing side are a phone call, a note on the pad and an argument with the marketplace a week later.
  • Promotions are whatever the marketplace is running this month, at the business's expense.

Scope of the service

What the build covers

A custom online ordering build normally covers:

  • An own-brand ordering site and Where wanted, an app
  • A menu with modifiers Option groups, upsells and meal deals that the kitchen can actually make
  • Delivery zones drawn on a map with minimum order and fee per zone
  • Collection and delivery time slots whose capacity is set By the kitchen in orders or dishes per window
  • An order pipeline from received through preparing Ready, out for delivery and delivered, with the customer told at each step
  • A kitchen display that shows what to cook next
  • Driver assignment with a driver view on a phone
  • Promotions and codes under the business's own rules
  • Routing between outlets by address or by load
  • Refunds and partial refunds through the payment provider without a phone call

How discovery works

Discovery works through a Friday service with you: how many orders the kitchen can really take in a fifteen-minute window, where the delivery boundary actually is, whether drivers are employed, self-employed or a third-party service, how marketplace orders will coexist with own orders in the kitchen, what the till or printer needs to receive, and which promotions have earned their keep. Each answer becomes a named workflow stage in the scope document.

  1. Order
  2. Payment
  3. Kitchen
  4. Ready
  5. Delivery or collection
  6. Complete. Where an existing point of sale must stay
  7. The scope names the integration point rather than replacing it

Deliberately out of scope

  • Table bookings, stock and purchasing, payroll and marketplace listings themselves

When the scope grows

Scoping scenario

A brand with five kitchens across a city wants one ordering site that routes each order to the nearest outlet with capacity in the requested slot, falls back to the next outlet when one is overloaded, pools drivers between two of the kitchens that sit close together, and reports margin per outlet after delivery costs. That is a materially different build from a single takeaway that wants to stop paying commission, and the scope document says which one is being built.

Deliverables

What you receive

  • Discovery notes from a walk-through of a peak service, from order to driver return
  • A written scope document naming each stage from order to complete, with what is out of scope
  • Design of the customer ordering flow, the kitchen display and the driver view, checked on the devices each will use
  • The build, deployed to your hosting or ours
  • Migration of menus, modifiers and customer records from current marketplace exports or the old site, where relevant
  • Training for managers, kitchen and drivers, with a one-page guide for capacity and slot settings
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, current menus, marketplace exports and a look at the till, printers and how drivers are run today.

    Project stage: Onboarding

  2. Planning

    Discovery with the owner, a shift manager and the kitchen lead; the scope document and milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the ordering flow, the kitchen display and the driver app, checked on a phone, a kitchen tablet and a driver's handset.

    Project stage: Design

  4. Development

    Built in stages: menu and zones first, then slots, capacity and payment, then kitchen display, drivers, routing and refunds.

    Project stage: Development

  5. Client review

    The kitchen runs a test Friday with staff orders alongside the marketplace tablets and tells us where capacity, zones or tickets are wrong.

    Project stage: Client review

  6. Revisions

    Capacity rules, zone boundaries, modifier logic and ticket layout are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Menus loaded, zones confirmed, printers connected, payment and refund callbacks tested, driver handsets set up, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The business takes its own orders; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card payment providers for checkout, refunds and partial refunds
  • Kitchen receipt printers and existing point-of-sale systems
  • SMS and push notification providers for order status updates
  • Third-party delivery fleets where the business does not run its own drivers
  • Mapping services for zone boundaries and driver routing
  • Accounting software for daily sales and refund reconciliation

How we would approach it

Worked example

Concept demo

A two-kitchen takeaway that stopped overselling Fridays

The situation

A takeaway with two kitchens a mile apart wanted own-brand ordering that never quoted a time the kitchens could not keep.

Why it is a custom build

This needs a custom build rather than a white-label ordering app because capacity is the central object: every slot, routing decision and quoted time derives from what the kitchen can produce, and the manager has to be able to change that number while the fryers are on.

The scope we would propose

  • Each kitchen sets a capacity in dishes per fifteen-minute window that the manager can lower mid-service
  • An order is routed to the kitchen whose zone contains the address and which has capacity in the requested slot, otherwise the customer is offered the next slot with space
  • Drivers are assigned from a shared pool with a phone view of their next three drops
  • Marketplace orders are keyed into the same display so the capacity count includes them

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of outlets and whether orders are routed between them
  • Delivery, collection or both, and how zones and fees are set
  • Own drivers, a third-party fleet or a mix, and whether a driver app is needed
  • How capacity is counted per slot and whether marketplace orders share it
  • Modifier and meal-deal complexity in the menu
  • Connection to an existing till or kitchen printer
  • A native app in the app stores in addition to the ordering site
  • Promotion rules, loyalty and refund workflows
  • Hosting choice: your own hosting or ours

Start from a package

Online ordering package

Own-brand online ordering with modifiers and upsells, delivery zones and fees, slots capped by kitchen capacity, a kitchen display, driver assignment, order status updates, promo codes and refunds without a phone call.

Custom build
View the package

FAQ

Frequently asked questions

Would the package do, or do we need a custom build?

A single outlet with delivery and collection, its own drivers and standard modifiers is usually covered by the online ordering package through configuration. A custom build is the honest answer for multi-outlet routing, shared driver pools, a two-way till integration or unusual capacity rules. Discovery is where we tell you which.

Can we keep taking marketplace orders alongside?

Yes. Most businesses keep the marketplaces for new customers and move regulars to their own channel. The scope can include keying marketplace orders into the same kitchen display so capacity is counted once, and where a marketplace offers an order feed we can connect it.

How does the system know how busy the kitchen is?

The kitchen sets a capacity per time window, counted in orders or dishes, and can lower it during service. Slots fill against that number and the ordering site stops offering a window once it is full, so the quoted time is one the kitchen can keep.

Do we need our own drivers?

No. The build can assign to your own drivers through a phone view, hand orders to a third-party fleet, or do both by zone or by time of day. Which applies is decided in discovery.

Who owns the customer data?

You do, along with the source code. Customer records, order history and the menu are handed over at delivery and can be exported at any time; hosting and maintenance are optional and separately agreed.

Get a project quote for online food ordering software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences