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.