software operations
Software Maintenance Cost: What Founders Need to Budget
Software maintenance cost is the recurring work of keeping a product safe, usable, and changeable. Budget by ownership and risk, not a borrowed percentage.
TL;DR — Software maintenance cost is the ongoing cost of keeping a product working, secure, supported, and ready to change. Budget it from your actual systems and owners; generic lifetime-cost percentages are not a forecast for your company.
Software maintenance is not a sign that a build failed. The moment a product has users, it meets changing browsers, operating systems, vendor APIs, security advisories, support requests, evolving data, and new business rules. The choice is whether that work is visible and owned, or whether it arrives as a series of expensive surprises.
Founders often try to estimate maintenance as a percentage of initial development. That shortcut is tempting, but it hides the variables that determine the real burden: number of integrations, change rate, reliability expectations, quality of tests and deployment recovery, vendor dependence, and who can diagnose a failure. Use a system inventory instead.
Separate the four kinds of upkeep
For planning, use four upkeep categories. Corrective work fixes defects after release. Adaptive work keeps the product working as environments, platforms, and integrations change. Perfective work improves performance, usability, or operating efficiency. Preventive work reduces foreseeable future failure, such as removing an unmaintained dependency or adding a recovery test.
The categories can overlap, but naming them helps. A payment API version change is adaptive work; a duplicated invoice is corrective; an automation that removes manual reconciliation may be perfective; a backup restore rehearsal is preventive. Each has a different trigger and different business value.
NIST’s Secure Software Development Framework treats security practices as part of the development lifecycle, including responding to vulnerabilities and maintaining released software. It is a useful corrective to the idea that security upkeep belongs in an occasional emergency budget.
Build a maintenance inventory
List every customer-facing service, data store, background job, integration, domain, and production account. For each, record the technical owner, business owner, change path, monitoring signal, recovery path, and any vendor renewal or deprecation date. The inventory is not documentation for its own sake. It tells you whether a maintenance request has someone who can act and someone who can decide its priority.
Then look at the past quarter: support tickets, deploy reversions, security updates, vendor changes, manual operations, and incidents. Group the work by source. A hypothetical product might discover that its largest recurring cost is neither servers nor bugs, but two hours a week spent reconciling a vendor export. That evidence may justify a small automation more clearly than a generic modernization project.
Budget capacity, not imaginary certainty
Set a recurring maintenance capacity based on what the product actually needs, and review it when the system or customer commitments change. Do not promise a fixed percentage as if it predicts the future. Instead, make a list of planned obligations and a small reserve for the unexpected. The reserve is not waste; it is how a team avoids choosing between an urgent repair and a customer promise.
The technical debt guide helps distinguish a recurring tax worth retiring from an imperfection that can wait. The build versus buy framework helps account for vendor ownership costs before a contract becomes difficult to exit.
Keep maintenance tied to outcomes
Every maintenance item should name the outcome it protects: recoverability, safe customer data, a supported workflow, a reliable revenue path, or a shorter change cycle. If it cannot name one, it may be a preference rather than a priority.
After an incident, turn the lesson into one owned action with a verification signal. Google’s incident management guidance recommends actionable, user-focused alerting and blameless follow-up. That is a better maintenance loop than a backlog full of “clean up” tasks.
Maintenance becomes manageable when it is ordinary product work: visible, scheduled, and tied to an owner. That leaves a founder free to decide which improvements create value rather than being forced to fund every surprise.
Ask one question at planning time
Before approving a feature, ask what it will require to operate after launch: alerts, customer support, permissions review, documentation, vendor monitoring, and a recovery plan. The answer need not block a small experiment. It does stop a temporary shortcut from quietly becoming an unowned production service.