Launch is a midpoint, not a finish line
The four ongoing costs of custom software that almost nobody budgets for — and how to plan for them before you build.
Most people budget for software the way they budget for furniture: pay once, it lasts. Software behaves more like hiring. It has a salary, it has needs, and it will cost you something every month you own it — whether or not anyone planned for that.
The launch number is the number everyone negotiates. These are the other four.
1. Change
Your business will not hold still. A regulation shifts, a supplier changes their process, a competitor ships something that makes your “nice to have” urgent. Software that can’t change with the business gets abandoned — not on purpose, but by a hundred small decisions to work around it instead of in it.
Budget reality: expect meaningful changes within the first quarter of real use. If the plan has no answer for how changes happen — who decides, what they cost, how fast they land — the launch budget is a down payment, not a budget.
2. Operation
Hosting, domains, certificates, API bills, backups that actually restore. Individually boring, collectively the difference between software that runs and software that ran. The question to ask is not “what does it cost to host” but “who watches it” — because unwatched software fails silently, and silent failures are discovered by your customers.
3. Attention
Someone has to notice when the numbers look wrong. Someone has to hold the answer to “why does it do that.” That’s a person, part-time or more, forever. The good news: if decisions were written down as they were made, this job is small. If they weren’t, this job slowly becomes a person’s whole job — usually a person who has better things to do.
4. Recovery
Things break at the worst possible time; that’s not pessimism, it’s selection bias — the worst possible time is when the software is under the most load, which is when failure is likeliest. The cost isn’t the fix. It’s the hour between “it’s down” and “the right person knows what to do,” multiplied by every person waiting.
An answer to “who fixes this, how fast, on a Sunday” is a line item. Price it or discover it.
What to actually do
None of this is an argument against building. It’s an argument for counting. When you compare options, compare year-one totals, not launch quotes — the cheap build with no answers for these four is reliably the expensive one.
And when someone pitches you software, ask one question: “What does this cost in month thirteen?” The answer tells you whether they’ve ever lived past a launch. Software isn’t finished when it ships. It’s finished when it’s boring — and boring is a budget.
Working on something this applies to? Tell us about it — thirty minutes, no pitch.