Business6 minute read
On the most-cited statistic, the build accounts for about 40% of what a custom-built-system costs over its life. The owner spends the other 60% after launch, and that money turning into advantage or into drag depends on who looks after the system.
On the most-cited statistic, the build accounts for about 40% of what a custom-built-system costs over its life. The owner spends the other 60% after launch, and that money turning into advantage or into drag depends on who looks after the system.
In July, Gartner raised its forecast for worldwide IT spending in 2026 to $6.37 trillion, up 14.2% from 2025. The growth is uneven. Gartner expects spending on data center systems to rise 62.5% this year, while services, the work that covers implementing and managing technology, grows 5.3%. John-David Lovelock, vice president analyst at Gartner, warned that inflation and the rush to fund AI projects are straining technology budgets.
For the CEO, CTO, owner and operator of a business, that strain lands on a cost few boards discuss: looking after the system after it has been deployed. The money for new AI projects has to come from somewhere, and a CFO hunting for it will find the maintenance budget the easiest line to trim.
Owning a system commits a business to years of operational work, and an owner who treats the build as the whole purchase has budgeted only for a fraction of the bill. Between 40% and 80% of a system's lifetime cost falls after launch. How the owner manages that spending determines whether ownership compounds into an advantage a competitor cannot rent off-the-shelf or turns into the most expensive way to run the company.
At thinkbridge, we call the discipline “managed care” for software: the maintenance and improvement a system receives after launch, from people accountable for the outcomes. We define this as managed care and not support because we understand the importance of combining technical continuity with empathetic, outcome-driven ownership. And we want business leaders and owners to understand why the perspective of seeing support as care is important to realise outcomes with the software built.
The best-known estimate comes from Robert Glass, who synthesized the research literature for IEEE Software, as early as 2001, and put maintenance at 40% to 80% of a system's total cost, with 60% as the average. The same synthesis contains a less quoted finding that matters more to a business owner and leader: enhancement accounts for about 60% of maintenance spending, and error correction for about 17%. Most of what a business spends on a system after launch pays for the system to do new things.
The figures are a quarter-century old, and the surrounding range is wide. The common rule of thumb quotes 15% to 20% of the original build cost to 90% of a project's budget, often with thin sourcing. Take a system that costs 17.5% of its build price to maintain each year, and stays in service for eight years. It accumulates post-launch costs of 140% of the build, or about 58% of its lifetime cost.
The more useful number for an owner is the 60% that goes to enhancement. Businesses that rent generic software sends that money to the vendor's roadmap, and waits for features the vendor chooses to build. Business that own their software spends it on changes specific to how the company operates, which widens the distance between its system and anything a competitor can buy. The practical step follows: budget ownership as a standing operating line, with a named allowance for new capability alongside the allowance for upkeep. A post-launch budget that covers patches and nothing else pays to keep the system as it was on launch day, while the business it serves moves on.
Vibe coding sharpens the point. The idea has reached corporate budgets: McKinsey's State of AI survey, published in August 2026, found that 32% of organizations had decided against buying at least one software product or feature because they could build it in-house with agentic coding tools. Cheaper code shrinks the build side of the ledger and leaves the post-launch side where it was. Yes, build costs fall by half, but maintenance stays the same, where post launch costs rise from 60% to 75%. Vibe coding describes the builder's experience. Owned software still needs someone who understands the code and keeps changing it as the business moves, and managed care is the arrangement that names that someone.
Conventional software ages at a manageable pace: a dependency falls behind or a certificate expires. AI-native systems decline faster, because their usefulness depends on context that goes stale. MIT's Project NANDA, in its 2025 study of enterprise generative AI, found that about 95% of pilots produced no measurable impact on profit and loss. It identified the core barrier as a learning gap: tools that do not retain context or improve over time. If no one feeds a model-backed workflow new context or re-evaluates it, the workflow falls further behind the business each month. Model providers also retire versions on their own schedules, which forces changes on systems whose owners had no plans to touch them.
Gartner expects organizations to cancel more than 40% of agentic AI projects by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Each of those problems surfaces after launch, when a system meets real transaction volumes and real auditors.
Regulation adds a second kind of upkeep. In April, MIT's AI Risk Initiative found in April that close to 80% of ~ 1,000 AI governance documents, most of them American, address the deploy and operate stages. So the obligations land after launch on the business running the system. And they also churn: of the binding laws in the dataset, legislators had enacted 44%, while 43% had become defunct and 12% remained proposals.
This conundrum is well demonstrated in APAC region. They face 2 issues: a rulebook the region is writing country by country and care that businesses have already deferred. In an IDC survey of 1,400 organizations across eight Asia-Pacific markets, sponsored by MongoDB and published in April 2026, 89% named technical debt as a major obstacle to modernization. Businesses that sells across the region can meet both problems at once: several rulebooks, each changing on its own calendar, and a backlog of debt that makes each change slower.
Managed care for an AI-native business system therefore needs two standing duties that a conventional maintenance contract, written around patches and bug fixes, does not cover: scheduled evaluation of whether the system still delivers the business outcome it was built for, and a watch on the obligations that apply to it. Both need a named owner.
Glass identified the dominant task in maintenance as understanding the existing product, at about 30% of maintenance time. That figure describes a tax a business pays each time the people who built a system walk away from it. The businesses team has to reconstruct why the code works the way it does before it can change anything without breaking it. The owner pays for that phase, and for the mistakes a team makes while it is still learning.
The opposite failure is harder to see. A builder that stays on but keeps the system on its own proprietary platform, or keeps the knowledge in its engineers' heads, turns ownership into a lease the owner cannot exit.
The arrangement that works, combines continuity with the freedom to leave. At thinkbridge, managed care is a part of every thinkOne build. The engineers who built the system stay accountable for it after launch: tightly-knit, curated teams paired with AI agents that monitor production and draft fixes, while the engineers decide what to change and why. This creates a continuous improvement loop: understand the client, observe how the system performs, identify opportunities, implement and validate changes, and measure the resulting impact. An owner who can take the whole system to another team at any point gets better care from the current one removing the comprehension tax.
The argument has limits. For a small internal tool with a handful of users, it doesn’t need a standing team, and a function that gives a business no edge belongs on rented software, where the vendor carries the upkeep. A simple test sorts the cases. If learning that a direct competitor runs the identical system would not bother you, rent it. If it would, you are paying for an advantage, and an advantage requires care. Continuity with one builder also concentrates risk, and the documentation and the right to leave exist to offset it.
The larger share of ownership begins at launch. Most of a system's lifetime cost arrives after go-live, and most of that money buys new capability. AI-native business systems require more of that care than the software that came before them. The decision about who provides that care, and on what terms, matters as much as the decision to build. Business owners should choose a partner that helps the system remain reliable, relevant, and increasingly valuable; while retaining ownership of the code, specifications, documentation, and the freedom to change providers. Settle it before signing the build contract, by naming the team that will change the system in year three and keeping the code and documentation in your own hands. Otherwise, by the third or fourth budget cycle, you will own an expensive system built for the company you used to be.
Tell us what is holding your operations together. thinkbridge will show you what it looks like built right.