Where app development money actually goes, line by line
A quote is one number. The project is roughly eight. Knowing the split tells you which parts you can cut and which ones will cost you later if you do.
Key takeaways
- Engineering is roughly half the budget, backend a fifth, design a seventh, with release and support taking the rest.
- Cross-platform saves 30 to 60 per cent against separate native builds for typical business applications.
- Scope is the only real lever; reducing day rates usually increases rework instead.
- Backend security, error monitoring and offline states look optional in a demo and are not.
In a typical mobile app budget, engineering is around half, backend and infrastructure a fifth, design a seventh, and the remainder splits between project management, quality assurance, store submission and the first months of support. Cross-platform delivery reduces the engineering line by roughly 30 to 60 per cent against building separate native apps, which is why most business apps are now built that way.
- 40–70%
- cost premium reported for native development over React Native for comparable feature sets
- 30–60%
- saving from cross-platform against separate native iOS and Android builds
- $40,000–150,000
- typical range for a production cross-platform app
- 15–25%
- of build cost per year for maintenance, which is not optional
The eight lines
- Discovery and specification. Small in cost and disproportionate in effect. Cutting it does not save money, it moves the cost into rework.
- Design. Interface, interaction, and the states nobody remembers to specify: empty, loading, error, offline, and right-to-left if you serve Arabic.
- Client engineering. The largest single line. Cross-platform frameworks compress it substantially for typical business applications.
- Backend and API. Frequently underestimated because it is invisible in a demonstration. If the app needs accounts, sync or payments, this is a real project of its own.
- Integrations. Payment gateways, identity, mapping, messaging, analytics. Each is a fixed cost with its own approval process, and regional payment gateways often take longer to approve than to implement.
- Quality assurance. Real devices, real networks, both platforms, both languages if bilingual.
- Release. Store accounts, review submissions, privacy declarations, and the rejections that come with a first submission.
- Support and iteration. What happens after launch, which is where the app either becomes useful or is abandoned.
What genuinely reduces the number
Scope, and almost nothing else. Removing a feature removes design, engineering, testing and its share of ongoing maintenance simultaneously. Reducing the day rate reduces one line and often increases another, because the largest cost overruns come from rework rather than from hourly rates. If the budget is fixed, cut features rather than quality; a smaller app that works is an asset and a large one that half-works is a liability.
What looks optional and is not
Backend security review, error monitoring, and the offline and error states in design. All three are invisible when the app is demonstrated on a good connection with clean data, and all three surface within a fortnight of real users arriving. The cost of adding them afterwards is several times the cost of building them in, because by then the architecture assumed they were unnecessary.
Cutting discovery does not save money. It moves the cost into rework, at a worse exchange rate.