Software Maintenance Cost After Launch: What to Budget Each Year

The launch party is over, the app is live, and your team is finally using it. Then the first quiet question lands: "So what does this cost us now?" If nobody raised that question before the build, you are not alone. Most quotes for custom software cover the build and stop there. The years after launch are where the real total cost of ownership lives.

This post covers the ongoing cost of custom software: what you are actually paying for, the benchmark most firms use, how retainers compare with paying as you go, how to set a budget you can defend, and what happens when you skip maintenance for a year or two. If you are still pricing the build itself, start with our post on custom web app cost in 2026. This one picks up where that invoice ends.

What you are paying for after launch

"Maintenance" sounds like one line item. It is really six or seven, and they behave differently.

Hosting and infrastructure. Servers, databases, file storage, email delivery, backups. A small internal tool can run under $100 a month. A customer-facing app with real traffic can run into the thousands, and usage grows with your business.

Third-party services. Payments, maps, SMS, authentication, error tracking, analytics. Each is cheap alone. Together they form a recurring bill that surprises owners in year two.

Dependency and security updates. Every modern app sits on hundreds of open-source packages, a runtime, a framework and an operating system. Each ships patches and eventually stops being supported. Node.js, for example, guarantees critical fixes on a long-term support release for a total of 30 months, after which you are on your own. Keeping current is the work that prevents the expensive surprises below.

Bug fixes. No launch is bug-free. Real users find edge cases the test plan never imagined. Most fixes are small, but they need someone who knows the codebase.

Small improvements. A new report. A field on the intake form. An export the accountant asked for. Each is a few hours. Over a year they are usually the largest slice of the budget, and the slice that returns the most hours to your team.

Monitoring and on-call. Someone has to know the app is down before your customers tell you. Uptime checks, error alerts and a person who responds.

Vendor changes. An API gets deprecated. A payment provider changes its rules. None of this is your fault, and all of it costs time.

The 15 to 25 percent benchmark, and what it hides

The number you will hear most often is that annual maintenance runs 15 to 25 percent of the original build cost. It shows up in Edana's January 2026 guide to total cost of ownership, which calls it "a common rule", and in Andersen's April 2026 cost breakdown, which lists post-launch support at 15 to 25 percent of initial development annually. So a $120,000 build implies roughly $18,000 to $30,000 a year to keep it healthy and slowly improving.

Treat that as a planning range, not a quote. Three things move you inside or outside it.

How much the software changes. Edana's breakdown is useful here: corrective work (fixing what broke) is the minority share, adaptive work (keeping up with platforms and vendors) is 20 to 30 percent of the maintenance budget, and evolutionary work (new capability) is 40 to 60 percent. If your business is stable and the app does one job, you will sit near the low end. If the app is the business and you ship features every month, you can blow past 25 percent and should be glad to, because that is growth spend, not upkeep. Edana's own example is a Swiss company that had to lift its maintenance budget to 35 percent the year after launch.

How the build was done. Clean architecture, automated tests and current dependencies at launch make everything cheaper afterward. A rushed build with no tests makes every small change risky and slow. Maintenance cost is partly set on the day the build is scoped.

How many moving parts you own. More integrations, roles and data mean more surface area to keep working.

Retainer or pay as you go?

There are two honest ways to buy maintenance, and a third that only looks cheap.

A monthly retainer buys a fixed block of hours, a named person who knows your code, response-time commitments, and scheduled update work that actually happens. You pay in slow months too, which is the point: slow months are when dependency updates and refactoring get done. Retainers suit anything customer-facing, anything handling payments or personal data, and any tool your team cannot work without for a day.

Ad hoc hourly work means you call when something breaks or when you want a change. It is cheaper on paper and fine for a simple internal tool with low stakes. The catch is that nobody is watching the things that do not announce themselves: expiring certificates, deprecated APIs, security advisories. You find out when they fail.

The "we will call the original developer if we need to" plan is the one that looks cheap. Six months later the developer is on another project, the dependencies are two major versions behind, and the first hour of any fix is spent rebuilding the environment. This is how a $500 bug becomes a $5,000 bug.

If you are also deciding whether to staff this in-house or with an outside team, our comparison of fractional development teams versus in-house hires covers the cost math. For maintenance specifically, the deciding factor is usually continuity: the cheapest fix comes from whoever already knows the code.

How to set a budget you can defend

Start with the benchmark, then adjust it with what you know.

1. Take 15 to 25 percent of the build cost as your first-year range. Pick the low end for a stable internal tool, the high end for a customer-facing product.
2. Add hosting and third-party services separately. They are usage-based and paid to other vendors, so they do not belong in the developer line. Pull the actual invoices from month one and project growth.
3. Split the developer budget into "keep it running" and "make it better." A reasonable floor for the first bucket is a few hours a month for updates, monitoring and small fixes. Everything above that is improvement work you can speed up or slow down.
4. Set a quarterly review. Look at what was spent, what broke, and what the improvement work returned in hours saved or revenue. Adjust the next quarter.
5. Plan for the step changes. A major framework upgrade, a runtime end-of-life, a new compliance requirement. These are lumpy and predictable. Put a line in the annual budget for one of them.

One more thing worth measuring: hours returned. If a $400 improvement saves your operations lead two hours a week, it pays for itself in a quarter and keeps paying. A maintenance budget that includes small, well-chosen improvements is not a cost center. It is the reason you built custom software instead of buying off the shelf.

What neglect actually costs

Skipping maintenance does not save money. It defers it with interest.

Security is the sharp edge. Verizon's 2026 Data Breach Investigations Report found that 31 percent of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way attackers get in. Those vulnerabilities are, overwhelmingly, known issues with patches available. An app that has not been updated in 18 months is carrying a list of them.

Upgrade debt compounds. Skipping one minor version is an afternoon. Skipping four major versions across three dependencies is a week of work plus a round of regression testing, and it has to happen all at once, usually because something finally broke.

Users quietly route around it. When the tool gets slow, flaky or out of date with the real process, your team goes back to spreadsheets and email. The software still costs you hosting; it just stops returning hours.

Vendor deadlines do not wait. APIs get shut off on a schedule. If your payment or mapping integration stops working on a Tuesday, you are paying emergency rates for a fix that would have been routine six months earlier.

The pattern is the same in each case: the cheapest time to do maintenance is before you need it.

Questions to ask before you sign a build

The best way to control maintenance cost is to raise it before the build starts. A few questions that help:

• What will this cost per month to host and run at our expected usage?
• Which third-party services does it depend on, and what do they charge as we grow?
• What is your maintenance offer after launch, and what does it include?
• What happens to the code and the documentation if we stop working together?
• How will we know when something breaks?

A developer who answers these clearly is also the one whose software will be cheaper to keep.

Next step

If you have an app that is live and you are not sure what it should be costing you, or you are about to build one and want the ongoing numbers before you commit, we are happy to look at what you have and give you a straight answer, including when the answer is "a few hours a quarter is plenty." Book a free call and you will get a written recommendation within a few days, whether or not you work with us.