# What it costs to keep a system running > A system's cost does not end at delivery. What you pay after go-live, and how the design decides that bill before the first line of code is written. - Author: Marlon Trettin - Published: 2026-08-17 · Updated: 2026-08-29 - Language: en - Canonical: https://yowpi.com/en/blog/what-it-costs-to-keep-a-system-running --- Keeping a system running after delivery costs money in four lines: infrastructure, fixes, changes in the operation, and evolution. None of them disappears over time. The exact figure varies; the pattern does not. The more coupled and less documented the system, the larger the annual bill. And that bill is decided in the design, not on the invoice. ## TL;DR - In [McKinsey research with 50 CIOs](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) at financial services and technology companies above USD 1 billion in revenue, 10% to 20% of the technology budget earmarked for new products gets diverted to resolving technical debt. - In the same study, CIOs estimated technical debt at 20% to 40% of the value of their entire technology estate before depreciation, and 60% saw that number rise over three years. - [Flyvbjerg and Budzier's study of 1,471 IT projects](https://arxiv.org/pdf/1304.0265) found an average cost overrun of 27%, with one in six projects overrunning by 200% on average. - Budget the system over three years, not over one delivery. The method is in the section "How to budget three years, not a project". ## Why does the budget stop on delivery day? Because the commercial proposal stops there. You get a scope, a deadline and a price. What happens the month after delivery rarely appears on the same spreadsheet, and the effect is predictable: the company approves the investment with one number and lives with another. The confusion comes from treating software as construction rather than as an asset in operation. Machinery has a maintenance plan. A vehicle has a service schedule. A system, which changes every time the operation changes, gets budgeted as a one-off purchase. The risk of getting that wrong is not theoretical. Bent Flyvbjerg and Alexander Budzier analyzed [1,471 IT projects](https://arxiv.org/pdf/1304.0265) and found an average cost overrun of 27%. The harder number is in the tail: one in six projects overran by 200% on average and ran nearly 70% late. The average misleads; the extreme is what breaks cash flow. ## What do you pay for after go-live? Four lines, and each deserves its own place in the budget. Infrastructure and licenses is the most visible. Servers, database, storage, email and messaging delivery, third-party tools. It grows with usage, which is fair, as long as you know the curve before you scale. Fixes are what nobody schedules and everybody pays for. Production errors, inconsistent data, an integration that stopped because a vendor changed their API. A high volume of fixes in the first months usually signals a rushed delivery, not bad luck. Changes in the operation is the most underestimated line. The company takes on a new type of customer, changes a commission rule, faces a new compliance requirement. The system has to follow. That is not a defect in the software, it is the operation being alive. Evolution is what you want to be paying for. A new report, automating a step that is still manual, a customer portal. If the first three lines consume nearly the whole budget, the fourth never happens. That is exactly where the bill tightens. According to [McKinsey](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity), 10% to 20% of the budget reserved for new products ends up diverted to resolving technical debt. The future's money pays for the past. Those companies operate at a different scale, of course. The mechanism is the same, and in a smaller operation it shows up faster, because the budget is smaller. ## How does the design decide the annual bill? Maintenance cost is born in decisions taken before the first line of code. Three of them weigh more than all the others. The first is coupling. When a business rule is scattered across several points in the code, any change becomes a treasure hunt. A commission-rule change that should take two hours takes two weeks, and testing everything that broke alongside it takes another. The second is data boundaries. A system that never defines the source of truth for each piece of information generates permanent reconciliation. Every month someone compares two lists to work out which one is right, and that someone costs a salary. The third is concentrated knowledge. With no documentation, no code standard and only one person able to touch it, maintenance cost starts to include a risk: one person's calendar. When they leave, you do not lose a developer, you lose the manual. [McKinsey](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) also offers a useful line for deciding when to stop patching. When an area's technical debt passes 50% of the value of the technology asset, the cost and risk of maintaining it start to outweigh the benefit. Gartner, in [How to Prioritize and Sell Technical Debt Remediation](https://www.gartner.com/en/documents/7092135), published on 21 October 2025, recorded that fewer than 20% of application and software engineering leaders consider themselves highly effective at managing technical debt, even though 44% of organizations call it one of their main challenges. Almost everyone knows the bill exists. Few manage it. ## An example with numbers The scenario below is hypothetical, built to illustrate the arithmetic. No real client is described here. A mid-sized distributor commissions an order and commission system for USD 150,000, delivered in five months. In the first year after go-live, the company pays USD 1,200 a month for infrastructure and services, contracts 20 hours a month of fixes and adjustments at USD 150 an hour, and makes two rule changes per half-year at USD 9,000 each. The annual bill comes to USD 14,400 in infrastructure, USD 36,000 in hours and USD 36,000 in changes. Total: USD 86,400, or 58% of the build price, in the first year. Evolution: zero. No budget was left for it, and that is precisely the symptom. Had the company budgeted only the build, year two would have arrived as a surprise. Now change one variable. Suppose the commission rule sits isolated at a single point in the system, with an automated test. The two half-yearly changes drop from USD 9,000 to USD 2,500 each. The annual bill falls to USD 60,400. That USD 26,000 a year did not come from negotiating a cheaper hourly rate. It came from a design decision taken before work started. ## How to budget three years, not a project Start by asking the vendor, while you are still reading the proposal, for an estimate of the four lines across the 24 months following delivery. Anyone who designs systems regularly can answer that. Anyone who stalls on the question is selling construction. Then write into the contract who is responsible for defect fixes and within what timeframe, with a clear warranty window. A fix for a delivery error and a change requested by the company are different things and need different prices. Third, demand the exit. Code in your repository, infrastructure credentials in your name, data exportable in an open format, minimum documentation of architecture and decisions. A system you cannot leave has its maintenance cost set by somebody else. Finally, reserve a fixed, predictable slice of the annual budget for reducing technical debt, proportional to the system's age. [McKinsey](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) recommends the opposite of a big push: continuous payment over time, because a modernization megaproject concentrates execution risk. It is the logic of any preventive maintenance. Two of our projects show both sides of this bill. At [Colo Saúde](/en/cases/colo-saude), the platform arrived already in operation and the work started with the cost of keeping it running, cutting consumption on the no-code platform it ran on by 60%, with the corresponding drop in the monthly plan, before any new feature. At [UniTrust](/en/cases/unitrust), the system was born in no-code in 2022 and, four years later, began migrating to a proprietary architecture, run by the same team. In both, the decision was about what it would cost to operate afterwards, not what it would cost to build. ## Frequently asked questions **Is there a standard annual maintenance percentage of the project value?** Percentages circulate, but none of them survives contact with a concrete case: complexity, number of integrations and the operation's rate of change move the result too much. Estimate the four lines with your vendor, using your system as the basis, and revise every six months. **Does off-the-shelf software solve this problem?** It changes the nature of the bill, not its existence. You trade fixes and evolution for a subscription, customisation, integration and dependence on a product roadmap that is not yours. The question stays the same in both cases: what does it cost to operate this for three years? **My current system is already expensive to change. Is it worth rewriting?** Not always. Before deciding, measure: how long a typical change takes today, how many people can make it, and what share of the budget goes to fixes. If the answer says that maintaining it already consumes more than half of what the asset is worth to the business, the discussion stops being technical and becomes an investment decision. ## The bill is decided in the design Expensive maintenance is rarely a technology problem. It is the monthly price of an architecture decision taken once, before the first line of code. If you are about to approve a new system, or already live with one whose maintenance grows every quarter, half an hour is worth it. Our [Operational Architecture Diagnostic](/en/contact) is a 30-minute session to look at where that bill is being decided in your operation.