Operations · 3 min read
What Keeping It Running Actually Costs
Software is usually budgeted as a project and lived with as a commitment. The build has a scope, a price, and an end date. What comes after has none of those, which is why it tends to be discovered rather than planned. Here is what it actually consists of.
The bill does not stop at launch
A running system consumes attention whether or not anyone is adding features to it. Dependencies publish security patches. Certificates expire. Platforms deprecate the APIs you are calling and give you a window to migrate. Browsers change. None of this is caused by anything you did, and all of it lands on you.
The failure mode here is not sudden. It is a system that is left alone for two years, at which point every dependency is several major versions behind, the upgrade path is no longer incremental, and a routine security fix has become a project. Deferred maintenance is a loan with a poor interest rate.
What maintenance actually covers
“Maintenance” is a vague word covering several distinct kinds of work, and it is worth separating them, because they have different urgencies:
- Security updates. Non-negotiable and time-sensitive. The window between a vulnerability becoming public and being exploited at scale is short.
- Dependency upkeep. Routine, dull, and much cheaper done continuously than in batches.
- Platform migrations. Forced on you by someone else’s deprecation schedule. The date is not yours to choose, but the notice period usually is generous if anyone is reading it.
- Corrective work. The bugs that only appear under real usage, real data volumes, and real users doing things nobody anticipated.
Monitoring, and what it is for
The point of monitoring is not dashboards. It is to shorten the distance between something breaking and somebody knowing. A system without it does have monitoring — it is your customers, and they report through complaints.
Useful monitoring tends to be narrower than expected. A handful of signals that correspond to the system doing its job — are requests being served, are they succeeding, are the background jobs completing, is anything queueing without end — will catch most real incidents. A wall of graphs nobody reads catches none of them.
Alerts should be rare enough that one is worth reacting to. An alert channel that fires all day trains everyone to ignore it, and the one that mattered arrives into that silence.
The emergency you have not had yet
At some point something will go wrong badly enough to need attention immediately. Planning for it costs very little and is almost never done.
The questions worth answering while nothing is on fire: who is called, and how? Who can authorise taking a feature offline to protect the rest? Where are the credentials, and does more than one person have them? When was the last time a backup was restored — not taken, restored? An untested backup is a belief, not a plan.
Budgeting for it
The honest framing is that a system has a running cost from the day it goes live, made up of hosting, upkeep, and a share of somebody’s attention. Treating that as an ongoing line rather than an unwelcome surprise changes the decisions made during the build, usually for the better — fewer moving parts start to look attractive when someone has to keep them all running.
It also changes what gets built. A team that knows it is maintaining something tends to build the simpler version, and the simpler version is usually the one still working in five years.
Build Software That Grows Your Business
From custom software development and AI automation to cloud-native applications, we create secure, scalable solutions built for long-term success.
Get Free Consultation