Most software budgets are written as if the project ends on launch day. It does not. As January 2025 IT-budget meetings get underway and the new-year planning season hits its stride, the single line item that surprises buyers most is the one that arrives after the invoice for the build: maintenance. The timing is sharpened this year by real platform churn—React 19 went stable in December 2024, and every team running an older app now faces an upgrade they did not schedule. That is maintenance in its purest form: work that keeps a working product working. As the founder of Softechinfra, I have sat through enough budget reviews to know that the gap between what buyers plan for and what software actually costs to own is the most expensive misunderstanding in our industry. This guide closes that gap: what maintenance really is, the rule of thumb that survives every tech cycle, the four categories your money flows into, and how to budget so the bill is a plan instead of a shock.
The 15–20% Rule: Annual Maintenance as a Share of Build Cost
The most durable number in software budgeting is this: plan for annual maintenance of roughly 15–20% of the original build cost, every year, for the life of the product. Build a custom application for $80,000 and you should expect to spend $12,000–$16,000 a year keeping it healthy. This is not a quote and not a penalty—it is the cost of ownership, the same way a building has upkeep and a vehicle has servicing.
The rule holds across project sizes because the drivers scale with the system, not with the calendar. A bigger application has more dependencies to patch, more integrations that can break, more users filing edge-case bugs, and more surface area for security issues. The percentage stays roughly constant; the absolute number tracks complexity.
The figure that genuinely surprises buyers is the second one. Over a five-to-ten-year life, the money spent keeping software running and relevant dwarfs the money spent building it. Treating the build as "the cost" and maintenance as "extra" gets the proportion exactly backwards. The build is the down payment; ownership is the mortgage.
The Four Categories Maintenance Money Actually Flows Into
"Maintenance" is a vague word hiding four very different kinds of work. The classic software-engineering breakdown—still the clearest way to think about it—splits maintenance into corrective, adaptive, perfective, and preventive. Knowing which bucket your spend falls into is how you tell healthy investment from accumulating neglect.
| Category | What It Is | Typical Share |
|---|---|---|
| Corrective | Fixing defects and bugs found in production | ~20% |
| Adaptive | Keeping up with the moving world: OS updates, browser changes, API and dependency upgrades, new regulations | ~25% |
| Perfective | Enhancements and small features users ask for once the product is live | ~50% |
| Preventive | Refactoring, paying down tech debt, hardening before things break | ~5% |
The proportions surprise people. Most assume maintenance means bug-fixing, but corrective work is usually the smallest slice. The largest is perfective—the steady stream of "can it also do this?" requests that real usage generates. That is not a failure of the original build; it is the sign of a product people actually use. The danger category is the smallest one: preventive. It is the easiest to defer and the most expensive to skip, because deferring it converts into corrective work later, at a markup.
Adaptive is non-negotiable
Dependencies move whether you do or not. A framework like React shipping a major version, a payment provider deprecating an API, a browser changing default behavior—each forces work you did not choose. Budget for it as fixed, not optional.
Perfective is your growth engine
The feature requests that arrive post-launch are your roadmap, written by the people paying you. Funding perfective work is how a product compounds in value instead of stagnating.
Preventive is cheap insurance
A few days of refactoring a quarter prevents the cascade where one fragile module makes every future change risky and slow. Skip it long enough and you face a rewrite-or-refactor decision you would rather not.
Tech Debt Is a Loan—And It Charges Interest
The most useful mental model for the preventive bucket is debt. Every shortcut taken under deadline—the copy-pasted logic, the missing test, the dependency left three versions behind—is a small loan against future velocity. Like any loan, tech debt is sometimes the right move: shipping fast to validate an idea can be worth borrowing against. The mistake is never acknowledging the balance or making a payment.
The interest shows up as slowing velocity: features that used to take a week now take three, every change risks an unexpected break, and onboarding a new developer takes months because the codebase no longer explains itself. When the interest payments exceed the value of new work, you have arrived at the rewrite-or-refactor crossroads—the decision we walk through in detail in our guide on whether to rewrite or refactor. The cheaper path is almost always to never let the debt grow that large, which is exactly what the small, boring preventive budget buys you. Disciplined teams treat security patching and dependency upgrades as part of this same hygiene; it is one reason we fold secure development practices into ongoing maintenance rather than treating security as a one-time launch checklist.
What Drives the Number Up or Down
Two products with identical build budgets can have wildly different maintenance costs. The variance is predictable, and most of it is decided during the build—which is why, across our web development projects, thinking about maintainability before writing a line of code is the highest-leverage cost decision a buyer can make.
| Factor | Lowers Maintenance Cost | Raises Maintenance Cost |
|---|---|---|
| Test coverage | Automated tests catch regressions early | Manual-only testing; every fix risks a new bug |
| Dependencies | Few, well-chosen, actively maintained libraries | Many niche or abandoned packages |
| Documentation | Code and decisions are documented | Knowledge lives only in one developer's head |
| Architecture | Modular, clear boundaries between parts | Tightly coupled; one change touches everything |
| Integrations | Stable, official APIs with versioning | Fragile scraping or undocumented endpoints |
Regulated and integration-heavy systems sit at the higher end of the range. On a fintech build like Radiant Finance, maintenance is not just bug-fixing—it includes keeping pace with compliance changes, recertifying integrations, and auditing security regularly. That is adaptive maintenance the business cannot defer, and it is why we set maintenance expectations for finance and billing systems higher than for a marketing site. The same logic applies to anything that moves money or holds sensitive data; if you are weighing a custom system in that space, our guide to custom billing software covers where the recurring costs concentrate.
How to Budget So the Bill Is a Plan, Not a Shock
The goal is not to minimize maintenance spend—starving a product is its own expensive mistake—but to make it predictable and intentional. Here is the process we recommend to every client.
Set the baseline at approval
The day you approve the build budget, set aside 15–20% of it as an annual maintenance line. Make it a committed number, not a hope.
Split the budget across the four categories
Earmark money for corrective, adaptive, perfective, and preventive work. The preventive slice is small but sacred—protect it from being raided for features.
Choose a support model and price it
Decide between a retainer (a fixed monthly block of hours), time-and-materials (pay for what you use), or a dedicated team. Retainers suit steady upkeep; T&M suits unpredictable needs.
Track velocity as a leading indicator
If features keep taking longer to ship, your tech debt is compounding. Use that signal to redirect spend toward preventive work before it becomes corrective.
Review annually against reality
At each year's planning cycle, compare what you budgeted to what you actually spent, and adjust the percentage for the product's real complexity.
A quick word on support models, since it is where buyers most often choose wrong. A retainer gives you a predictable monthly cost and a guaranteed response window—ideal for a live product that needs to stay reliable. Time-and-materials is cheaper when needs are sporadic but offers no guaranteed availability, which hurts the moment something breaks at the wrong time. Most established products land on a small retainer for baseline upkeep plus T&M for larger enhancements—predictability where you need it, flexibility where you do not.
Maintenance is not a tax on a finished product—it is the price of keeping a useful tool useful while the world around it keeps moving. The teams that budget for it deliberately get years of compounding value from a single build. The teams that pretend launch is the finish line get a slow decline, a painful rewrite, and a much larger bill three years later. Plan for the 15–20%. Protect the preventive slice. Treat the build as the beginning of ownership, not the end of the project.
Planning a Build—Or Inheriting One That Needs Care?
We scope software with total cost of ownership in mind and offer maintenance models that keep your product healthy for years, not months. Let's plan a budget that holds up.
Talk to Softechinfra →
