The 15-25% figure isn't a guess
Ask five dev shops what software costs to maintain and you will get five slightly different numbers, but they cluster in the same band. Pulsion's 2026 breakdown of build-to-maintenance ratios puts annual maintenance at 15-25% of what it cost to build the software in the first place. The maintenance rule of thumb attributed to Gartner lands in the same range: 15-20% of your original build cost, every year, for as long as the system stays in production. On a 150,000 dollar build, that is 22,500 to 37,500 dollars a year - not a one-time true-up, a recurring line item.
The number holds up across sources because maintenance is not discretionary spend you can zero out. Research cited alongside the Gartner figure puts roughly 60% of a system's total lifetime cost in the maintenance phase, with only 40% going to the original build. Most teams budget the 40% down to the sprint and treat the 60% as an afterthought, which is backwards from how the money actually gets spent.
What the percentage actually buys
15-25% is not one thing. It is four different kinds of work with very different urgency profiles, and the split matters more than the headline number when you are setting a budget. Pulsion's category breakdown of a typical maintenance spend looks like this:
| Category | Share of Maintenance Budget | What It Covers |
|---|---|---|
| Corrective | 20-25% | Fixing bugs, crashes, and errors that only show up once real users and real data hit the system |
| Adaptive | 15-20% | Keeping the software working as the world around it changes: OS updates, browser changes, third-party API changes |
| Perfective | 25-30% | Feature enhancements, workflow improvements, and performance work driven by real user feedback |
| Preventive | 5-10% | Refactoring, dependency upgrades, and documentation that reduce how much corrective work you need later |
Notice what is missing from that table: hosting. Infrastructure is usually tracked as a separate line rather than folded into the maintenance percentage, and it scales with usage rather than headcount. Benchmarks for a growth-stage application put compute, database, CDN, email, and monitoring at roughly 100 to 400 dollars a month early on, climbing well past that as traffic and data volume grow. Budget maintenance and infrastructure as two separate numbers, not one blended figure - they grow on different curves.
Run the math on a 150,000 dollar build sitting at the middle of the range, 20% a year: that is 30,000 dollars annually. Split across the categories above at their midpoints, that lands around 6,750 dollars on corrective fixes, 5,250 on adaptive compatibility work, 8,250 on perfective enhancements, and 2,250 on preventive upgrades, plus infrastructure tracked separately, starting in the low hundreds a month and climbing with traffic. None of those columns is really discretionary the way a marketing line item is. You can trim perfective work in a lean quarter and ship fewer enhancements. You cannot meaningfully trim corrective or adaptive work without the system eventually breaking in front of users.
Year one looks nothing like year three
The 15-25% figure is an average across a system's life, and averages hide the shape of the curve. In practice, maintenance cost front-loads hard in year one, then settles into a lower steady state, then starts climbing again as the system ages.
Benchmarks compiled across build sizes show the pattern clearly:
- A 30,000 dollar MVP runs 6,000 to 10,000 dollars in year-one maintenance, then drops to 4,500 to 6,000 dollars a year once things stabilize.
- A 75,000 dollar-plus product runs 15,000 to 25,000 dollars in year one, settling to 11,000 to 15,000 dollars a year after that.
- A 200,000 dollar-plus platform runs 40,000 to 70,000 dollars in year one, settling to 30,000 to 50,000 dollars-plus once the initial bug wave clears.
Year one runs hot because that is when real users find everything your test suite did not: edge cases in production data, load patterns nobody modeled, integration failures with systems you do not control. Some benchmarks put first-year maintenance as high as half of the original build cost for smaller products. If your year-one maintenance budget looks like a flat 15% of build cost, you have under-budgeted it.
Then, further out, the curve turns upward again. A widely cited case tracked one legacy enterprise application's annual maintenance cost at 2.4 million dollars in year one, 2.7 million in year two, and 3.6 million by year five - a 50% increase, driven by maintenance costs that compound at roughly 10-20% a year as the talent pool that understands an aging stack shrinks, vendor support gets more expensive, and unresolved technical debt keeps adding friction. You will not see numbers that large on a typical custom software project, but the shape of the curve applies at any size: cost drops after year one, then climbs again once technical debt starts compounding.
Skipping the preventive maintenance line, the 5-10% for refactoring and dependency upgrades, does not remove that cost from your budget. It defers it into next year's corrective column, where the same research puts the multiplier at three to five times the price. Every dollar you do not spend on prevention becomes three to five dollars of firefighting later.
What deferred maintenance actually costs you
The compounding effect is not abstract. A frequently cited developer survey found that engineers at companies with significant legacy footprints spend about 42% of their work week, roughly 17 of 41 hours, on maintenance and technical debt rather than new work, with aging systems named as the primary driver. Organizations with heavy legacy footprints report spending 60-80% of their entire IT budget on maintenance, leaving as little as 20% for anything new. That is the end state of treating the preventive slice of the budget as optional year after year: the corrective and adaptive slices grow to consume almost everything.
This is also why the 15-25% figure should be read as a floor, not a target. A team that spends toward the low end every year while skipping the preventive category is not saving money, it is postponing a bill that arrives with interest.
Which contract model fits which stage
The right way to pay for this work changes as the system ages, and treating every year the same is one of the more common budgeting mistakes we see. In year one, a bug-fix-heavy retainer with headroom for unplanned hours makes sense, since you genuinely do not know yet what will break. By year two or three, once the corrective load has dropped, a blended retainer that mixes ongoing support with scheduled feature work tends to fit better, as perfective work becomes a bigger share of the total. Past year four or five, it is worth budgeting a dedicated technical debt paydown sprint on a regular cadence rather than letting preventive work get squeezed out sprint after sprint by whatever feature is on fire that week, which is exactly the pattern behind the 10-20% annual compounding described above.
How to actually put a number on it
A few practical rules that hold up across the projects we have scoped:
- Budget maintenance as a percentage of what it would cost to rebuild the system today, not the number in an old proposal. Software gets more expensive to reproduce as it grows, and a stale baseline understates the real maintenance number every year.
- Staff year one differently from year two. Plan for the higher end of the range, or above it, for the first twelve months after launch, then revisit the number once the bug curve flattens.
- Keep the preventive category funded even when nothing is on fire. It is the only line item in the table above that reduces next year's bill instead of just paying this year's.
- Track infrastructure separately from engineering effort. Blending them hides which one is actually growing.
None of this is an argument for maximizing the maintenance budget either. The point of tracking the categories separately is that it gives you a lever. A team that can see corrective spend rising quarter over quarter has a concrete signal that something upstream, test coverage, code review standards, the original architecture, needs attention, rather than a vague sense that the software feels expensive to run. A team that only tracks one blended maintenance number never gets that signal; the bill just quietly grows every renewal and nobody can say why.
How well this works depends heavily on how the system was built and scoped in the first place. When we run projects through our process, maintenance is not an afterthought we estimate at handoff, it is scoped alongside the build, so a client knows the year-one number before the first line of code is written. And a lot of what determines whether year three looks like a manageable 15% or a compounding mess comes down to decisions made during the original build. See how we approach custom software for the maintainability choices, test coverage, documentation, dependency hygiene, that keep the preventive column cheap instead of letting it turn into the corrective column two years later.
Don't let maintenance be a surprise line item
We scope the maintenance budget alongside the build, not after you have already shipped. Tell us what you are running and we will tell you what to actually set aside.
Frequently asked questions
Is the 15-25%-a-year rule accurate for every kind of project?
It is a reasonable starting point, but the real number shifts with size and age. Smaller applications tend to run toward the higher end of the range as a percentage of build cost, while larger enterprise systems can sit lower as a percentage but far higher in absolute dollars. Age matters too: year one typically runs hotter than the average, and systems past year five often climb again as technical debt compounds.
What is normally included in a maintenance retainer versus a new project?
A maintenance retainer typically covers bug fixes, security patching, dependency and platform updates, monitoring, and small enhancements driven by user feedback. Larger feature work, a new module, a redesign, a new integration, is usually scoped and billed separately, even if the same team does the work.
Should hosting and infrastructure be part of the maintenance budget?
Track them separately. Maintenance labor, the 15-25% figure, covers engineering effort. Infrastructure cost scales with usage and traffic rather than headcount, so blending the two numbers makes it hard to tell whether a rising bill is due to more engineering work or more customers.
How can we reduce maintenance spend without cutting corners?
Keep the preventive category funded, refactoring, dependency upgrades, and documentation, even when nothing is broken. Research on preventive versus corrective maintenance spending found that a dollar spent on prevention avoids three to five dollars in later corrective fixes, so the fastest way to raise your maintenance bill is to skip the part of it that looks the most skippable.