Your Software Maintenance Budget, Explained: Why "Done" Was Never the Point

A software maintenance budget is the yearly slice you set aside to keep a working system useful after it launches, and the part that surprises most owners is that the bulk of it is not repair. Decades of data show that roughly half of all software effort goes into systems that are already built and running, and most of that work is enhancement, your business growing and the software growing to match, rather than fixing anything broken. Budget nothing for it and the work does not disappear; it simply arrives later, unplanned, and at a worse price. A modest figure agreed at build time keeps every future change routine, while the same money spent in a panic feels like a run of ambushes. Here is what the budget actually buys.

The short version

• Maintenance is mostly growth, not repair. The classic research found enhancements, not bug fixes, dominate post-launch effort.
• "Done" is a myth for living software. The world around your system keeps moving, so a system nobody touches slowly stops working.
• A zero budget is the expensive choice. Deferred upkeep compounds into one big risky job, and the team quietly routes around the tool instead of improving it.
• Decide the slice at build time, in writing. A planned line item stays calm; the identical spend, unplanned, feels like an ambush.
• Watch the fix-versus-growth split. Mostly enhancements means a healthy system; mostly firefighting is a signal to act.
• Own the code, data, and accounts from day one. Upkeep pricing only stays honest when you can walk to another developer tomorrow.

Why is software never really "done"?

Back in 1980, the researchers Bennet Lientz and Burton Swanson surveyed 487 organizations about where their software effort actually went, and published the results in a book that is still cited today. The finding that startles founders: roughly half of all effort went into systems that were already built and running in their study. And the detail that matters most for your budget is what that maintenance work was made of. More than half of it, on the order of 60 percent, was enhancement, new things people needed the system to do, while only about a fifth was fixing outright bugs.

Sit with that ratio, because it flips the whole picture. The word "maintenance" makes you imagine a leaky faucet, a cost you pay because something is defective. The data says maintenance is mostly the opposite: it is your business expanding and your software expanding alongside it. The systems soaking up all that post-launch effort were not broken. They were being asked to do more, by people who had found them useful.

That survey is older than most of the companies we work with, and the pattern has not moved. If anything the modern environment churns faster: browsers update, operating systems shift, payment providers revise their interfaces, privacy rules change, and the platforms your software depends on retire old endpoints on schedules you do not control. Software nobody touches does not hold still. It slowly drifts out of sync with a world that refuses to.

What are you actually paying for after launch?

When you unpack what really happens to a business system after launch, the work sorts into three piles, and only one of them is repair.

Fixes. Genuine bugs, the smallest pile in a well-built system: a report that miscounts an edge case, a form that chokes on an unusual address. These cluster in the first months and then taper as the software settles into daily use.

Keeping up with the world. Nothing inside your business changed, but something around it did. The payment processor now demands a new authentication flow. A tax rule moves. The service your inventory sync talks to retires the interface version you launched on, exactly the kind of moving connection we make the case for owning properly in why API integrations beat copy and paste. None of this is anyone's fault, and none of it is optional. Skip it long enough and the software stops working on a day you did not choose.

Growth. The biggest pile, the 60 percent. You add a product line and need it in the system. A new hire needs a login and a role. The report that was perfect at launch needs one more column now that you sell in two states. A customer asks for something reasonable and you want to say yes. This is not upkeep at all; it is the system earning its keep by evolving with the business, the same trajectory we describe in how we build custom software, step by step: a strong first phase, then deliberate additions as real use teaches you what matters.

Once you can see the three piles, the yearly invoice stops reading as a suspicious repair bill and starts reading as what it is: mostly a growth budget with a small insurance policy attached.

What does a zero maintenance budget cost you?

Budgeting nothing for post-launch work does not make the work vanish. It only changes when you pay for it and how much it costs.

Deferred keeping-up work compounds quietly. Skip one year of small updates and you have a system running on aging dependencies. Skip three and the eventual catch-up is not three years of small invoices summed together; it is one larger, riskier job, because changes that would have been routine taken one at a time now have to happen all at once, on software nobody has opened in years. This is the same interest-charging dynamic we describe in technical debt, explained for owners, where the shortcut you never revisit quietly taxes every later change. Emergency work is also the priciest kind there is: it happens on the vendor's soonest open slot rather than a planned one, under pressure, while some part of your operation sits down.

