You hire software thinking you will pay to build it and then use it. In practice, most of the money goes to keeping what was already delivered running. It is common for 40%, 60%, sometimes 80% of the tech team's capacity to be tied up fixing, adjusting, and redoing something that already exists. Little is left for the new. And that ‘little’ becomes ‘nothing’ in the month with a fire.
This is not bad luck, it is not a lack of good people, and it is rarely a tool problem. It is the result of decisions that no one made at the start. This post explains in plain language where the leak is and how to shut off the tap before the next budget.
1. What ‘maintenance’ is and why it grows on its own
Maintenance, in the software world, is all the work the team spends to keep running what has already been delivered: fixing an error that showed up, adjusting a rule that ‘was not quite like that’, redoing a part that stopped holding up under use, handling a customer ticket. It is not building the new. It is holding up what exists.
Think of a construction job: the builder handed over the house, and every week comes back to fix a leak he himself caused. You pay for his hours again, and the house still does not get expanded. In software the same thing happens, but it is invisible, because the end customer does not see the builder coming back, they only see that ‘the new feature still has not come out’.
The result shows up in meetings like this: ‘we have no capacity for the new feature’, ‘the team is putting out fires this week’, ‘a critical problem came up and locked everything’. That is the bill arriving. And it grows on its own, because each rushed fix usually creates the next one.
2. Where the leak is: the work was done at the wrong time
There is a simple and cruel rule: every problem costs much less to solve before the system exists than afterward. In approximate numbers that keep repeating in the market: what costs 1 hour to solve before programming costs 10 hours after the system is ready, and 50 hours after it is live with users.
When you see a team living in maintenance, it is almost certain that the work that should have been done beforehand (agreeing on rules, anticipating error cases, planning the impact of the change) is being done afterward, in the form of a ticket and an emergency fix. The team is not executing badly. It is executing at the wrong moment on the timeline.
A construction analogy: discovering there is no outlet in the kitchen after the tiles are already laid. The outlet exists, will exist, but the cost of making it appear now is ten times higher than if it had been marked on the blueprint.
3. Agree beforehand: the blueprint of the system
Before programming a single line, three things need to be written, in language the business owner understands:
- The non-negotiable rules: what the system MUST always do. Example: ‘every sale generates an invoice’, ‘no customer can see another customer's order’, ‘inventory can never go negative’.
- What to do when there is a problem: each error case needs an agreed response. ‘If the payment fails, what state does the order stay in?’ ‘If the customer cancels after it has shipped, who gets notified?’
- Who talks to whom: which systems exchange information, at what moment, and what each one expects to receive.
This is the equivalent of the signed blueprint of the construction. Without it, every question that comes up during the build turns into improvisation. Improvisation in the build turns into a ticket after delivery. A ticket after delivery turns into maintenance. Maintenance turns into the bill that comes back every month.
The one who writes these three pieces is not just the technical team, it is the business owner alongside them. Good software starts with a well-agreed business decision, not with a chosen technology.
4. Plan before touching: seeing the possible damage
Every time you are going to change something in a system that is already running, there is a risk: what else could break along with it. Software is full of connected parts that are not always obvious. Touching one can stop another that no one was looking at.
Before any change, the team should be able to answer, in five written lines: which parts will be touched, in what order, what else could break along with it, and the way to roll back if things go wrong. Whoever cannot write this has not yet understood the change they are about to make. And they will find out what was missing in production, with the customer complaining.
Analogy: remodeling a room without turning off the breaker. It might all go fine. But the day the electrician touches the wrong wire, the whole floor stops. The question ‘which breaker do I need to turn off?’ takes two minutes. Not asking it can stop the building for hours.
5. Deliver with an off switch and a panel to watch
‘Deliver’ in the software market usually means ‘it went live, it worked, next’. That understanding is expensive. Real delivery has three components that separate the 5-minute fix from the 5-hour incident:
- An off switch for the feature: if the new functionality causes a problem, the team can disable just that one, without redoing the system, without stopping the rest. Without that switch, every new problem turns into an emergency fix under pressure.
- A panel to follow along: the new feature needs to ‘report’ whether it is working well or badly. Without a panel, the team only finds out about the problem when the customer calls complaining. And between the problem appearing and someone noticing, days go by.
- A rollback plan: if none of that solves it, how to go back to the previous version, in how long, and who triggers it. One written line. Whoever improvises this on the spot improvises it wrong.
Without these three, every delivery is a bet. When the bet goes wrong, it becomes an invisible maintenance queue: the problem stays live, no one sees it, and it costs in lost sales, an irritated customer, and staff hours working at night to fix it.
6. What to do with the maintenance you already have
The steps above solve the future liability. But you already have a liability in the present, and trying to kill it all at once is what destroys teams. Accumulated maintenance needs triage, not a task force.
Look at the list of problems that come back every week and classify each one by three questions: how often does it reappear?, how much time does each occurrence consume?, how often does that part of the system change?. The ‘load-bearing walls’ of the liability are the ones that score high on all three. Those go into a season of planned correction, with the rules written beforehand (even if late). The rest becomes a quick fixed-price fix or is accepted as an operating cost until the next review.
The classic mistake is to decide ‘let's zero out everything’. It cannot be done, and trying generates more problems (a rushed fix in already fragile code breaks something new). The target is to reduce what comes new into the queue, not to empty the queue. The queue shrinks as a consequence, over months, when the method of agreeing and planning beforehand becomes a habit.
7. Three numbers that show whether the method is working
You do not need a sophisticated dashboard. Three numbers, on a spreadsheet, tell the story:
- How many problems show up in the first 15 days after each delivery, divided by the amount of stuff delivered. If it is falling, it is a sign that agreeing beforehand is taking hold.
- How many tickets reveal ‘no one agreed it would be like this’. If it is falling, it is a sign that the system's blueprint is being written better.
- How long until the team discovers a problem. If it is falling, it is a sign that the panel is catching it before the customer complains.
Those three falling together mean the invisible cost is being cut at the root, not just moved around.
8. The main point
Maintenance does not disappear. But it stops being the destination of the budget. The difference between a team that lives fixing things and a team that delivers new things is where the work was placed on the timeline: before the code existed, or after the system went live.
Five lines agreed beforehand cost one meeting. Five hours of maintenance afterward cost a lost day, an irritated customer, and the month's delivery that did not come out. The method is not a trendy methodology, it is a decision about where to spend. Whoever decides to spend beforehand pays less. Whoever ignores it keeps getting the bill every month labeled ‘unforeseen’, and promising that next time there will be time to do it right.