Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

E-commerce development for restaurants and takeaway

Online food ordering behaves like nothing else in e-commerce: a dish sells by service, drops off the menu when an ingredient runs out, returns the next day, and has to end up printed in the kitchen. This is the kind of work I take on in this sector.

Describe my issue Send a message

A menu is not a catalogue

In a standard shop a product either exists or it doesn’t, and its stock counts down to zero. On a menu, availability is a function of the service slot: the dish of the day only exists at lunch, the evening set menu opens at a fixed hour, and a missing ingredient pulls a dish mid-service before it reappears tomorrow. Modelling that as a stock quantity produces wrong states and orders the kitchen cannot fulfil.

Options make the confusion worse. Cooking level, side, sauce, extras: these are constrained choice groups — one compulsory choice here, three at most there — and each can change the displayed price. Treated as CMS variants, they cause a combinatorial explosion of references by the second menu category. What you need is an option model attached to the dish, with its own minimum and maximum rules, not a separate product per combination.

What breaks with a generic ordering module

  • Availability is stored as a quantity, when it actually depends on the service and the day of the week.
  • The checkout accepts a slot that is already full and only rejects it after payment, once the kitchen sees the order.
  • Preparation time is fixed, when it varies with the contents of the basket.
  • The delivery area is entered as a list of towns, when it is really a shape drawn around the outlet.
  • Delivery charges are assigned to a single VAT rate, which skews the bill as soon as a bottle joins the basket.
  • Allergen information sits in a footnote instead of being data attached to each dish.
  • Orders arrive by email: nobody sees them during a busy service.

Three rates on one bill, and allergen data per dish

A single bill routinely mixes food for immediate consumption, items meant to be eaten later, and alcoholic drinks, which do not share the same rate. None of the three CMS platforms I work with splits delivery charges across those rates on its own: by default the shipping line carries one rate and the document handed to the customer becomes inaccurate. So you need a split in proportion to what is actually in the basket, applied when the total is computed, and a document template that shows the breakdown rate by rate.

Allergens follow a similar logic. The information is mandatory, it belongs to each dish, and it changes whenever a recipe or a supplier changes. Written into the description, it cannot be found and cannot be corrected in bulk. Structured as a dish attribute with a closed list of values, it can be filtered, shown at the point of choice, and updated in one place.

How I work on an online ordering project

  1. Start from the real menu

    I work from what already exists, printed menu or till software: dishes, option groups, availability rules per service. That document drives the data model, not the other way round.

  2. Build the slot engine

    Maximum capacity per time band, closing days, preparation time computed from the basket, delivery area drawn on a map rather than listed. The slot is held before payment and released if payment fails.

  3. Make the kitchen hand-off reliable

    Automatic printing or a production screen, an acknowledgement of receipt, and a queue that replays tickets after a printer outage. A paid order that never reaches the kitchen is lost twice.

  4. Name the master record for the menu

    The same dish lives on the site, on the till and on the delivery platforms, each with its own item reference and identifiers. I pick one master source and build the syncs around it, rather than letting three manual entries drift apart.

Related work

Frequently asked questions

Can dish options be handled with CMS variants?
Technically yes, until the number of combinations becomes unmanageable: two groups of three choices are enough to multiply references and slow the back office down. I prefer an option model attached to the dish, with a minimum rule, a maximum rule and a price impact per choice.
How do you stop a full slot being sold?
By holding the capacity the moment the customer picks the slot, and releasing that hold if payment does not complete. The check has to happen before the money is taken: refusing afterwards means refunding and phoning the customer mid-service.
Does the site need syncing with the delivery platforms?
As soon as the same menu lives in several places, yes. Each platform keeps its own item reference and identifiers, so you need a mapping table and a regular sync, otherwise prices and unavailable items drift apart within days.
How are allergens handled on a dish page?
As product data with a closed list of values, attached to the dish and repeated on the page, in the basket and on the preparation ticket. A general note at the bottom of the menu does not meet the information duty and goes stale at the first recipe change.
What if the kitchen printer fails during service?
You need a persistent queue and a fallback production screen: unprinted tickets stay pending and replay once the printer is back. Without that, an outage quietly removes orders that have already been paid for.

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

type
existant
stack (facultatif)
utilisateurs (facultatif)
echeance (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Related pages