Software Maintenance Costs: What to Budget After Launch

What do people actually mean by maintenance?

Four different costs travel under the one word, and separating them is most of the discipline. 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.

Something needs attention — which kind of cost is it?
  Defect inside the warranty window  → corrective: $0 (14–60 days)
  Hosting, domain, monitoring        → infrastructure: $10–50/month
  An external API changed            → adaptive: a few hours, 1–2×/year
  "Could it also do X?"              → perfective: new work — scope it
  Fixes arriving faster than value   → stop patching, rebuild fixed-price

What does the research say — and why do 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.

What does a small app cost to run each month?

Between $10 and $50 a month covers most of them. 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 does the 15–20% rule 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.

What does a realistic annual budget look like?

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.

PINCLER's perspective: how we keep maintenance cheap 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 does upkeep work cost when you do need it?

First-party data helps here too, because upkeep work is a recognisable build category. Across the 79 builds in PINCLER's fixed-price catalogue — all priced between $500 and $2,500, published at /research/what-you-can-build — cloud and DevOps work carries the lowest advertised price and the shortest quoted window: a median of $850 at a median 5 days. Integration work, the most common adaptive fix, is priced at a median $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.

Who needs a maintenance budget, and who needs almost none?

Maintenance spending scales with exposure, not with the size of the codebase. If your application takes payments, stores personal data, integrates with third-party APIs that version on somebody else's schedule, or runs on infrastructure you patch yourself, you need a real annual figure and a named person whose job includes it.

If the application is a small internal tool on managed hosting, with few dependencies and no payments or personal data, the honest annual figure is close to nothing beyond the hosting line. Plenty of small applications go a year needing a dependency bump and a certificate that renews itself, and pretending otherwise would be selling worry.

The distinction that matters is movement rather than age. Software sitting still on a managed platform ages slowly. Software touching APIs owned by other companies ages at whatever pace those companies choose, and that is the line item most budgets forget.

• Needs a real budget — payments, personal data, self-managed servers, or two or more third-party integrations.
• Needs a real budget — an application still being changed, because feature work and upkeep share one queue.
• Needs almost none — a low-traffic internal tool on managed hosting with a short dependency list.
• Best for a retainer — teams with a compliance obligation or a response-time commitment they can state out loud.

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 and alerting 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 catalogue median of $1,450. Unless the contract buys guaranteed response times you demonstrably need, that money purchases reassurance, not maintenance — one of the patterns we unpack in the hidden costs in software contracts.

When should you 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, and legacy app modernisation becomes the cheaper strategy.

The arithmetic is unusually kind at small scale. A fresh rebuild on a modern stack is priced at $500–$2,500 fixed — against the catalogue median of $1,450 — and is typically quoted 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.

How should you budget 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 — the build side of the budget is covered in our custom software development cost guide. If you want ours for a specific project, the free 30-minute call covers running costs alongside the fixed build quote.