A first app budget typically covers design and development, and stops there. That number is usually accurate for what it prices. It is also, over a three year horizon, a fraction of what the product actually costs to own.
None of what follows is hidden in a sinister sense. It is just outside the quote, so it never makes it onto the spreadsheet until the invoice arrives. Here is the full picture, so you can plan for it rather than discover it.
- Budget ongoing maintenance at roughly 15 to 25 percent of the original build cost per year. It is not optional.
- Two OS releases a year will require work whether or not you shipped anything, so reserve capacity for them.
- Third party services are cheap at pilot scale and can become a significant line item at real volume. Model the cost curve early.
- Support, store fees and app store optimisation are operating costs, not project costs.
- The largest hidden cost is technical debt. Deferred quality is a loan with interest, not a saving.
Section 01
What the build quote actually covers
A development quote prices the work needed to get a defined scope to a submittable state. That is a legitimate and useful number, and it is what you should compare across partners.
What it does not price is everything that happens because the app exists: keeping it running, keeping it compatible, keeping it supported, and paying the parties who sit between you and your users. Those costs start the week you launch and do not stop.
Section 02
Platform and store costs
The store fees are small and predictable. The rest of the platform relationship is neither.
- Developer programme fees for both platforms, renewed annually.
- Commission on any digital goods sold through the app, which for many products is the single largest ongoing cost of all.
- Rejection cycles. A submission that fails review costs days, and a policy dispute can cost weeks. Neither is in anyone's estimate.
- Policy changes that require engineering work you did not plan, on a deadline you do not control.
Section 03
Backend, infrastructure and the services you rent
Modern apps are assembled from services, and the pricing on all of them is designed to be trivial while you are small. That is a good deal at pilot scale and a real budget line at production scale.
- Hosting, database and storage, which scale with usage rather than with revenue.
- Push notifications, email and SMS, where transactional volume tracks user count directly.
- Authentication, analytics, crash reporting and monitoring, each with a free tier and a cliff beyond it.
- Maps, payments, identity verification and any AI features, which are usually priced per call and can surprise you badly if a bug causes a retry loop.
- File storage and bandwidth for user generated content, which only ever grows.
Model these against your target user numbers before launch, not after. It is an hour of work and it occasionally changes the business model.
Section 04
Maintenance, which is the big one
This is the cost most founders underestimate by the widest margin, because there is nothing visible to show for it. The app looks the same at the end of the year as it did at the start. It only stayed that way because someone maintained it.
- Two major OS releases a year, each with deprecations, permission changes and layout differences to absorb.
- New device sizes and form factors that break layouts you tested carefully on last year's hardware.
- Dependency and SDK updates, some of them security critical and not optional.
- Certificate and key rotation, which is a routine task until you miss the date and every installed copy stops working.
- Bugs found by real users on device and network combinations that no test matrix covers.
An app that has not been touched in eighteen months is not stable. It is accumulating a bill that will arrive all at once.
Section 05
Support, content and the human costs
Users will contact you, and someone has to answer. This is a staffing question that arrives quietly, usually before anyone has decided whose job it is.
- Customer support, including the store review responses that materially affect your rating.
- Content and moderation, if users can post anything at all.
- App store optimisation: screenshots, descriptions and keyword work that need refreshing as the product changes.
- Localisation, which is not just translation but ongoing translation of every string you add afterwards.
- Legal and compliance work, from privacy policy updates to data requests you are obliged to service.
Section 06
Technical debt, the cost that compounds
Every shortcut taken to hit a launch date is borrowed time. That is often the right trade to make. What makes it expensive is not tracking it, so the interest accrues invisibly until the day a small feature takes three weeks and nobody can explain why.
- Keep an explicit list of what was deferred and why, rather than relying on memory.
- Reserve a share of each cycle for paying it down. Ten to twenty percent is a common and workable figure.
- Treat any estimate that seems disproportionate to the feature as a signal that debt is now the constraint.
Section 07
Building a budget that survives contact with reality
A three year view is the minimum useful horizon, because year one flatters you and year two is where unmaintained products fail.
- Take the build quote as your year one development figure.
- Add 15 to 25 percent of that per year for maintenance, starting the month you launch.
- Model third party and infrastructure costs at your target scale, not your launch scale.
- Add store commissions against your projected revenue, if you sell anything.
- Add whatever support and content capacity your product genuinely requires, in hours per week.
- Hold a contingency of 15 to 20 percent. Something on this list will be larger than you planned.
Frequently asked questions
How much should we budget for app maintenance each year?
A common planning figure is 15 to 25 percent of the original build cost per year. Simple apps with few integrations sit at the lower end. Products with payments, third party SDKs and frequent releases sit at the higher end, and occasionally above it.
What is the most commonly missed cost?
Operating system upgrades. Two major releases a year arrive whether or not you planned engineering capacity for them, and ignoring one usually means a scramble when a store deadline or a broken permission forces the issue.
Does a cross platform build really cost less overall?
It reduces the engineering portion, both at build time and in maintenance, because a fix ships once instead of twice. It does not reduce store fees, infrastructure, support, compliance or content costs. Treat it as a discount on part of the budget rather than on the whole of it.
Can we skip maintenance if the app is working fine?
Only briefly. Working fine today is compatible with a dependency vulnerability, an expiring certificate or an OS release that breaks a permission next quarter. Deferred maintenance does not remove the cost, it defers it and adds a deadline you did not choose.
