Software maintenance cost after launch: the year one bill

A build quote is a number for a piece of work with an end. Software does not have an end. The day it launches is the day it starts ageing, and the parts that age fastest are the parts nobody wrote: the database version underneath it, the runtime it executes on, the browser that renders it, the payment provider that changes an API.

This is not a warning about bad code. Well built software ages at almost exactly the same rate as badly built software, because the clock is being run by other people. What good building buys you is that the ageing is cheap to respond to rather than expensive. It does not stop the clock.

The quote covers the build, not the ownership

Ask what a system costs and you will be told what it costs to build. That is a fair answer to a badly framed question. Scoping a build is a bounded exercise and we have written about how to do it in how to scope a software project before anyone writes code. Scoping the ownership of that system is a different exercise that most buyers never run at all.

The gap shows up about four months after launch. Nothing is broken, nobody is unhappy, and there is no line in the budget for the work that is nevertheless arriving. Someone eventually pays for it, usually by letting it accumulate until it becomes a project of its own, which is the most expensive way to buy maintenance.

The dependency clock starts on launch day

The clearest way to see that maintenance is not optional is to look at the published support windows for the things your software sits on. These are not estimates or vendor pressure. They are dates, announced years ahead, and they arrive whether or not anyone has budgeted for them.

PostgreSQL states its policy plainly: "The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After this, a final minor version will be released and the software will then be unsupported (end-of-life)." Its versioning policy also sets the smaller rhythm, with minor releases carrying bug and security fixes "at least once every three months", and a recommendation that users "always run the current minor release associated with their major version".

That policy has a live consequence right now. PostgreSQL 14 reaches end of life on 12 November 2026. Any system that was launched on 14 and never touched is roughly ten weeks from running an unsupported database, and the work to move it does not become smaller by being left.

Node.js runs the same kind of clock. Its release documentation says long term support "typically guarantees that critical bugs will be fixed for a total of 30 months", and states the operating rule directly: "Production applications should only use Active LTS or Maintenance LTS releases." Thirty months is a generous window and it is still shorter than the life most businesses expect from a system they paid to build.

Where the money actually goes in year one

Maintenance is not one activity, and lumping it into a single line is what makes it feel unpredictable. Separated out, most of it is forecastable and only one row is genuinely uncertain.

The row people forget is the last one. Backups that have never been restored are not backups, they are an untested assumption, and the cost of finding that out during an incident is not comparable to the cost of a scheduled restore test. We made the fuller argument in a data backup strategy for a small business.

What a maintenance year should include

If you are being sold a maintenance agreement, these are the things worth insisting are named in it. Anything that is not written down is not included, whatever the conversation implied.

• Security and dependency updates applied, not merely reported to you
• A stated response time for something being down, separate from response time for something being wrong
• At least one tested restore from backup during the year, with the result written down
• Runtime and database kept inside their published support windows, with the migration planned before the end of life date, not after
• Whatever monitoring exists, and who receives the alert at two in the morning
• A named limit on included change requests, so both sides know where the line is

What it should not include

Maintenance should not be a bucket that new features are quietly paid from. That arrangement suits nobody: the vendor loses money on any month with real feature work in it, and the client loses the maintenance they thought they were buying because the hours went to the new report someone asked for.

It should also not be priced as a percentage of the build with no description attached. A percentage is a way of avoiding the conversation about scope, and it produces the same failure in both directions depending on whether the system turned out to be quiet or busy.

How to budget it without a made up percentage

You will find confident figures online for maintenance as a share of build cost. We are not going to repeat one, because the sources that carry those numbers do not publish a method behind them, and a number with no method is not more useful than an honest range.

A more defensible approach is to build the budget from things that have dates and prices. Look up the end of life date for every major dependency you are standing on and put the migration in the calendar year it falls in. Add the hosting and service costs, which are knowable and which we broke down in what a web app costs per month to run. Then hold a genuine contingency for the adaptive work, because something upstream will change and the only unknown is which thing.

For a service business quoting this to a client, the pricing structure matters as much as the number. BDG Labs set out a method for arriving at a service price without guessing in how to price a B2B service, and a maintenance retainer is exactly the case it describes: recurring, partly predictable, and easy to underprice by ignoring the unpredictable part.

Honest limits

Some systems genuinely need very little. A small internal tool with two dependencies, no payment integration and five users can sit for a year with nothing but version updates, and paying a monthly retainer for it would be waste. The honest answer for those is a small annual review rather than an ongoing agreement.

The other honest limit is that none of this makes the first year cheap. Defect work is front loaded, and a system launched in September will cost more to keep running between September and December than it will in any later quarter. That is normal and it is not evidence the build was bad. It is the shape of the curve, and knowing the shape is most of what stops the surprise. If the timeline is the part that surprised you rather than the cost, why software projects take so long covers the other half of the same question.