The common answer is 10 to 20 percent of the original build cost per year. It is a reasonable sanity check and a poor budget, because it tells you nothing about what you are buying. Two apps that cost the same to build can differ by a factor of five to run, and the difference is almost never the app - it is the infrastructure underneath it and how much the product is still changing.
So rather than a percentage, here is the actual shape of the cost, including the prices we publish.
The first three months are already covered
A standard 3-month warranty period runs from launch as part of the build, covering critical defect remediation with monthly client engagement and a bug remediation cycle. That is included, not an add-on.
It matters for budgeting because the first weeks after launch are when defects surface fastest, and a business that has budgeted nothing for month four is the one that gets caught. The question is not what you pay in month one. It is what happens in month four.
Option one: keeping it safe
The Warranty, Monitoring and Support Retainer picks up where the warranty period ends, so cover does not lapse. It is AUD 4,000 per month on a standard 12-month term, and it covers:
- Technical support for customer ticket investigation, capped at 7 hours per month
- Critical bugs fixed under warranty terms
- 24/7 infrastructure monitoring with proactive alerts
- Advance notice of required third-party updates, with cost implications stated upfront
- Business-hours response to outages
- A monthly review and Platform Health Report
Longer terms are discounted: a 24-month term takes 5 percent off the monthly fee and a 36-month term takes 10 percent off. Optional Hypercare Support is AUD 4,000 one-off and covers two weeks of post-launch priority response.
This is the floor. It keeps the platform running and someone accountable for it. It does not move the product forward.
Option two: keeping it moving
If the roadmap is still live, the Product Retainer includes everything above and adds continuous delivery. It is priced per 4-week cycle against a committed story-point capacity:
- Steady - $10,000 per 4 weeks, 12 points per sprint
- Growth - $20,000 per 4 weeks, 25 points
- Scale - $30,000 per 4 weeks, 40 points
- Velocity - $40,000 per 4 weeks, 56 points
- Momentum - $50,000 per 4 weeks, 75 points
Pricing against capacity rather than hours is deliberate. It means the conversation each cycle is about what to build, not about how long something took, and it makes the trade-off visible: a tier is a decision about how fast the roadmap moves.
What actually drives the number
Infrastructure is the line item that surprises people, because it scales with usage rather than with features and it is the one you did not choose at build time.
It is also the most recoverable. We reduced one client's cloud hosting costs by over 50 percent, saving them more than $10,000 every month. On another we decreased per-user cloud costs by 60 percent, and our rescue work routinely cuts server costs 30 to 50 percent.
Often the cause is a data model rather than a server bill. When we refactored the Move With Us user program engine from duplicated per-user data to templates, the core workout table shrank from 42GB to 0.9GB - 98 percent smaller - and database CPU peaks fell from 40 percent to under 5 percent. Nothing about the app changed for users, except that programming changes now reach them instantly with no workout reboot.
If your hosting bill is growing faster than your user base, that is a design problem presenting as a running cost, and it is worth an audit before it is worth a bigger server.
What deferring maintenance costs instead
Maintenance is not optional; it is only ever deferred, and the interest rate is poor. We have rescued 15+ platforms in the past 3 years: app ratings recovered from 3.8 to 4.6 stars, crash rates typically cut 50 to 70 percent within 2 weeks, and feature development 60 to 80 percent faster after modernisation.
Read those numbers in the other direction. Before the rescue, those products were rated 3.8, crashing at several times a healthy rate, and shipping features at a fraction of the speed - while their owners were still paying to run them.
The Train With Cass rescue is the clearest version of the argument. We took the crash rate down 90 percent, achieved 99 percent uptime and cut maintenance costs 50 percent, through a seamless handover from the previous developer. Maintained properly, the platform became cheaper to run, not more expensive.
How to budget for it
Decide first whether the product is finished or still moving, because that is the real fork. A finished product needs cover, which is a known monthly figure. A moving product needs capacity, which is a tier decision you revisit quarterly.
Then look at the infrastructure separately from the team, and check it against usage rather than against last year's bill. For the definitional side of what maintenance covers, see our glossary entry on app maintenance; if you are still costing the build itself, how long it takes to build an app sets out the phases this budget follows on from.
If you are unsure which side of that fork you are on, or the hosting number has stopped making sense, we are happy to look at it with you.