An online ordering system for restaurants that keeps the margin in your kitchen

What is an online ordering system for restaurants, and does a Dutch takeaway need one?

An online ordering system for restaurants is the menu, basket, checkout and kitchen link that lets guests order food from you directly, on your own domain or in your own app. For a Dutch takeaway that already gets steady repeat business, it is usually worth having, because each repeat order placed there carries no marketplace percentage.

The idea is simple, but the pieces matter. A guest opens your site, picks a pizza with extra toppings, enters a postcode, sees whether you deliver there and at what fee, pays with iDEAL, and gets a confirmation. Seconds later a ticket prints in the kitchen. That chain has to work every Friday at 18:30 when half your street is hungry at once.

Who benefits most? Restaurants where a large share of orders come from the same neighbourhoods week after week: pizzerias, snackbars, Surinamese and Turkish takeaways, sushi counters, poké bars and dark kitchens running two or three menu brands from one kitchen. If you mostly serve tourists who will never return, the maths is weaker.

• You need it when repeat customers already ask for your number or come back through a delivery app every week.
• You can wait when you do fewer than a handful of delivery orders a day and have no one to drive.
• You need something bigger when you run several branches with separate menus, stock and staff screens; that is a custom build.

If you are unsure where you sit, send us an export of last month's platform orders and we will talk it through before quoting. For the wider picture of shop builds in the Netherlands, the webshop cost guide is a good companion.

When does your own online ordering system for restaurants pay for itself?

It pays for itself once the commission you no longer pay on moved orders is larger than the build and running costs. You can work that out from your own platform invoices in ten minutes, without trusting anyone's marketing numbers, including ours.

Take the commission percentage from your contract or monthly statement, not from an article. Multiply it by your average basket to get the commission on one typical order. Subtract what your own payment provider will charge per iDEAL transaction. What is left is your saving per order you move to your own channel. Divide the one-off build price by that saving and you have the number of moved orders needed to break even. Add hosting and, after the free months, the care plan to the monthly side.

• Commission per typical order = your contract percentage × your average basket.
• Saving per moved order = commission per order − your own payment fee per order.
• Break-even orders = build price (from US$750) ÷ saving per moved order.
• Monthly running cost = hosting + payment account fees + care plan (from US$120/mo after two free months).

Two honest caveats. First, not every marketplace order will move: guests who found you by browsing the app may keep ordering there, and that is fine. Second, if the platform also supplies the driver, your own channel needs your own driver or a pickup-only offer, and driver costs belong in the sum. We would rather you run these numbers before paying us than discover afterwards that the saving was never there.

Should you leave Thuisbezorgd or Uber Eats completely?

Usually not. For most Dutch takeaways the sensible model is hybrid, with an online ordering system for restaurants running next to the apps: stay listed on the marketplaces for discovery, and give every guest a reason to order directly next time. Thuisbezorgd and Uber Eats are strong at putting you in front of people who have never heard of you; your own channel is stronger at keeping the ones who liked your food.

How do you move people across without breaking platform rules? Read your marketplace contract first, because some agreements limit what you may put inside the delivery bag or in messages to platform customers. Within those limits, common tactics are a menu card with a QR code for guests who come to the counter, a sticker on pickup bags, the ordering link on your Google Business Profile, and a small first-order perk for ordering direct.

Some owners also set slightly different prices per channel to reflect the different cost of each. Whether that is allowed depends on your agreement with each platform, so check it with them or a lawyer; we build whatever pricing you decide on, but we do not advise on contract terms.

What should an online ordering system for restaurants include?

At minimum, an online ordering system for restaurants needs a fast menu with options, a basket that recalculates correctly, a checkout with iDEAL, clear delivery or pickup rules, allergen information, confirmation messages and a reliable kitchen notification. Everything else is optional and should be added only when it earns its place.

Menu options deserve more thought than owners expect. A pizza has a size, a base, removable toppings and paid extras. A poké bowl has a base, a protein, up to four toppings and a sauce. A menu deal combines a burger, a side and a drink with swaps allowed. We model these as option groups with minimums and maximums, so a guest cannot check out a bowl with no protein or a deal with two drinks.

• Opening hours per day, holiday closures and a ‘kitchen busy, orders paused’ switch for the manager.
• Pre-ordering for a later time slot, with a cap on orders per quarter hour so the kitchen is not flooded.
• Sold-out toggles per item that staff can flip from a phone.
• Pickup and delivery with separate minimums and fees.
• Tip option for drivers, shown after the basket total.
• Order history and one-tap reorder for logged-in guests; guest checkout for everyone else.
• A simple dashboard: today's orders, refunds, top dishes, new versus returning guests.

What we deliberately leave out of a first version: table-side QR ordering, kiosk screens and complex marketing automation. Those are useful for some restaurants and can be added later, but they slow down launch and rarely drive the first month's direct orders.

