In this article
A local web agency, your POS vendor or a franchise consultant asks the same question sooner or later: do you want your own app? The answer you get is almost always emotional — "be where your customer already is" — and almost never worked out on paper. This piece works it out, using the numbers the app industry itself publishes.
A native app sounds like the obvious next step after your website: your customer already orders from a screen, so why not from an icon on their phone too? The idea isn't the problem. What happens next is — and that part is rarely mentioned by whoever is selling you the app.
The mobile app industry has measured exactly what happens to an install for a decade: how many people open it, how many are still there after a month, how many come back after three. Those numbers are hard, public and remarkably consistent — and almost never applied to a single hospitality venue.
This article does that, in four numbers: what an app genuinely costs to build and keep running, what share of your own customers realistically install it, how many of them still open it after 30 and 90 days, and — the question that actually matters — how many extra visits it takes before it has paid for itself. At the bottom, plug your own numbers into a calculator that runs the same maths as the rest of this article.
The conclusion is neither "never" nor "always". For a single-location independent, the answer is almost always no — the numbers below show exactly why. For a multi-location group or a delivery-heavy concept with genuine repeat-order volume, the same maths can clear the bar. The difference isn't ambition, it's scale.
The ultimate guide Restaurant Tech & Data: 6 Steps from 7 Tools to 1 System From a standalone till to one integrated system: the complete guide to technology choices that actually pay off. Open the guide1. What an app costs to build — and to keep paying for
A quote for a "simple" ordering and loyalty app for a single venue runs, at specialist agencies, roughly €8,000 to €25,000, depending on how much of your existing system has to be built into it. Add reservations, delivery tracking or a richer loyalty programme and it climbs quickly towards €40,000 to €80,000 — and that's only where the bill starts. Weigh that honestly against what's already on your list of software subscriptions: an app is rarely the first cost you want to add.
On top of the build cost sit two recurring costs no quote leads with. Apple charges roughly €92 a year for a Developer account, without which no iOS app ever goes live — miss a year's payment and your app disappears from the App Store, however many customers already use it. Google charges a one-off €23 for a Play Console account. Small amount, but it's the first of many: every major iOS or Android update forces a new review cycle, and an app left untouched for two years eventually gets rejected or simply becomes unfindable in the store.
There are two cheaper routes, and both deserve an honest mention before you read on. A progressive web app (PWA) — "add to your home screen" straight from your existing website — costs a fraction of a native app, because there's no App Store review, no two separate codebases and no annual Apple bill involved. And if the reservation or ordering system you already use offers an app as a built-in feature, its marginal cost is zero: you're already paying for it, whether you use it or not.
Add it up: €95 a year for Apple, €24 one-off for Google — before a single line of code is written, and with no guarantee a single customer ever opens the result.
2. How many of your customers actually install it
Ask an app agency for an install rate and the answer stays vague: "it depends". Ask the loyalty platforms that build standalone restaurant apps for their own numbers, and the answer gets more specific — but it's a number with an address. Loyalty-app vendors typically report a 10 to 20% install rate, and that share is measured against their best customers: people who are already regulars. It's the same trap as self-order kiosks: appealing technology that only pays off for a very specific slice of your guests.
That's the problem. That 10 to 20% isn't a share of all your customers, it's a share of your regulars — and regulars are themselves a minority. Restaurant research consistently puts the share of guests who never return at roughly 70 to 77%, and attributes some 65 to 80% of revenue to the customers who do come back. In other words, the group that's even a candidate to install an app is itself only a fifth to a quarter of your full customer base.
Stack those two numbers on top of each other and the share of your FULL customer base that ever installs the app drops to low single digits — not ten percent, let alone twenty. On a base of a thousand customers that's roughly two hundred and twenty regulars, of whom about one in seven installs the app: thirty-three people. That's the realistic starting point, not the optimistic figure on the quote.
On 1,000 customers, using the shares above. Each bar is a share of the step before it.
These are guide figures, not a law: a venue with genuinely loyal delivery customers gets a higher regulars share, one with lots of tourists gets a lower one. The pattern — a steep funnel from customer to install to active use — holds up in almost every study.
3. Who still opens it after 30 and 90 days
An install is not a user. The mobile app industry has measured this for years through cohort curves — how many of the people who installed on day zero ever come back — and the pattern is remarkably consistent, whatever the category of app. Business of Apps and Adjust reported an average day-1 retention for 2026 of around 25%: of everyone who installs, roughly one in four ever opens the app a second time.
It only accelerates from there. The same sources put average day-30 retention at 5 to 7%, and by then more than 90% of all users have already let the app go. By day 90 — the point at which a second-visit discount would actually start paying off — retention across most categories sits somewhere between 3 and 5%. That's not one careless developer's bad luck; it's the average across thousands of apps in dozens of categories.
Translate that to the thirty-three installs from the previous number, and three months later there's roughly one active user left. Not one in thirty-three percent — one person. That's the reality behind "we're building an app to bring customers back": the odds that a random customer still opens it on day 90 sit close to one in a thousand.
4. How many extra visits it takes to break even
An app only pays for itself if an active user visits more often than they would have without it — not more often than average, more often than they'd have come anyway. That difference exists in no published industry standard: no report tells you how many extra visits one app user genuinely generates, because it varies by venue, concept and offer.
What we do know, we can set against each other. Take the build cost, divide it by your average spend per visit, and you get the total number of extra visits the app needs to generate to pay for itself. Divide that again by the number of active users left after 90 days, and it becomes clear how many extra visits per month each remaining user would need to make — a figure that, for a normal venue, comes out wildly unrealistic.
For an average-sized independent, the payback period runs to decades. Not because the app has no value, but because the number of people still using it by day 90 is too small to carry a build cost of thousands of euros — even if every remaining user turned out to be improbably loyal.
Same venue, same install and retention shares, three ways to get an app.
The PWA bar assumes the same install and retention shares as the native app — only the build cost differs. In reality the threshold for tapping "add to home screen" is lower than an app-store download, so this is more a floor on how fast a PWA pays back than a ceiling.
Run the numbers for your own venue
The figures above are averages. Fill in your own customer base, spend and quote — everything runs locally in your browser.
—
"Extra visits per month because of the app" is the one assumption here with no published source — fill it in conservatively rather than hopefully. Everything runs locally in your browser; nothing is sent or stored.
When the maths does close
The sums above are written for the venue most readers of this article run: one location, a few thousand customers, a quote in the tens of thousands. Change that scale and the conclusion can flip — not because the retention curve changes, but because the build cost isn't multiplied per location while the customer base is.
Take a delivery-heavy concept with several locations and a combined customer base of around 50,000 people, with a higher order frequency and a higher share of regulars than the average dining venue — realistic for a business that delivers routinely rather than one that seats guests occasionally. Same app, same quote of roughly €52,500, but now spread across a far larger base of active users.
With equally conservative install and retention assumptions, that app breaks even in around 10 months — instead of decades. The difference isn't the app, it's the denominator: at that scale there are enough active users left to carry the build cost; at a single independent venue there aren't.
What to do before you sign
Signing a quote takes one signature. These three steps take an hour, and they decide whether that signature saves money or costs it.
Before you ask for a quote
- Count how many of your customers are genuinely regulars — people who return at least monthly. That number, not your full customer base, is what an app is actually built on.
- Ask yourself one question: what does the app do that a WhatsApp broadcast list, a free loyalty card or a home-screen bookmark can't? If the honest answer is "nothing concrete", the app is an expensive way to do the same thing.
- Open the calculator above with your own numbers before you talk to an agency — then you'll know what answer a quote needs to give you, not the other way around.
If you build one anyway
- Start with a PWA, not a native app. If it's genuinely being used after six months, you have evidence before making the tenfold investment.
- Put one concrete benefit in the app from day one that exists nowhere else — a stamp card that only accrues there, a dish shown there before anywhere else. Without a reason to keep it open, the cohort curve above repeats exactly.
- Set aside 15 to 20% of the build cost a year for maintenance and app-store updates — that's not an extra, that's the price of staying live.
The cheaper route
- Check first whether the reservation or ordering system you already use — or are considering — offers an app as a feature alongside the other automation it already gives you. If so, the marginal cost is zero.
- Compare that free route honestly against the quote: the same push notifications, the same loyalty integration, without a separate Apple bill.
- Read what such a built-in app actually offers on the product page for our own app — the same question, minus the agency in between.
Not a no, not a yes — a sum
Almost every owner reading this article recognises the feeling that an app belongs with "a modern venue". That feeling isn't wrong — it's just not a financial model. The four numbers above show what happens between the quote and the first year-end close: a steep funnel from customer to install to active use, and a build cost that has to be split among too few remaining users.
For an average-sized independent, the answer is almost always: not now, not native, not at that price. That's not a judgement on the ambition — it's what the entire app industry's cohort curves predict, applied to one hospitality venue instead of a mass-market audience.
What does work is the same instinct — being closer to your customer — without the build cost, the app-store bill and the annual update obligation. Our own app is exactly that route: the same feature, built into a system you're already using, with no second invoice from an agency.