Custom Software Maintenance: What It Actually Costs After Launch

Most build cost estimates don't include the maintenance reality. The build is the start of a relationship with your software, not the end. Here's what maintenance actually costs after launch, what it covers, and how to think about it.

The 15–25% rule

The industry rule of thumb: annual maintenance budget for active software is 15–25% of the build cost.

A $100k build → $15–25k/year maintenance

A $250k build → $40–60k/year maintenance

This isn't optional. Modern web applications have dependencies that update constantly. Browser security patches, library updates, framework upgrades, third-party API changes. Skipping maintenance for 12+ months turns small updates into major upgrade projects later.

What maintenance covers

Defensive maintenance (10–15% of cost annually)

Dependency updates (npm packages, framework versions)

Security patches

Browser/device compatibility as standards change

Third-party API updates (Stripe, AWS, etc.)

Light bug fixes from real-world usage

Backup and monitoring tuning

Active maintenance (5–15% of cost annually)

Small feature additions and UX improvements

Performance optimisation as data grows

Reporting and analytics changes

Integration additions

Sometimes-needed (variable)

Major version upgrades (every 2–3 years for major frameworks)

Compliance changes (new regulations, browser policies)

Significant scaling work as usage grows

What it doesn't cover

Maintenance retainers typically exclude:

Major new feature builds (those are scoped separately)

Architectural overhauls

Migration to new tech stacks

Adding new user types or roles

Significant integrations with new systems

The line between "maintenance" and "new feature build" is fuzzy. The safe rule: if it requires architectural decisions, it's a new build.

How maintenance retainers typically work

Most custom software shops offer maintenance as either:

Hours-per-month retainer: $1,500–$5,000/month for 10–30 hours of engineering. Hours roll over up to a cap. Unused hours don't compound forever (typically 90-day max).

Percentage-of-revenue: For revenue-share or subscription engagements, maintenance is included in the ongoing fee.

Per-incident: Pay per fix at a higher hourly rate. Cheaper for software that genuinely doesn't change much, more expensive overall once you're using it.

When to take maintenance in-house

If you have an engineer who:

Knows the codebase

Has at least 8–10 hours/week to dedicate

Is empowered to update dependencies and ship fixes

Can stay updated on security advisories for your stack

Then in-house maintenance is cheaper. Otherwise, retainer math usually wins.

The hidden cost of skipping maintenance

Software that's not actively maintained accumulates technical debt at compounding rates. Common patterns we've seen:

Year 2 skipped: dependencies fall 18 months behind. Migration is a 1–2 week project later.

Year 3 skipped: major framework version is now deprecated. Security patches no longer available. Migration is now a 4–8 week project.

Year 5 skipped: the framework is in legacy mode. Vendors won't support hosting. Some integrations have changed API contracts. Migration is now closer to a rebuild.

The cheapest path is steady maintenance, not delayed catch-up.

What this means for your decision

When evaluating custom software cost, mentally add a maintenance budget:

15% of build cost annually if your software is fairly static

25% if you'll be iterating on features regularly

If a vendor offers a build without addressing maintenance, ask. If they don't offer maintenance, plan for it yourself.

For a transparent cost estimate including maintenance scope, our cost calculator accounts for both. Or contact us for a 48-hour scope.