There is a slower cost too. When every change requires a fresh negotiation from zero, changes stop being requested at all. The team learns that asking for one extra column is a whole procurement event, so they stop asking and start working around the software instead: the side spreadsheet appears, the manual step creeps back in, and the system slowly loses its fight for relevance. The tools that die are rarely the ones that break. They are the ones nobody budgeted to evolve, so everyone quietly stopped asking them to grow.

How do you set a maintenance budget, step by step?

Setting the budget is boring and effective, which is exactly why it works. Here is the sequence.

1. Decide the slice at build time, not after. Agree, in writing and before the build starts, that a small yearly percentage of the build cost is part of the real price of owning the system. The exact slice depends on how central the tool is and how fast your business changes; the number matters less than the fact that it exists. The build-cost figure it is a fraction of is the one we break down in what custom software costs.
2. Fold it into your payback math. Carry the yearly upkeep figure into the return calculation for the tool, so the number you use to justify the build is the one you will actually live with afterward. We walk through where that slots in over time in the custom software ROI timeline.
3. Pick the model that fits how requests arrive. Two shapes work for small businesses. A retainer is a fixed monthly amount covering keeping-up work plus a predictable allowance of small improvements, and it suits systems that sit at the center of daily operations with requests coming steadily. Prepaid blocks are a bank of hours or a set of small fixed-price mini-projects drawn down as needs surface, and they suit stable systems where changes arrive in bursts.
4. Insist on the same transparency you demanded during the build. Require a short log of what was done and why, work grouped into small described chunks rather than one opaque "maintenance" line, and a clear split between fixes, keeping-up work, and growth.
5. Watch the split over time. If most of your upkeep spend is enhancement, you own a healthy system that people want more from. If most of it is firefighting, that is a signal worth acting on, not a bill worth quietly paying.

A checklist for an upkeep arrangement that stays honest

Before you sign any maintenance arrangement, make sure you can check off each of these. They are what separate a plan from a trap:

• You own the code, the data, and the hosting accounts outright, from the first milestone, so you could move to another developer tomorrow.
• The yearly slice was agreed in writing before the build, not sprung on you with the first post-launch invoice.
• Every maintenance invoice itemizes the work in small, described pieces rather than a single lump line.
• The log distinguishes fixes from keeping-up work from growth, so you can watch the split.
• The model matches your reality: a retainer for steady demand, prepaid blocks for bursty demand.
• You review the arrangement at least yearly and can end it without losing access to your own system.

An upkeep arrangement you cannot exit is not a maintenance plan. It is rent, and the option to leave is what keeps the pricing honest whether or not you ever use it.

When should you not pay for maintenance?

A maintenance budget is not always the right answer, and it is worth saying so plainly.

If the tool is genuinely temporary, built to bridge a gap for one season or to test an idea before a bigger decision, then patching it indefinitely is waste. Give it an end date and let it retire on schedule. If the system runs entirely on mainstream off-the-shelf software, most of the keeping-up work is the vendor's job and is already baked into your subscription; do not pay a third party to duplicate what you are already buying. And if a custom tool has drifted so far from how the business now works that every change is a fight with its original assumptions, the honest recommendation is sometimes a focused rebuild of one piece rather than another year of increasingly expensive life support. We have told clients exactly that, including when it meant less work for us, because a retainer on software that should be replaced is money poured down a well.

The test is simple: maintenance money should buy you options, speed, and calm. The moment it is only buying survival, stop and reassess the system itself rather than the invoice.

Common pitfalls

The mistakes owners make with maintenance are consistent, and they mostly trace back to treating a living system like a finished object.

The first is pricing the build like a one-time purchase and budgeting zero for what comes after, which guarantees that year two lands as a shock. The second is signing an upkeep deal without owning the code and accounts, which quietly converts a maintenance relationship into a dependency you cannot escape. The third is paying every "maintenance" invoice without ever asking for the split, so a system that is actually being nursed through constant firefighting looks, on paper, identical to one that is healthily growing.

