You have run the arithmetic, you have made the site fast, and the answer is still yes — you have the frequency, you have a reason the browser cannot serve, and you have somebody to look after it. Good. This topic is about buying it in a way you do not regret, and most of the regret in this industry comes from two things nobody asks about at the demonstration: what happens in year two, and whose name the accounts are in.
🧰 Three ways to have one
| Way | Roughly what it costs | What you control | Who it suits |
| Custom build | A large one-off, plus maintenance forever | Everything, including the bugs | Groups with several sites and a technical person |
| Template / white-label | A monthly fee, small setup | Your logo, your menu, their features | Most restaurants that genuinely need one |
| Inside somebody else's platform | Commission, or nothing extra | Very little — their app, their customer | Restaurants that want reach rather than an asset |
For a single restaurant, the custom build is almost never the right answer, and the reason is not the price of building it. It is that an app is a living thing: the phone operating systems change twice a year, the store rules change, the payment and mapping libraries expire, and each of those is a small invoice or a small outage. A white-label provider absorbs that work across hundreds of customers. A custom app absorbs it out of your pocket, or it rots — and a rotted app is worse than no app, because the customer who opens it and sees last year's menu learns something about your restaurant that is not true.
The third row deserves an honest note. Being inside a platform's app is not having an app; it is being a listing. That can be perfectly good business — the delivery course covers exactly what that trade costs — but do not confuse it with building a channel of your own, because everything the reservations course said about who owns the customer applies here word for word.
🧾 What it actually costs, in year two
Price the whole thing over three years rather than as a purchase, because that is the shape of the commitment.
There is the build or the monthly fee. There are the store accounts, which cost a modest amount every year and must be renewed or the app disappears from sale. There is maintenance — the twice-yearly operating system updates that break something small, at minimum a few hours of somebody's time each time. There is the content: menu changes, prices, photos, holidays, which is the part that quietly falls to whoever is least busy and therefore stops happening. And there is support, because a customer whose order fails in your app will phone your restaurant, not your developer.
Then convert the monthly total into what the budgeting course taught you to convert it into: a permanent sales requirement. A $300 monthly commitment needs about $600 of extra sales every month for as long as you keep it, which is roughly twenty-four extra covers. Write that number on the proposal before you sign it. It is the same test you would apply to a piece of kitchen equipment, and it is the test nobody applies to software.
🔑 Whose accounts are these?
Ask these before signing, and get the answers in the contract rather than in an email.
- The store accounts are in your name, with your billing details, and you have the login. Developers routinely publish client apps under their own account, and the day you part company your app belongs to them.
- The customer list is exportable, by you, at any time. Names, emails, phone numbers, order history — the customer data course explains why this is the actual asset. An app whose data you cannot export is a rental.
- You own the source code, or you do not care that you do not. Both are defensible; not knowing which is the problem.
- Who fixes it, in how long? Get the response time in writing, and ask what happened the last time a phone update broke something.
- How does it end? Notice period, what happens to the data, and whether the app is removed from the stores or left there dead.
- What does the customer see when you switch it off? Somebody should have thought about this before it happens, and topic 6 explains why it will.
⏱️ Start smaller than the demonstration
Every app demonstration shows a full product: ordering, points, bookings, gift cards, a table game. Build one job, do it well, and add the second only when the first is being used.
For most restaurants the one job is reordering — the customer's usual, in two taps, because that is the only thing an app genuinely does better than a browser for a returning customer. For a coffee shop it is the points balance. For a place with a queue it is order-ahead. Pick the one that matches why your customers come, and leave the rest of the screen empty rather than filling it with features nobody asked for.
And launch it to a small group first — your regulars, in person, over two weeks — before you promote it at all. You will find the three things that are broken, and you will find them from people who like you enough to tell you rather than from a one-star review that stays on the store page for the life of the app.