The Bill Nobody Quotes You: What Owning Custom Software Really Costs

Software isn't bought. It's kept. Every proposal you receive prices the building of a system, and almost none of them price the keeping of it. That gap is where most disappointment with custom software actually lives — not in the build, which usually goes roughly as promised, but in the quiet years afterward, when the thing that was supposed to run in the background starts asking for attention nobody planned for.

This is the piece I wish someone had handed to the people who sign these contracts. None of it is specific to how any one firm works, and none of it requires a technical background to use. It is a plain description of what an owned system asks of you over time, a one-page register worth keeping, and a set of questions you can put to anyone proposing to build you something — including us.

Every system you own is a system somebody has to keep.

Year one is not the expensive year

Year one is the visible year. It's scoped, staffed, and on a calendar. There is a launch date, there is attention from leadership, and there is goodwill — everyone involved wants the new thing to work. Whatever it costs, you can see it coming.

The years that surprise people are the ones where nothing notable happens. There's no project, no budget line, no owner whose performance review mentions it. The system runs. Underneath, a slow and uneven series of small obligations accumulates: an expiring certificate, a runtime approaching end of life, a report format the state quietly changed, a staff member leaving with the only clear understanding of why a particular rule works the way it does.

Organizations that have never owned custom software tend to budget it like equipment — one large purchase, then depreciation. It behaves much more like a building. The purchase is the beginning of the cost, not the whole of it, and the maintenance you defer doesn't disappear. It compounds, and it tends to present itself at the worst available moment.

What actually decays

Working software does not rot on its own. Left alone on a machine nobody touches, it would keep doing exactly what it did on launch day. The decay comes from outside, and it is worth naming specifically, because vague warnings about "maintenance" are easy to nod at and ignore.

Runtimes and dependencies reach end of life. The language runtime, the database engine, and every library underneath your system has a support window. When one closes you are either on a newer version or you are running something that no longer receives security fixes. These dates are published years ahead, and there are community-maintained end-of-life calendars that collect them in one place. This is knowable information, which is what makes it frustrating when it arrives as a surprise.
Platforms change their requirements. If any part of your operation runs on a phone, the app stores set the terms, and they periodically require a rebuild against a newer SDK to stay listed. That work arrives on their schedule, not yours.
Integrations move. Payment processors, email providers, payroll systems, accrediting bodies, state reporting layouts — every external system you exchange data with is on someone else's release schedule, and none of them ask permission.
Credentials expire. Certificates, API keys, domain registrations, signing identities. Individually trivial. Collectively they are among the most common reasons a system that worked yesterday does not work this morning, and they fail on a specific date that was always knowable.
Security is a moving target. The patch that matters is the one released after you stopped paying attention. This is ongoing work by definition; there is no version of a system that is finished being secured.
The operation itself changes. A new program, a new location, a new regulation, a role that didn't exist when the workflow was mapped. A system that can't follow the operation becomes a system people work around — and the workarounds are how an organization finds its way back to spreadsheets.
The knowledge leaves. The person who knew why a rule was written that way takes another job, and the reasoning goes with them.

That last one is the most expensive and the least budgeted. Every other item is a task. This one determines whether the tasks can be done at all.

Keep a one-page ownership register

The single most useful thing a non-technical owner can do is maintain one page — a document, a wiki entry, a pinned note, it genuinely does not matter — that answers the questions nobody can answer during an outage. Suggested contents:

Every external dependency and its published end-of-support date. Runtimes, databases, frameworks, and the operating systems they run on.
Every credential and its expiry, with a named owner and a reminder set well ahead of it. Certificates, API keys, domain registrations, signing identities, processor keys.
Where the source code lives and who can reach it today. Not who could work it out in principle. Who has access this morning.
The date of the last restore you actually performed. Not the last backup that ran — the last time a person took a backup and rebuilt a working system from it.
Every external system you exchange data with, and where that system announces changes. Most publish a changelog or a deprecation notice; almost nobody subscribes to them.
Who answers when it breaks, and who answers when that person is away.
The decisions that aren't obvious from the screen. Why a rule rounds the way it does, why a field is required, which regulation drove which behavior. A page of these is worth more than most technical documentation.

It is genuinely one page. The value is not in its sophistication; it is in the fact that it exists somewhere other than in one person's memory.

A backup you have never restored is a hypothesis.

Six questions, and what the answers mean

Ask these of anyone proposing to build you software, and of anyone already maintaining software for you. They cost nothing to ask and the answers are more informative than any portfolio.

“When it breaks at 7am on the first day of a new term, who answers?”

A good answer names a person or a rota, and a response time someone could be held to. A weak answer is “email support” with no hours attached. You are not looking for heroics. You are looking for evidence that somebody has already thought about the worst morning of your year.

“Who holds the credentials?”

A good answer is that the cloud accounts, the domain, and any app-store listings are in your organization's name, with the vendor granted access to them. A weak answer is that everything sits in the vendor's account for simplicity. That arrangement is genuinely simpler — right up to the one day it is the only thing that matters.

“Where does the source code live, and what happens to it if we stop working together?”

A good answer is a repository you own or can be handed on request, plus a written statement of what you may do with it. Reasonable firms differ on how much they assign versus license, and that is a fair negotiation to have. What is not fair is discovering the answer in the middle of a disagreement.

“Can we export all of our data, including the parts that never appear on a screen?”

A good answer comes with a format and, ideally, a sample file. Reports are not an export. Audit history, attachments, and the records behind a calculation are exactly the parts people find missing at the moment they need them most.

“What is the update cadence, and who decides what gets updated?”

A good answer distinguishes security patches, which should not require a debate, from feature work, which should. If both are treated the same way, one of them is being neglected.

“What does it cost to leave?”

A good answer is a number, or an hourly rate and an honest estimate of hours. The content of the answer matters less than the reaction to the question. Nobody should have to buy their way out of their own records.

What belongs in the agreement

Four things are far easier to settle before the work starts than after, and none of them are adversarial to ask for:

Ownership or a durable license for the source code, stated explicitly.
Accounts and domains registered in your organization's name from day one.
A data export in a documented, machine-readable format, available on request rather than on good terms.
A notice period and defined exit assistance, priced.

A firm that has thought carefully about how you would leave is usually a firm that has thought carefully about the rest of it too.

If you do only two things

Put a restore test on the calendar — an actual rebuild from an actual backup, performed by a person, at least once a year. And ask what it costs to leave, of whoever maintains your systems now, before you have any reason to need the answer.

Both are close to free on an ordinary Tuesday. Both are impossible on the day they matter.