How does iDEAL checkout work in a restaurant ordering system?

In an online ordering system for restaurants, iDEAL sends the guest from your checkout to their own banking app to approve the payment, then back to your order confirmation. For Dutch guests it is the familiar way to pay online, so an ordering site without it loses orders at the last step.

Behind the scenes, you open a merchant account with a payment provider that supports iDEAL and cards, in your restaurant's name. We connect your ordering system to that provider. The important part is the webhook: a message from the provider to your server confirming the payment status. An order should only print in the kitchen once that confirmation arrives, never just because the guest came back to the thank-you page. Otherwise you will one day cook for someone who closed the banking app without paying.

We also build the unhappy paths. A payment that stays open is cancelled after a set time and the basket is kept so the guest can try again. A missing item can be refunded in part from the dashboard. Cash on delivery or pin at the door can be offered as an extra option if your drivers carry a card terminal.

Payment money goes from the provider to your bank account on the provider's own schedule; it never passes through us. For the full technical story, including recurring payments and in-app rules, see the iDEAL integration page.

How do postcode-based delivery zones work?

In an online ordering system for restaurants, a delivery zone is a set of postcodes with its own minimum order, delivery fee and estimated delivery time. Dutch postcodes are four digits plus two letters, which makes them precise enough to draw zones street by street when you need to.

Most takeaways start with ranges of four-digit areas: the digits around the restaurant as zone one, the next ring as zone two with a higher minimum and fee, and everything else refused politely with a pickup suggestion. When a canal, ring road or railway makes a nearby area slow to reach, you can exclude single six-character postcodes inside an allowed range. The checkout checks the postcode before payment, so nobody pays for an order you cannot bring.

A map radius sounds simpler, but in Dutch cities a straight-line distance often ignores bridges, one-way streets and pedestrian zones. Postcode lists match how your drivers actually think about the city, and staff can edit them in the dashboard without calling us.

• Zone name, postcode ranges and single-postcode exceptions.
• Minimum basket, delivery fee and free-delivery threshold per zone.
• Estimated time per zone, raised automatically when the kitchen is busy.
• Delivery hours per zone, for example the outer ring only until 21:00.

Kitchen printers, tablets and POS: where do the orders go?

Whatever online ordering system for restaurants you choose, orders should arrive where the cooks already look, in a format they can read in two seconds. For most small kitchens that is a network receipt printer; for others a tablet screen with bump buttons; for restaurants with a cash register system, a direct push into the POS.

A network printer on the kitchen Wi-Fi or cable receives each paid order and prints a ticket: order number, pickup or delivery, requested time, items grouped by station, options in capitals, allergen remarks at the top. A second copy can print at the counter for the driver. If the printer is offline, the dashboard shows an alarm and the order stays visible on screen, so nothing silently disappears.

POS hand-off depends entirely on your POS vendor. Some offer an open API or an import format, in which case we send orders straight into the register with the right product codes. Others keep their systems closed; then the practical route is the printer or tablet, and staff ring up the order once. We check your POS documentation before quoting and tell you plainly which of these routes is realistic.

Allergen information on your online menu: what does the NVWA expect?

Guests must be able to find allergen information for your dishes before they order. The Dutch food safety authority NVWA says on its allergen guidance page that a webshop must state which allergens its products contain, or give a telephone number where customers can ask.

The NVWA lists 14 allergens that businesses must always inform customers about: cereals containing gluten, crustaceans, eggs, fish, peanuts, soy, milk including lactose, tree nuts, celery, mustard, sesame, sulphur dioxide and sulphites, lupin and molluscs. For gluten and nuts, the NVWA asks you to name the specific cereal or nut rather than a general warning.

In the online ordering system for restaurants we build, allergens are stored per dish and per option, because a topping can add an allergen the base dish does not have. The dish page shows icons with text labels, the basket repeats them, and the kitchen ticket prints any remark a guest types, such as “no sesame, allergy”. We can also add a visible line with your phone number for allergen questions.

What we do not do: decide which allergens your recipes contain. You or your chef supply the allergen list; we make sure the system displays it correctly everywhere. For formal questions about your obligations, speak with the NVWA or a food-law adviser.

Loyalty and reorder via WhatsApp: how does it work without spamming guests?

Guests opt in at checkout to receive order updates on WhatsApp, and optionally occasional offers. From then on your system can confirm the order, say when the driver leaves, and later send a reorder link for their usual meal. Without that opt-in, no marketing messages go out.

Order updates travel through the WhatsApp Business Platform using message templates that Meta reviews before use. Promotional messages need their own permission and should be rare; a message every Friday at dinnertime will get you blocked quickly. A loyalty rule works well alongside: every tenth order earns a free side, and the WhatsApp message tells the guest when they are one order away.