Here is a concrete pattern, details changed. A company had a custom order system built, negotiated the build price hard, and set nothing aside for afterward. For the first year almost nothing happened, which confirmed their belief that the thing was finished. Then, over a few months, several bills landed at once: the payment provider changed its integration and broke checkout, a browser update surfaced a layout bug, and the team wanted three new fields the sales process now depended on. Because none of it had been planned, each item was handled as an emergency at premium rates, on whichever developer had a free slot, and the total for that stretch dwarfed what a modest planned retainer would have cost across the same period. Worse, because they did not own the deployment accounts, moving the work to someone cheaper meant untangling access first, which added delay to every fix. When we were brought in, the repair was barely technical. It was to set a sane yearly slice, move ownership of the code and accounts to them, and start itemizing the work so they could finally see that most of their spend was growth they actually wanted, not decay they were helpless against. The budget did not conjure the work into existence; the work had been there the whole time. It made the work calm, planned, and theirs to direct.

Launch is a starting line, not a finish

The healthiest systems we look after are years old and barely resemble their launch versions, because the businesses behind them kept growing and the software kept pace. That is what the yearly slice actually buys: not repairs, but the freedom to say yes quickly when the business changes, at planned prices instead of emergency ones. If you are pricing a build right now, ask every developer what year two costs. And if you already own a system with nothing set aside behind it, tell me what it runs on and when it was last touched, and I will give you a straight read on what its yearly slice should be, or whether it has earned a quiet retirement instead.

FAQ

What does a software maintenance budget cover?

It covers the three kinds of work a live system needs after launch: fixing the occasional genuine bug, keeping the software in step with a changing outside world, and growing it as the business asks it to do more. In a well-built system the fixes are the smallest part; the keeping-up work is unavoidable because payment providers, browsers, and rules all move on their own schedules; and the growth is usually the largest share, because a useful tool keeps being asked to handle new products, roles, and reports. The budget is less a repair fund than a fund for keeping the system worth using.

How much should I budget for software maintenance each year?

The right figure is a small yearly slice of the original build cost, with the exact percentage depending on how central the system is and how quickly your business changes; a tool at the heart of daily operations warrants more than a stable one that rarely moves. The specific number matters less than agreeing it in writing before the build begins, so it becomes a planned line item rather than a surprise. Whoever builds the system should be willing to tell you what year two looks like and what it costs; if they will not, treat that reluctance as a warning.

Why am I being charged for software after it was finished?

Because software that gets used is never truly finished. Some of what you are charged for is keeping the system working as the world around it changes, since payment providers revise their interfaces, browsers and operating systems update, and rules shift, none of it under your control. Most of the rest is growth you asked for: new fields, roles, products, and reports the business needed once it was live. Only a small share is usually genuine bug repair. The invoice feels like a betrayal only because nobody explained up front that a living system carries ongoing costs by design.

Is it better to pay a monthly retainer or buy hours as needed?

It depends on how your change requests arrive. A monthly retainer suits a system that is central to daily operations and generates a steady stream of small requests, because it covers the unavoidable keeping-up work plus a predictable allowance of improvements at a stable price. Prepaid blocks of hours or small fixed-price mini-projects suit a stable system where needs come in occasional bursts, because you draw them down only when something actually surfaces. Whichever you pick, insist on itemized logs so you can see exactly what the money bought.

What happens if I do not budget for maintenance at all?

The work does not go away; it just gets pricier and more disruptive. Skipped keeping-up updates pile up until the catch-up becomes one big risky job instead of a series of small routine ones, and unplanned work lands as an emergency at premium rates while part of your operation is down. There is a quieter cost too: when every change means negotiating from scratch, people stop requesting changes and start routing around the tool with side spreadsheets and manual steps, and the system slowly slides into irrelevance. A modest planned budget heads off both outcomes at once.

When should I stop paying for maintenance and replace the system instead?

When the maintenance money is only buying survival rather than options, speed, and calm. If a tool was always meant to be temporary, give it an end date instead of patching it forever. If it runs entirely on mainstream off-the-shelf software, the vendor already handles most upkeep through your subscription, so do not pay twice. And if a custom system has drifted so far from how you now operate that every change fights its original assumptions, a focused rebuild of the worst piece can cost less than another year of escalating life support. The signal is a maintenance bill that keeps climbing while the system does less and less of what you need.