Software Maintenance Costs: What to Budget After Launch

The four things people mean by maintenance

Maintenance conversations go wrong because four different costs travel under one word. Infrastructure is the true monthly cost: hosting, domain, email, monitoring. Corrective work is fixing defects. Adaptive work is responding to change from outside — an API you integrate with alters its interface, a platform deprecates a feature. Perfective work is improvements, which is really new development wearing an old name.

Separating them changes how you budget. Infrastructure is predictable and small. Corrective work concentrates in the first weeks after launch, which is why our builds carry a 14–60 day warranty by tier. Adaptive work arrives in occasional lumps driven by the outside world. Perfective work is optional and should be scoped and priced as the new feature work it is.

What the research says — and why small apps differ

The software-engineering literature takes maintenance seriously for good reason. Estimates collated in Vention's 2024 maintenance benchmark range from 67% of total lifecycle cost (Schach) to over 90% (Erlikh), and the same benchmark notes that annual maintenance for actively developed systems typically runs 15–25% of the original development budget. Those numbers are real, and for enterprise systems they are earned.

But look at what produces them: decades-long lifespans, constant feature change, large user bases filing tickets, integration webs that shift monthly, and teams whose salaries are the real cost. A $1,500 booking system with one integration and a stable feature set shares none of those properties. The research describes systems under continuous modification; a small app that works is mostly left alone, and its costs collapse to infrastructure plus rare events.

The practical conclusion is not that maintenance is a myth — it is that the percentage rules are the wrong instrument at small scale. Budget events and infrastructure, not percentages, and revisit if your app grows into something that ships changes every month.

Realistic monthly numbers for a small app

These are typical figures for the applications we ship — booking systems, CRMs, dashboards, chatbots — running on modern managed platforms at small-business traffic. Most clients land near the bottom of each range.

Why the 15–20% rule does not fit small apps

The percentage convention assumes a system under continuous change: many users filing tickets, integrations shifting, a team making steady modifications. Small custom apps do not live like that. A booking system that works in month one usually still works, untouched, in month eighteen — software does not wear out; its surroundings change.

So budget by events rather than percentage. Expect a cluster of small fixes right after launch, covered by warranty. Expect one or two adaptive events a year — a dependency upgrade, an API change — each a few hours of paid work. A realistic annual developer budget for a small app is a few hundred dollars, held in reserve rather than paid monthly to nobody in particular.

The event model also changes who you need. Percentage budgeting implies a standing relationship with whoever built the system; event budgeting only requires that the code be maintainable by anyone competent, which is a property you can verify at handover. A documented, mainstream codebase in your own repository converts maintenance from a dependency into a shopping decision you make once or twice a year.

A worked annual budget, every input shown

Here is a complete year for a typical small app, priced line by line. Infrastructure: hosting at $10 a month is $120; a managed database at $5 a month is $60; the domain is $15; monitoring rides a free tier. Annual infrastructure total: $195.

Now the events. Assume two adaptive events in the year — say a payment-API version bump and a framework security patch — at roughly three hours each. At a mid-range independent rate of $60–100 an hour, that is 6 × $60 = $360 at the low end and 6 × $100 = $600 at the high end. Worst-case annual total: $195 + $600 = $795. Typical-case: closer to $400, and in a quiet year just the $195.

Compare that with the enterprise convention applied naively: 20% of a $100,000 build is $20,000 a year — a different universe, because it prices a team, not a utility bill. The small-app number is a utility bill with an occasional plumber visit, and budgeting it any other way buys anxiety rather than reliability.

What makes maintenance expensive — and how we avoid it at build time

Most runaway maintenance bills are built in on day one. The choices that inflate them are well known: exotic frameworks that few developers know, self-managed servers that need patching, sprawling dependency trees, and undocumented cleverness only the original author understands.

The countermeasures are equally unglamorous, which is why they work. We build on mainstream stacks with enormous communities, deploy to managed platforms so server patching is someone else's full-time job, keep dependencies few and standard, and hand over documented code in your own GitHub. This is standard practice for disciplined custom software development, not a premium feature.

AI-assisted tooling reinforces it. With Stack Overflow's 2025 Developer Survey finding 84% of developers using or planning to use AI tools, conventional, well-documented code has become even cheaper to maintain — any competent developer, aided by the same tools, can read and safely modify a mainstream codebase they have never seen before.

What upkeep-class work costs when you do need it

First-party data helps here too, because upkeep work is a recognisable project category. Across PINCLER's 79 documented projects — all fixed-price between $500 and $2,500, published at /research/what-you-can-build — cloud and DevOps work is the cheapest, fastest category: a median of $850 delivered in a median of 5 days. Integration work, the most common adaptive fix, runs at a median of $1,200 and 10 days.

Those numbers are for whole projects — a deployment pipeline, a monitoring setup, a rebuilt integration — not for the three-hour patches most maintenance events actually require. They mark the ceiling of what an adaptive event should ever cost a small app: if a vendor quotes four figures to absorb an API change, the dataset gives you a reference point for pushing back.

Do you need a maintenance retainer?

For a small app, usually not, and we do not push one. What you actually need is three things: monitoring that tells you when something breaks before your customers do; a warranty window that catches launch defects, which is included; and a developer you can reach when an adaptive event lands. Pay for work when work exists.

Retainers earn their keep in specific cases: the app is revenue-critical and you want guaranteed response times, you ship changes monthly anyway, or compliance obligations require someone formally on the hook. If none of those apply, put the retainer money in a small reserve and spend it on improvements instead.

Run the arithmetic before agreeing to one. A $300-a-month retainer is $3,600 a year — more than double the worked worst-case budget above, and within sight of a complete rebuild at the 79-project median of $1,450. Unless the contract buys guaranteed response times you demonstrably need, that money purchases reassurance, not maintenance.

When to stop maintaining and rebuild instead

There is a point where maintenance stops being the cheap option, and it pays to recognise it early. The signs: adaptive fixes arriving faster than they can be absorbed, a framework past end-of-life, dependencies that no longer patch cleanly, and every small change risking two new breakages. At that point each fix is rent on a condemned building.

The arithmetic is unusually kind at small scale. A fresh rebuild on a modern stack costs $500–$2,500 fixed — against the 79-project median of $1,450 — and typically ships inside a month, with the old system running until cutover. If your last year of patches cost more than half of that, the rebuild is not an expense; it is the cheaper of the two maintenance strategies, and it resets the clock on everything in this guide.

One caution on timing: rebuild from strength, not from outage. The best moment is when the old system still works — data migrates calmly, the cutover can wait for a quiet week, and nobody negotiates under pressure. Waiting for the final breakage converts a planned $1,500 project into an emergency with your operations held hostage to the schedule.

Budgeting for your own app

Practical plan: take the table above and price your actual stack — most small apps land at $10–50 a month. Add a reserve of a few hundred dollars a year for adaptive work. Revisit annually. That is the whole discipline, and it beats both ignoring maintenance and over-insuring against it.

If you are scoping a new build, ask every bidder two questions: what will this cost per month to run, and what happens when something breaks in month seven? Clear answers are a good sign. If you want ours for a specific project, the free 30-minute call covers running costs alongside the fixed build quote.