The maintenance budget nobody plans for, and how to size it

A common rule of thumb is to budget 15–25% of the original build cost each year to maintain an app or website. That covers hosting, compatibility, security and fixes. Move towards the higher end for mobile apps, many integrations, regulated data or active development, and budget new features separately.

Most software budgets are built around a single number: what it costs to launch. Then the app goes live, and the invoices keep coming. Hosting, licences, updates, fixes, an urgent patch after a new iOS release. Nobody is surprised that these things exist. They are surprised that nobody planned for them.

Maintenance is the budget line that gets cut from proposals to make the headline price look better. Here is what it really covers, and how to size it honestly.

What maintenance actually pays for.

It is more than bug fixes. A live product needs ongoing work in five areas:

• Keeping it running. Hosting, monitoring, backups, and paid services such as maps, email and payments.
• Keeping it compatible. New iOS and Android versions, browser changes, and app store rule changes all arrive on someone else's schedule.
• Keeping it safe. Security patches and updates to the third-party code your product depends on.
• Keeping it working. Fixing bugs, including the ones that only appear with real users and real data.
• Keeping it useful. The small improvements your users and team ask for after launch.

The last of these is the one to watch. Bug fixes and new features are different kinds of work, and mixing them in one budget is how a maintenance plan quietly turns into an unfunded roadmap.

A number to start with.

A common rule of thumb is to budget 15–25% of the original build cost per year. In other words, expect to spend a real share of the build cost again every year to look after it properly.

Treat that as a starting point, not a quote. It is a planning convention, not a law. Published figures vary, and a product with an active roadmap can run well above that range. But it is far more useful than the figure many companies actually budget, which is zero.

How to size it for your product.

Move up or down the range based on what you have built.

Plan towards the low end if:

• It is a simple website or a stable internal tool.
• It has few third-party integrations.
• The feature set is settled, and usage is steady.

Plan towards the high end, or above, if:

• You have mobile apps, especially separate native apps for iOS and Android.
• You depend on many integrations, each of which can change without warning.
• You handle payments, health data or anything regulated.
• You are still actively adding features.
• The product runs AI features, which need regular review and tuning.

Five costs that catch people out.

Usage-based services. SMS, maps, cloud storage and AI services often charge by volume. Your bill grows along with your success.

Forced updates. When Apple or Google changes a requirement, you have to act by their deadline, whether or not it suits your roadmap. Fall too far behind, and you can lose the ability to release updates.

Third-party changes. A payment provider retires an old API version, or a courier changes its integration. Your code did not change, yet something has broken.

Technical debt. Corners cut to hit a launch date will be paid for later, and usually at a worse rate. Skipped upkeep compounds in the same way.

Lost knowledge. If the people who built the product have gone, a new team has to spend time learning it before they can change anything safely. This is one reason we keep the same team on after launch.

What happens if you skip it.

A neglected product rarely fails all at once. Small things stop working. The app gets slower. A security issue goes unpatched. Updating anything starts to feel risky, so the team stops making changes. Then one day the app stops working on a new phone, or a required update turns into a major project.

At that point you may be paying for a rebuild, which is far more expensive than the upkeep you tried to save.

How to set it up.

1. 01Budget at the start. Include year one of maintenance in the business case.
2. 02List your running costs. Write down every service, licence and what it charges for.
3. 03Separate fixes from features. Give each its own budget, so that upkeep does not get crowded out.
4. 04Agree response times. Know what counts as urgent and how fast it gets handled.
5. 05Get a monthly report. See what changed, what broke, and what is coming.
6. 06Review it every year. A product that has grown needs a budget that has grown too.

When you compare proposals, ask each supplier what happens after launch, who will do the work, and what it will cost. A low build price with a vague answer to that question is not a saving. If you would like a plan you can actually budget for, talk to us about maintenance and support.

Common questions.