We also build the simplest version for owners who are not ready for the platform: a “share my order on WhatsApp” button and a click-to-chat link to your business number. It costs almost nothing extra and still keeps the conversation with you instead of a marketplace inbox.

• Checkout checkbox for order updates, separate checkbox for offers.
• Templates for confirmation, driver on the way, and delayed order.
• Reorder link that refills the basket with the guest's last order.
• Easy stop: a reply of ‘stop’ removes the guest from offers.

More detail on bots and templates lives on the WhatsApp chatbot page for Dutch businesses.

Ordering website, web app or native app: which should a restaurant build first?

Build the website version of your online ordering system for restaurants first. Every guest can open a link without installing anything, Google can index it, and it is the cheaper of the two. Add a native app once you have enough regulars who would use it weekly.

A mobile-first ordering site can behave much like an app: it remembers the address, offers reorder, and can be added to the home screen. What it cannot do as well is send reliable push messages on every phone, show in the App Store and Google Play, or feel as smooth as a native app on older devices.

A branded app built in Flutter for Android and iOS makes sense for restaurants with a strong following, multiple branches or a loyalty scheme that people check often. It is published under your own Google Play and Apple developer accounts: Google Play charges a one-time US$25 registration fee and the Apple Developer Program costs US$99 a year, both paid by you.

Thinking about an app? The app development page for the Netherlands compares cross-platform and native builds in more depth.

How much does an online ordering system for restaurants cost?

With BtechWaleTech an online ordering system for restaurants starts from US$750 for the website version, from US$600 for Android and iOS apps, and from US$900 for multi-branch custom software. Care after the two free months starts from US$120/mo. All are starting prices; your written quote lists each part.

What moves the price up or down? The number of menu option rules, how many branches share or split the menu, whether we integrate with a POS or just print, loyalty logic, and how many languages the menu needs. A single pizzeria with 60 dishes and a printer sits at the lower end. A group with three brands from one kitchen, separate menus per brand and a central stock view sits much higher.

Costs that are not ours: the payment provider's transaction fees, hosting, your domain, a receipt printer, app store accounts and any WhatsApp Business Platform conversation charges from Meta. You pay those providers directly, so you can see and control them. Quotes from other developers and SaaS vendors vary widely because they bundle these differently; ask each one which running costs are included before comparing.

For a line-by-line view of Dutch shop budgets, read what a webshop costs in the Netherlands; the pricing table below this guide lists all our starting prices.

How long does it take to launch a restaurant ordering system?

An online ordering system for restaurants in website form usually goes live in four to eight weeks from written approval; a native app takes six to ten weeks. The slowest step is rarely the code. It is collecting a clean menu with prices, options, photos and allergens.

Week one is menu and rules: you send your current menu, we turn it into a spreadsheet with option groups and allergen columns, and you correct it. Weeks two to four cover design, the menu front end, basket and checkout. Weeks four to six bring the payment connection, delivery zones, the printer link and the dashboard. The last stretch is testing in your real kitchen: we place test orders during a quiet afternoon while you check tickets, and then a soft launch to a few regulars before you announce it.

• Before we start: merchant account application with your payment provider (their approval time varies).
• Week 1: menu spreadsheet, option groups, allergens, zones.
• Weeks 2–4: design, menu pages, basket, checkout.
• Weeks 4–6: payments, printer or POS, dashboard, WhatsApp templates.
• Final week: kitchen test orders, soft launch, fixes, public launch.

Tip from our side: apply for the payment account on day one. Everything else can run in parallel, but a live checkout cannot.

How will guests find your ordering site on Google and in AI answers?

An online ordering system for restaurants only earns direct orders if guests can find it. They arrive mostly through searches for your name and “pizza bezorgen” style queries near them, so the ordering site needs strong local basics: a Google Business Profile that links to it, crawlable menu pages, correct opening hours and restaurant structured data. Nobody can promise rankings, but these basics are what search engines and AI assistants read.

We build the menu as real HTML pages rather than a picture or a PDF, so each dish with its description and price is readable by Google and by AI search tools that summarise local options. Restaurant schema marks up your address, cuisine, hours and the ordering URL. The site is tuned for Core Web Vitals on mid-range phones, because most orders happen on a phone, often on mobile data.

Then the ordering link goes everywhere guests already are: the Google Business Profile, your Instagram bio, the menu card QR code and the WhatsApp business profile. Reviews stay on Google, where you control the replies, instead of inside a marketplace app.

If you want ongoing help, local SEO starts from US$150/mo a month; the technical SEO page explains what that covers for Dutch sites.

What is it like to work with an Indian team from the Netherlands?

Practical and quick, if you like WhatsApp. India is three and a half hours ahead of the Netherlands in summer and four and a half in winter, so our afternoon is your morning and we overlap with most of your working day from late morning. Restaurant owners tend to reply between lunch and dinner service; that window suits us well.

