What software costs after launch

A commissioned system has two costs. One is quoted, negotiated, and paid on a schedule. The other is not quoted, arrives in pieces, and is usually paid by whoever is nearest. The second one is larger.

This is not an argument against building software. It is an argument for knowing the shape of the whole cost before deciding what to build, because that knowledge changes the design — and the cheapest time to change a design is before it exists.

The four things that cost money after launch

Dependencies and security. A modern application is mostly other people’s code. That code is patched, deprecated, and occasionally abandoned, on a schedule nobody consulted you about. Left alone for eighteen months, an update that would have taken an afternoon becomes a project, because the versions have moved far enough apart that they no longer meet. This is the single most common way a working system becomes an expensive one.

Hosting and third-party services. Usually the smallest line, and the only one that appears on a card statement, which is why it gets the most attention and deserves the least. Worth watching for one reason: services that are cheap per unit and priced per use can change shape quickly when the product succeeds.

Changes the business asks for. Not defects — changes. A new tax rate, a new document type, a second office, a regulation, a competitor. These are not a sign that the first version was wrong. They are the system doing its job, which is to keep matching a business that will not hold still.

The cost of staying understandable. The one nobody itemises. Every system drifts from what its documentation says, and the gap is paid for in the hours it takes a new person to become useful. A system nobody currently understands is not maintained; it is merely running, and the difference shows up the first time it needs to change under time pressure.

A rough shape

For a system with a normal working life — call it five years — the build is somewhere around a third of the total, and the remainder is spread out unevenly, weighted toward the first year after launch and toward whatever year brings the largest business change. That is not a formula and it is not a quote. It is an order of magnitude, and its use is this: if the ongoing cost is not in the plan at all, the plan is wrong by more than any negotiation on the build will recover.

What makes the second number smaller

• Fewer dependencies. Every library is a small recurring obligation. The ones worth keeping earn their place against the code you would otherwise write, not against how easy they were to add.
• Boring choices in the load-bearing places. Interesting technology is fine at the edges. In the parts that everything else rests on, prefer what is well documented, widely used, and dull.
• Documentation written for the person who was not there. Not a manual. The three or four decisions that would otherwise have to be reverse-engineered from the code, and why they were made.
• Tests around the parts that would be expensive to get wrong. Not coverage for its own sake. The money and the deadlines.
• A working deployment on day one. If shipping a change is a ceremony, changes get batched, and batched changes are how small fixes turn into incidents.

What to ask before you sign

Three questions, and they are fair to ask of anyone:

1. What does it cost to run this for a year, with nobody adding features?
2. If we came back after two years of silence, what state would it be in?
3. What would another team need in order to take this over?

The answers matter less than whether they arrive readily. A supplier who has thought about the second cost has usually designed for it. One who has not will find out about it at the same time you do.