The price of software isn't what it costs to build, but what it costs to own it for the years it will be in production. Building it has become cheap; operating, fixing, integrating, and evolving it hasn't. Comparing two proposals based on their delivery budget is like comparing two buildings based on the cost of the concrete.
This distinction has become urgent in the last eighteen months. The cost of producing code has fallen in a real and verifiable way—Stanford HAI documented that the inference cost for a GPT-3.5 equivalent system fell more than 280-fold between November 2022 and October 2024—and with it, the entry price of many development proposals has fallen. What hasn't fallen is the cost of maintaining what is built.
A project budget typically covers analysis, design, development, and implementation. This represents between 30% and 40% of the money the system will consume over its lifetime. The remainder is allocated later, divided into items that are almost never included in the initial proposal.
Departure | What's included | When does it appear? |
Construction | Analysis, design, development, deployment | Months 1-9 |
Infrastructure | Cloud, storage, backups, environments | From day one, forever |
Correction | Defects, regressions, production incidents | From the first week |
Evolution | Business changes, new requirements, new integrations | Continuous |
Security and compliance | Patches, audits, regulatory adaptation | Continuous, with regulatory peaks |
Dependence | Cost of only one supplier knowing how to play it | It appears when you want to change |
The first five items can be estimated. The sixth does not appear in any budget and is the one that costs the most money when it materializes, because it is not paid in euros at the beginning: it is paid in loss of negotiating power.
Technical debt is usually explained as an engineering concept, which is why management committees often ignore it until it's too late. In financial terms, it's simpler: it's the extra cost you pay every time you want to change something, stemming from decisions made to speed things up at the time.
Industry estimates place the burden of maintenance and technology debt at around 401% of an average organization's IT budget. This figure should be treated as an order of magnitude, not an audited data point, because methodologies vary considerably between studies. However, the direction is consistent across all sources: most of an established company's technology spending doesn't fund new capabilities; it funds the maintenance of outdated decisions.
There's an additional piece of information that changes the conversation when you bring it up with a CFO: IBM estimates that cleaning up the technical debt of legacy systems can improve the return on AI initiatives by up to 29%. In other words, technical debt doesn't just cost money in maintenance; it reduces the performance of everything built on top of it.
And the problem is growing, not shrinking. GitClear, based on an analysis of 211 million lines of code, documented that code block duplication skyrocketed starting in 2024 and that refactoring work—the activity that pays off debt—fell from approximately 25.1% of total change in 2021 to less than 10.1% in 2024. It's building faster and cleaning up less.
A formal audit isn't necessary to detect the early symptoms. These are the indicators that appear first:
When three or more of these symptoms appear, adding development capacity doesn't accelerate anything. It only increases the number of people waiting for a design decision to be resolved.
When comparing vendors, these four questions separate someone who sells a single delivery from someone who sells a system. None of them are technical; all are contractual.
Whose code is it? If the answer includes nuances, licenses, or "access to the repository," the answer is no, it's not yours. Ownership of the code, documentation, and intellectual property must be transferred by contract. Without that, any quote is provisional, because the provider has indefinite pricing power over your transaction.
What happens if I want to change providers tomorrow? The helpful answer isn't "you won't." It's: architectural documentation exists, modules expose versioned contracts, there are separate environments, and any competent team can take over within a reasonable timeframe. If that transition requires someone from the original vendor to "explain how it works," the system isn't documented; it's memorized.
Who pays for the defects? A defect in delivered code is not a scope change. It should be fixed at no cost, and that should be in writing. At The Cloud Group, we call it the Rain Guarantee, and it's in the contract: we fix defects in delivered code, for life. It's not generosity, it's consistency: if you claim your engineering is disciplined, you have to accept the cost of it not being so.
What is the estimated operating cost over three years? Any reputable provider can offer you a range of infrastructure, support, and upgrade options. Those who can't either haven't considered it or prefer you don't.
These are exactly the questions we help formulate when we act as an independent party in a process of Supplier selection and RFP writing [internal link], without participating as candidates in the tender we are evaluating.
It's not a coincidence, it's a causal relationship. Decisions that reduce construction costs are almost always the ones that increase maintenance costs.
None of these decisions are visible in a demo. They are all visible on the third-year bill.
The opposite case also exists and is measurable. In legacy system modernization projects—auditing, refactoring, and modernizing instead of rewriting from scratch—we've seen maintenance cost reductions of up to 60%. Not because the new code is magic, but because the cost of maintenance is largely the cost of uncertainty: when the system is understandable and tested, every change ceases to be a gamble.
The technical team's common mistake is requesting a budget "to pay off technical debt." It's a request no committee enthusiastically approves, because it sounds like trying to fix something that was done incorrectly.
The formula that works is different and honest:
The conversation shifts from "the software is poorly made" to "this is the cost difference between the two routes." That second conversation can be won.
A cheap proposal that doesn't include code ownership, documentation, testing, or integration contracts isn't a cheap proposal: it's a loan with an interest rate you'll discover later.
The question to ask yourself when making your next software purchase decision isn't how much it costs to build. It's how much it costs to own, who owns it, and what happens if you want to change your mind.
It is the sum of all the costs associated with a system throughout its lifespan: construction, infrastructure, defect correction, functional evolution, security and compliance, and the cost of relying on a single vendor. The construction budget typically represents only between 301% and 401% of the total.
Industry estimates place it at around 401% of the IT budget, though the figure varies depending on the study methodology. The trend is consistent: in established companies, most technology spending maintains past decisions rather than building new capabilities.
It estimates at least three years of life and includes six items: construction, infrastructure and environments, defect correction, functional evolution, security and regulatory compliance, and exit or supplier switching costs. A reputable supplier can give you a reasoned range for the first five.
Because the decisions that reduce construction costs—skipping the design, not writing tests, not documenting, patching things up—are the same ones that increase the cost of each subsequent change. The savings are concentrated in the first quarter, and the additional costs are spread over the following years.
Four things: ownership of the code, documentation, and intellectual property; versioned and documented integration contracts; free defect correction; and a transition plan that allows another team to take over without relying on the original vendor.
In most cases, yes, provided there is a prior diagnosis. Auditing, refactoring, and modernizing by domain allows for a significant reduction in maintenance costs—up to 60% in projects we have executed—while keeping operations running, something a complete rewrite does not allow.
Do you know how much your software will cost you in three years? Our technical audit provides a written report on the state of your architecture, code, debt, and security, with a fixed price and within 10 business days. It's the most cost-effective way to uncover an expensive problem. Request your audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
