App for my restaurant: do you need one, what to build and what it costs

"Should I build an app for my restaurant?" is a fair question once you notice how many of your regulars order through a delivery aggregator, or how often the phone rings with the same questions. The short answer: an app for your restaurant pays off when you have regulars who order or visit often, and when the app does three things well. It lets them reorder in one tap, rewards them for coming back, and sends orders straight into your kitchen and till. Without those three, it is an expensive menu.

If most guests visit once a year, a fast website with ordering is enough. If you have a steady base of regulars, your own app is how you keep them, and keep the margin that a marketplace commission takes on every order. Below: the formats to choose from, what to launch with, why POS integration decides everything, what it costs and a quick test of whether you need one now.

Why aggregators are expensive, and what your own app changes

Delivery services such as Glovo, Wolt or Yandex Eats are convenient at the start: they bring traffic. But as a channel they work against you in two places. First, the commission: the platform takes a share of every order under your contract, and on repeat orders from people who already know you, that share is money you did not need to spend. Second, the customer does not belong to you. A guest who ordered through an aggregator will open the aggregator again next time and see whoever paid for a higher placement, and you usually do not get their contact details to invite them back.

Your own app flips three things:

• The margin on repeat orders stays with you. You can acquire a guest through an aggregator, but after that it is more profitable to move them into your own app, where there is no platform commission.
• The customer is tied to the brand. Bonuses, order history and a favourite order in one tap keep the guest with you rather than on the marketplace.
• The data is yours. What people order, at what times, how often, the average ticket by location: promotions, menus and purchasing are built on this.

Important: your own app does not replace aggregators. A smart setup is the aggregator as an acquisition channel for new customers, and your own app as a channel for retention and repeat sales with a healthy margin.

Which format: native app, mini app or website?

When owners ask about an app for their restaurant, they often mean very different things. There are three formats, and they differ in price, speed and who they suit.

In practice, many start with a website or a Telegram Mini App, which is fast and inexpensive, and build a native app once the guest base is collected and it is clear that repeat orders happen. The back end (menu, orders, payment, integrations) is shared, so moving from one format to another does not mean rewriting everything from scratch if the architecture was laid out correctly.

The minimum set: what you cannot launch without

You do not need to build an aggregator killer right away. You need a set that covers the guest's journey from choosing a dish to receiving the order without gaps.

A note on languages. Article 21 of the Language Law lists menus among the visual information placed in the state language, and in Russian where needed. Whether that covers an app is a question for your lawyer, but your guests need a Kazakh menu either way.

This is enough to launch. Things people often want right away but that comfortably wait for phase two: real-time courier location on a map, a referral program ("invite a friend"), subscriptions for recurring orders such as business lunches, reviews and dish ratings, and a support chat.

What gets added in phase two

Once the first version is working and orders have started, it makes sense to build what increases frequency and ticket size:

• Courier tracking on a map. It reduces the guest's anxiety and the number of calls.
• Loyalty tiers and gamification. Statuses, challenges, stamps for orders. They raise visit frequency.
• Behaviour-based personal promotions. "You have not ordered pizza in a while, here is a promo code." This works far better than mass mailouts.
• Subscriptions and preorders. Recurring deliveries, scheduled business lunches.
• Several brands from one kitchen. If you run several concepts out of one kitchen, you can show them as separate storefronts inside one app.

What cheap wrapper apps fail at: integrations

Here is the key idea worth grasping before you choose a contractor. An app that is not connected to the kitchen and the POS is not automation, it is extra work: an administrator retypes orders from the app into the restaurant system by hand. That is what cheap wrapper apps built on top of a website do: they look decent, but inside there is manual labour and errors.

A working app integrates with what the venue already has:

• The restaurant POS. In Kazakhstan this is often iiko or r_keeper. An order from the app lands in the kitchen and is rung up at the till automatically. The menu and sold-out items are synced: when a dish runs out, it disappears from the app and the guest cannot order what is not there. iiko offers a cloud API for this, and r_keeper has a separately licensed module for delivery orders.
• Online payments. Cards through a bank's internet acquiring (Apple Pay and Google Pay if your bank supports them), payment through Kaspi by invoice or QR, and a receipt that matches what the till records. Online cash registers and receipts for online payments are covered in our guide on online payments and receipts; check the details for your company with your accountant. If you already use Kaspi's service for restaurants, the app works next to it, not instead of it.
• Delivery. Assigning couriers, delivery zones and cost, integration with your own courier team or a delivery service.
• Analytics. Revenue by location and by dish, average ticket, order frequency, promotion effectiveness. Without this, you do not know whether the app pays off.

