AXENTED — Blog Article

Software Maintenance Cost: What to Budget After Launch

Slug: /blog-posts/software-maintenance-cost

Meta description: Most software budgets end at launch. The real cost of ownership includes infrastructure, security, maintenance, and support — typically 15–25% of build cost per year.

Target keywords: software maintenance cost, post launch software cost, software total cost of ownership, software support budget

The software development invoice gets paid. The project ships. Everyone celebrates. Six months later, the same company is spending 40% of what they spent building the system just to keep it running, and nobody budgeted for it.

This is the post-launch software cost conversation that should happen before the project starts.

The Standard Budget Failure

Most software budgets cover discovery, design, development, and launch. They don't cover what comes after: ongoing hosting, security updates, dependency maintenance, bug fixes, small feature additions, performance optimization, and the accumulated work of keeping a production system running reliably over time.

The industry benchmark for software maintenance cost is 15–25% of the initial development cost per year. A system that cost $200,000 to build will typically require $30,000–$50,000 per year to maintain. That number surprises clients who budgeted for development but not for the life of the system.

Infrastructure: The Visible Cost

Cloud infrastructure is the easiest maintenance cost to quantify. Compute, storage, database, networking, CDN, monitoring tools — these show up as monthly invoices and are straightforward to project from initial usage patterns. Common mistake: projecting infrastructure costs based on development environment usage rather than production traffic patterns. Production systems handle more requests, store more data, and need more redundancy than development environments. Budget two to five times your development environment cost for production infrastructure, depending on traffic expectations.

Security: The Non-Negotiable Cost

Every application has dependencies — libraries, frameworks, and third-party packages that other teams maintain. Those dependencies have vulnerabilities. New vulnerabilities are discovered continuously. Not updating dependencies means running known vulnerabilities in production, which is how most breaches happen.

Dependency maintenance is recurring, non-optional work. For a typical web application, expect to spend four to eight hours per month on dependency updates, testing that the updates didn't break anything, and deploying the changes. That's engineering time with a real cost. Add to it the cost of addressing any application-level security findings from periodic penetration tests, which should happen at least annually for any system handling user data.

Feature Maintenance vs. Feature Development

There's a distinction that most software budgets blur: the cost of keeping existing features working versus the cost of adding new ones. Existing features break. Not catastrophically, usually — the breakage is subtle. A third-party API changes its response format. A browser update changes a CSS behavior. A database grows large enough that a query that ran in 50ms now runs in 500ms. Keeping up with this ambient degradation requires a steady allocation of engineering capacity even when you're not adding new features.

Budget 10–15% of your engineering capacity for maintenance of existing features. If you have one full-time engineer, that's roughly two to three hours per week. If you have five engineers, that's half an engineer's time. This capacity shouldn't compete with feature development in sprint planning — it should be reserved before the sprint is allocated.

The Support Cost That Nobody Counts

Every deployed application generates support questions. Users encounter errors, can't find features, or hit edge cases the team didn't anticipate. For internal tools, that support falls on the engineering team. For customer-facing products, there's usually a support function — but bugs that surface through support still require engineering time to diagnose and fix.

Track the engineering time spent responding to support-driven bugs and questions for one month. The number is usually higher than teams expect, and it provides a real baseline for what to budget.

The Total

A realistic post-launch annual budget for a mid-complexity web application: infrastructure ($12,000–$24,000), security and dependency maintenance ($8,000–$15,000), ongoing bug fixes and minor features ($20,000–$40,000), and support engineering ($5,000–$10,000). Total: $45,000–$89,000 per year.

That budget is the cost of ownership. It should be discussed before the development contract is signed, because it changes the economics of whether the system makes sense to build.