When people budget for software, they budget for the build. It is the visible part, it has a start and an end, and it produces something you can look at.
The build is now the cheap part. Here is what the rest actually consists of, why it never appears in a quote, and what happens to companies that do not pay it.
What “keeping it alive” is made of
Not one job. About nine, most of them boring, none of them optional.
Watching. Something has to check the application is answering, from outside, on a short interval. Errors have to be captured with enough context to reproduce them, and routed to a person rather than into a dashboard nobody opens. This is the difference between hearing about an outage from your monitoring and hearing about it from your best customer.
Patching. Every library your application depends on is someone else’s code, and some of it will turn out to have a vulnerability. Nothing about your application changes; the world around it changes. Somebody has to be watching the advisories and applying the patches, on a schedule, forever.
Backing up — and restoring. Backups are easy and nearly everyone has them. Tested restores are hard and almost nobody has them. The gap between the two is discovered exactly once, at the worst possible moment.
Deploying safely. Changes need to reach production without an outage, and they need to be reversible when they misbehave. That means a staging environment, an automated check suite, and a rollback path — a modest amount of machinery that has to be built once and maintained forever.
Scaling. Capacity has to follow demand, which means it has to be measured. The alternative is finding your ceiling on the day you get written about.
Answering security questions. Every serious customer sends an assessment. Someone has to hold the answers, keep them current, and be able to defend them.
Controlling cost. Cloud spend does not stay still. Oversized resources, storage nobody reads, jobs running more often than anything needs — someone has to look, or the bill grows quietly.
Handling incidents. When something breaks, someone has to contain it, tell you, fix it, and afterwards explain what changed so it does not recur.
Being able to change it. Perhaps the most expensive of all. Software that cannot be modified in year three is a liability wearing the costume of an asset.
Who pays for this today
If you hired a team, you pay in salaries — two or three people, indefinitely, plus benefits and the management attention of someone who can evaluate their work. The work above is maybe a third of one person’s time, but you cannot buy a third of a person, and you cannot buy the on-call coverage separately.
If you used an agency, you did not pay for it, which means you did not get it. The build was quoted; the years afterwards were not. This is why so many agency-built applications are quietly abandoned eighteen months after delivery — not because they were badly built, but because nobody was left whose job it was to keep them.
If you used a cheap AI tool, you also did not pay for it, and you also did not get it. The difference is that here you may not know. The application looks finished. The absence shows up as an incident rather than as a line item.
If you did nothing, you pay anyway, in a currency that does not appear in the accounts: the founder’s evenings, the ops manager’s weekend, and the slow accumulation of a system nobody dares touch.
The number nobody quotes
The uncomfortable arithmetic is that ongoing operation typically costs more over a product’s life than the original build — often several times more — and it is the part with no natural moment to be quoted.
It has no deliverable. It has no launch. It succeeds by producing an absence of events. It is, structurally, the easiest thing in a budget to leave out and the most expensive thing to have left out.
Why it is cheaper when it is shared
Here is the part that makes a service like this possible at all.
Almost none of that work is specific to your application. Monitoring is monitoring. Patching is patching. Backup verification, deployment pipelines, secret management, incident processes, security documentation — the machinery is the same whether it serves one application or fifty.
Build it once, maintain it across everything, and the marginal cost of adding one more application to a well-run platform is genuinely small. Build it once per company, and every company pays the full cost of the same machinery.
That is the entire economic argument. Not that engineers are expensive — though they are — but that every company currently rebuilds identical operational infrastructure from scratch, badly, and then employs someone to maintain their own copy of it.
What to actually ask
If you are evaluating anyone to build you software, the build questions are the easy ones. Ask the other set:
- Who is told when it goes down, and how quickly?
- When was the last time a backup was restored, and did it work?
- How do security patches reach my application, and on what schedule?
- What happens if I want it changed in two years?
- Who answers my customer’s security questionnaire?
The answers will tell you whether you are buying software, or buying software and a second job.