The POS integration is exactly where the difference between "built cheap" and "built so it actually works" becomes obvious. It needs to be planned into the project from day one, not bolted on later.

An example: what matters on a real project

Take a chain of three coffee shops on iiko, where some regulars order through an aggregator and others message on WhatsApp. The task is not "make a beautiful app" but "make guests come back and keep the system standing during the morning rush". So the focus is on three things:

• an order for a set pickup time that goes straight into iiko and onto the barista's screen;
• clear cashback that is added the same way at the till and in the app;
• analytics by location and guest: who orders every day, who has disappeared, which promotions work.

Our project for Hotu-As, a meat processing plant with its own retail chain, is built along the same lines: bonuses are added through ATOL tills and 1C 7.7 accounting, and the customer sees the balance and a card in Apple Wallet. In food service, iiko or r_keeper usually takes the place of 1C, but the principle is the same.

The takeaway: the menu screen is the smallest part of the value. Most of it sits in the link to the POS, a loyalty program guests understand, and analytics you actually make decisions on. If a contractor talks only about design at the first meeting and never asks which POS you use or how your loyalty works, that is a bad sign.

Common mistakes that cost a lot

• An app with no link to the POS. Orders are retyped by hand. Within a month, no one at the venue wants to use the app.
• Complicated loyalty. Confusing bonus rules mean the guest does not see the benefit and does not collect. Loyalty should be readable in five seconds.
• Ignoring sold-out items. The guest ordered something that has run out, the order got cancelled, and you lost a customer. Availability should sync automatically from the POS.
• Launching everything at once. People try to build the maximum number of features at the start, the budget and timeline slip, and half the features are not needed. The right way is a first version, then expansion driven by data.
• No analytics. The app launched, but there is nothing to measure the impact with. Money is spent blindly.
• Skimping on the back end. A cheap back end cannot handle peak hours on a Friday evening, and the app crashes exactly when there are the most orders.

Do you need an app for your restaurant? A quick test

Tick what is true for you today:

• Most of our revenue comes from regulars who order or visit at least twice a month.
• A noticeable share of those regulars order through an aggregator.
• We run, or want to run, a loyalty program: stamps, bonuses or a birthday reward.
• Our POS can accept orders from outside: it has an API or an integration partner.
• We have someone who will update the menu, prices and offers every week.
• We can promote the app at the till, on the receipt, on the packaging and in every delivery bag.

Five or six ticks: your own app is likely to pay off. Three or four: start with web ordering or a messenger mini app, collect guests, and add a native app later on the same back end. Two or fewer: a good website and a simple loyalty card come first; see our 12 loyalty program ideas.

How much it costs and how long it takes

An exact figure only comes from looking at your menu, your POS and how you run delivery, but you can plan from our starting prices.

The starting scope of the app is described on our restaurant app development page, and everything we build for food service is collected on the page for restaurants and cafés. A first version is out within a few weeks once your menu, loyalty rules and POS access are ready. Store fees and payment and push provider subscriptions are listed separately. The price is fixed in the contract before work starts, with a 6-month warranty, and the source code and accounts stay with you.

What moves the price: the number of locations, delivery with your own couriers versus pickup only, the POS and its API, and how flexible the loyalty rules must be. A chain app with delivery zones and advanced analytics gets its own estimate after a brief.

How to save money sensibly

You can save without hurting the result if you:

• Start with a first version for one or two main scenarios (for example, delivery and pickup with payment and basic loyalty), test demand for repeat orders, and only then build out more.
• Begin with a mini app or website, and build an iOS and Android app once you have a loyal base. That way you do not pay for an expensive format before you have confirmed it will pay off.
• Reuse the back end. A catalogue, orders, payment and POS integration built once work for the website, the mini app and the native app alike.
• Do not skimp on POS integration and analytics. That is exactly where saving turns into manual labour and blind decisions.

The bottom line

An app for your restaurant is not a prettier menu. It is a way to bring guests back, move repeat orders out from under the aggregator commission and see what people actually order. Three things decide whether it pays off: POS integration, a loyalty program guests understand, and analytics. For most venues the sensible path is to start small, with web ordering or a first app version for pickup, and expand based on data.