Restaurant app cost: ordering, click & collect and loyalty
10 min read
Key takeaways
- Rewriting costs 70 to 110% of the original price; repairing costs 25 to 40%.
- A rewrite is justified by the inability to ship, not by the unpleasantness of reading the code.
- An app with no tests is not “to be rewritten”: it is to be instrumented first.
- The most profitable strategy is almost always progressive replacement, screen by screen.
- Get a costed audit before deciding: three to five days that often avoid a six-figure mistake.
“The code is unreadable, let’s start from scratch.” This sentence is uttered in just about every takeover project we come across, generally within the first two hours, and on average it costs the price of a complete app.
Sometimes it is right. Most of the time, it expresses the natural discomfort of facing code written by somebody else. Here is how to decide with figures rather than with an impression.
The three scenarios and their costs
Take an app developed three years ago, and express each scenario as a percentage of its initial cost.
| Scenario | Cost (as % of initial cost) | Duration | Risk |
|---|---|---|---|
| Repair — version bumps, targeted fixes, visual refresh | 25 – 40% | 6 to 10 weeks | Low: the app stays in production |
| Replace progressively — screen by screen, same scope | 60 – 95% | 5 to 9 months | Medium: two codebases coexist for a while |
| Rewrite — start from a blank page | 70 – 110% | 6 to 12 months | High: nothing is delivered until the end |
The figure that surprises is the third. Rewriting rarely costs less than the original development, for a simple reason: you are not rewriting the app from three years ago, you are rewriting today’s, with the features added since, the accumulated edge cases and the business rules that nobody documented but that users know by heart.
The hidden cost of a rewrite: for six to twelve months, you ship nothing to your users. Your competitors carry on. This opportunity cost appears on no quote and often exceeds the cost of the project itself.
The six signals that really justify a rewrite
Just one is enough. None of them is “the code is ugly”.
1. The technology is no longer supported. The development framework is no longer maintained, or the stores impose a minimum version that your stack can no longer reach. Here, there is no choice.
2. Nobody can get it to build. If a competent developer cannot produce a binary in a day, the app is no longer maintainable — regardless of the quality of the code itself.
3. The cost of adding features has more than doubled. Measure it: an average feature cost five days two years ago, it costs twelve today. It is the most reliable economic signal there is.
4. The data model no longer supports the business. You work around the structure with every new request, with fields diverted from their purpose and rules hard-coded. It is the only form of debt that cannot be paid down progressively.
5. A platform change has been decided. Moving from native to cross-platform, or the reverse, for documented reasons — the subject of our comparison React Native, Flutter or native.
6. The product itself has changed in nature. The app no longer does what it was designed to do. This is then not a rebuild, it is a new product carrying the same name.
What does not justify a rewrite
“The code is badly written.” That is almost always true, and almost never enough. Ugly code that works and can be modified is better than elegant code that does not exist yet.
“There are no tests.” This is not a reason to rewrite, it is a reason to write tests — starting with the three critical journeys. Two weeks, and the takeover becomes possible.
“It’s not the technology we would have chosen.” The technology your competitors use has never sold a product. The only criterion that matters is whether you can find people capable of keeping it alive.
“It’s faster to start from scratch.” In practice, it is — until the moment you have to rediscover the two hundred edge cases the old app was quietly handling. That phase regularly represents 40% of the project.
The strategy that wins in most cases
Progressive replacement combines the advantages of both approaches.
- Audit and instrument (2 to 3 weeks). Surface crashes, measure performance, write tests on the critical journeys. You finally know what actually breaks, which is often very different from what the team believed.
- Stabilise (3 to 5 weeks). Bump versions, fix the ten most costly defects, get the release pipeline back in order. At this stage, many projects stop there — and that is good news.
- Replace by zones (ongoing). One screen or module at a time, with the new approach, keeping the old one functional until the switchover. Each step is deliverable, measurable and reversible.
The total cost is comparable to that of a rewrite, but it is spread over time, and you ship continuously. Above all, you can stop at any moment if the return on investment is no longer there — which a rewrite never allows.
70–110%Of the original cost for a full rewrite
25–40%Of the original cost for a targeted upgrade
≈ 40%Of a rewrite spent rediscovering forgotten edge cases
The three-year comparison
Take the same app, over three years, again as a percentage of its initial cost.
“Repair then maintain” option: about a third of the initial cost for the upgrade, then about 17% a year. Total: ≈ 85% of the initial cost. The app stays online throughout the period and improves in small steps.
“Rewrite” option: about 95% of the initial cost for a nine-month rewrite, during which nothing changes for users, then about 15% a year in maintenance over two years. Total: ≈ 125% of the initial cost, plus nine months of standing still.
The gap represents nearly 40% of the initial cost, and it widens further if you put a value on the features not delivered during the rewrite. These orders of magnitude fit with those in our article on the cost of a mobile app and the one on maintenance.
A rewrite is decided on one figure: the cost of adding a feature. As long as that figure stays acceptable, rewriting amounts to paying a great deal to feel better.
Before deciding: the audit
Three to five days are enough to produce a documented decision: the real state of the code, debt costed by module, at-risk deadlines, and the comparative cost of the three scenarios for your specific case.
It is the best possible investment before a six-figure commitment. We carry it out independently, including when the conclusion is that there is nothing to do — which happens more often than you might think.
Sources
- Exigences liées au niveau d'API cible pour les applications Play — Google Play Console
- Upcoming Requirements — Apple