Here is how it runs. You message us on WhatsApp with your menu and a few photos of your current setup. Within about two working days you get an itemised quote in USD. Nothing is billed before you approve it in writing. You pay in milestones by Wise, bank wire or PayPal, and invoices come from India. We hold short video calls in English when a decision needs a screen; most day-to-day questions are settled in chat.

• Days 1–2: menu review, questions about zones, payments and printer, written quote.
• Days 3–5: after approval, menu spreadsheet and design direction shared for your comments.
• Days 6–10: first clickable menu and basket on a test link you can open on your phone.
• Days 11–14: payment provider in test mode, first test ticket printed in your kitchen.

What we cannot do: visit your restaurant, install hardware or train staff in person. We guide the printer setup over video, and the three of us (One of us on the build, another of us on hosting and search, the third of us on planning and automation) stay reachable seven days a week. More on our remote model: hiring developers in India.

Who owns the ordering system, the menu data and the customer list?

You do. With an online ordering system for restaurants built by us, the domain, hosting account, source code, payment merchant account, app store listings and the customer database are all registered in your restaurant's name, and we work inside them with access you grant and can revoke.

That matters more for ordering than for most websites, because the customer list is the whole point. Names, addresses, order history and WhatsApp opt-ins belong to you and sit in a database you control. If you ever switch developers, you hand the new team the repository and hosting access; there is no export request to beg for.

Because you hold personal data, the AVG (the Dutch name for the GDPR) applies to you as the controller. We help the build support your obligations: only the fields you actually need at checkout, a privacy page you provide, a cookie banner that keeps non-essential cookies off until consent, encrypted connections, staff accounts with limited rights, and a way to delete a guest's data on request. Your own adviser should sign off the privacy wording; we do not give legal advice.

For a deeper look at privacy-by-design builds, see GDPR-compliant website development.

Red flags when choosing an online ordering system for restaurants

Walk away, or at least ask hard questions, when a provider will not tell you where your customer data lives, charges a hidden percentage on top of its subscription, or keeps the domain in its own name. Any of those can trap you later.

Other warning signs are quieter. A demo that only shows a simple menu with no options usually means the system struggles with real pizza or bowl logic. An order that prints before the payment is confirmed is a bug waiting for a busy Friday. A checkout that asks for an account before showing the delivery fee loses guests. And if nobody can explain what happens when the printer goes offline, assume the answer is “the order is lost”.

• Domain, merchant account or app listing held in the provider's name.
• No export of customers and order history in a standard format.
• Orders sent to the kitchen before the payment webhook confirms payment.
• No allergen fields per option, only per dish.
• Delivery fee hidden until the last step.
• Support only by ticket, with no one reachable during dinner service.

Ask us the same questions. The answers should be short: your name on every account, full exports, payment-first printing, allergens per option, fees shown at the postcode step, and WhatsApp replies seven days a week.

Worked example: a hypothetical pizzeria in Utrecht moves its regulars

Here is an illustrative scenario, not a client story. Say a pizzeria near the Utrecht city centre gets most of its delivery orders through a marketplace, and the owner notices the same names and streets every week. She wants her own online ordering system for restaurants without dropping the marketplace.

Her brief: pizza sizes and extras, pickup and delivery, three delivery zones by postcode, iDEAL and card payments, tickets on the existing kitchen printer, a loyalty stamp after every tenth direct order, and WhatsApp messages when the driver leaves. No app for now.

We would quote the ordering website from US$750, with the loyalty rule and WhatsApp templates listed as separate lines. Week one goes on her menu spreadsheet: 48 dishes, 7 option groups, allergens per topping. By week five she tests orders from her own phone while the printer runs in the kitchen. At launch, every marketplace customer who comes for pickup gets a menu card with a QR code and a first-order perk for ordering direct.

After three months she compares her platform statements with the dashboard to see how many regulars have moved. If the number is low, the fix is usually marketing at the counter, not more software. If it is high, the next step might be a branded app from US$600.

Checklist before you order an online ordering system for restaurants

Gather these before you ask anyone to quote an online ordering system for restaurants, and you will get a sharper price and a faster launch. Most can be done from your phone in an evening.

• Current menu with prices, sizes, extras and deals, as a document or photos.
• Allergen list per dish and per extra, confirmed by your kitchen.
• Delivery area as postcodes, with minimums and fees you want per zone.
• Opening hours, holiday closures and busiest time slots.
• Kitchen printer or POS brand and model, with a photo of its label.
• Your domain name (or the one you want) and who currently controls it.
• Whether you will deliver yourself, use a courier service or offer pickup only.
• Last three months of platform statements, to run the commission sums.
• Logo, brand colours and a few good food photos.

Send what you have on WhatsApp through our contact page; missing items can follow later.