Restaurant app cost: ordering, click & collect and loyalty
10 min read
Key takeaways
- Allow 15 to 20% of the initial development cost per year, excluding new features.
- Two major OS updates a year mean work, even with no functional change.
- Certificates and developer accounts expire: forgetting them makes the app unavailable.
- An app without maintenance generally becomes unpublishable within 18 to 24 months.
- Taking over an abandoned app costs 40 to 70% of a rewrite.
It's the budget line nobody plans for and that catches everyone out. The app is launched, the team moves on to something else, and fifteen months later it no longer builds, no longer passes store review, and nobody knows where to pick it up.
A mobile app isn't a deliverable: it's a service that lives in an environment that changes twice a year without asking your opinion.
What changes without you doing anything
Operating systems. Apple and Google each release a major version every year, plus interim versions. Each brings its share of adaptations: new permission rules, system interface changes, modified background behaviour, deprecated APIs.
Publication rules. A minimum development kit version is enforced, new privacy declarations, accessibility requirements. An app that was compliant in 2024 is not automatically so in 2026.
Dependencies. Your third-party libraries publish security fixes and major versions. Staying behind is comfortable for a year, then every upgrade becomes a project because they pile up.
Certificates and accounts. Signing certificates, push notification keys, developer accounts, third-party service subscriptions. They expire. Forget one certificate, and the app can no longer be updated — sometimes no longer installed.
The most frequent and most avoidable incident: the expiry of a developer account or a certificate. Not a single line of code is at fault, the app is removed or blocked, and getting it back online can take several days. Put these deadlines in a shared calendar, not in a single person's inbox.
What a maintenance budget actually covers
| Item | Indicative share | Content |
|---|---|---|
| OS compatibility | 25 – 35% | Adapting to major iOS and Android versions |
| Dependencies and security | 20 – 25% | Version upgrades, security patches |
| Bug fixing | 20 – 30% | Crashes, regressions, unforeseen cases |
| Monitoring | 10 – 15% | Tracking crashes, performance, server errors |
| Infrastructure | 10 – 20% | Hosting, backups, certificates, accounts |
Note what isn't there: new features. They are budgeted separately. A maintenance contract that claims to include enhancements hides either a very limited reserve of days or a misunderstanding that will surface in the first quarter.
15–20%Of the initial cost, per year, to keep what exists running
18–24 monthsBefore an unmaintained app becomes unpublishable
40–70%Of the cost of a rewrite to take over an abandoned app
The calculation that convinces finance departments
Take an app whose development represented a substantial budget.
With maintenance: around 15 to 20% of the initial cost per year. After three years, you've spent about half the initial cost and you have an up-to-date, publishable app whose team knows the code.
Without maintenance: no spending for three years, then a takeover. Restoring the build chain, three years of upgrades piled on top of each other, adapting to the stores' current rules, fixing what broke along the way. Observed cost: 50 to 65% of a rewrite, which is as much as or more than three years of maintenance — to get back exactly the same app, three years later, with no improvement at all.
The apparent saving was therefore negative, and the app will have been degraded throughout the period.
What to put in place from launch
These four items cost a few days and cut the cost of maintenance afterwards.
Crash monitoring. A tool that automatically reports errors, with the version, the device and the context. Without it, you find out about problems through store reviews, which is to say too late.
An automated delivery pipeline. Building and publishing should be a command, not a three-hour ritual mastered by a single person. That's the subject of our article on mobile CI/CD.
A calendar of deadlines. Certificates, accounts, subscriptions, with a reminder two months ahead, shared between at least two people.
Start-up documentation. How to set up the environment, build, publish. One page is enough, and it's worth several days when someone new takes over the project.
The three formulas available on the market
As needed. You call when something breaks, you pay by the day. Suited to non-critical internal apps; unpredictable on an exposed product.
Monthly retainer. A fixed budget covering corrective maintenance and light enhancements, with a commitment on response time. It's the most common formula, and the clearest for management accounting.
Reserve of days. A volume of days bought in advance, used as needed. Flexible, but needs tracking to avoid everything being consumed by enhancements and nothing by real maintenance.
The question is never "should we maintain the app". It's "do we pay for maintenance continuously, or for a more expensive takeover in two years". There is no third option where the app stays usable without anyone touching it.
The warning sign
If you can't answer these three questions, your app is already in debt:
- When was the last version published?
- When do your certificates expire?
- How many crashes per day do your users experience?
If you'd like an outside opinion, we carry out a takeover audit in a few days: state of the code, technical debt, at-risk deadlines and a priced estimate of the cost of bringing it up to date. It's useful even when the conclusion is that all is well.
Sources
- Exigences liées au niveau d'API cible pour les applications Play — Google Play Console
- Program Renewal - Membership — Apple
- Upcoming Requirements — Apple
