Total cost of ownership is a structure, not a number
In short
Total cost of ownership for custom software is a checklist of line items across four phases — build, run, change and exit — filled in to the same depth for every option under consideration. Four items are missing from almost every first budget: inference and retrieval run cost, monitoring and on-call time, dependency and platform upgrades, and the internal hours of the people who own the thing.
Key takeaways
- TCO is a structure applied identically to every option, not a figure attached to one of them.
- 4 phases carry line items: build, run, change and exit. Most budgets stop after the first.
- The 4 usual omissions are inference and retrieval run cost, monitoring and on-call, dependency upgrades, and internal owner time.
- Run cost for an AI feature has to be modelled per unit of work, because it scales with usage rather than with headcount.
- A TCO number quoted without its structure is unfalsifiable, which is why comparisons beat totals.
Total cost of ownership is not a figure you calculate once. It is a fixed list of line items, filled in to the same depth for every option, so that 2 options are compared on something other than which had the more thorough spreadsheet. Get the structure right and the arithmetic is easy. Get it wrong and the arithmetic is decoration.
4 phases, with a specific set of items under each. Most first budgets contain phase 1 and about a third of phase 2.
The four phases and what sits under them
| Phase | Line items | Usually missing |
|---|---|---|
| Build | Discovery, design, engineering, testing, data migration and backfill, integration work, security review, launch support | Migration, and the second and third environments |
| Run | Hosting, storage, third-party licences, model inference and retrieval, observability tooling, on-call rota, support handling, incident time | Inference and retrieval, and the human side of on-call |
| Change | Dependency and platform upgrades, model or provider changes, regression evaluation, regulatory changes, ongoing feature work | Upgrades that produce no visible feature |
| Exit | Data export, integration rework, retraining, parallel running, contractual notice period | Effectively all of it |
The exit row is the one people file under risk rather than cost. It belongs in the comparison: the option cheapest to run is often the most expensive to leave, and that only shows when both sit on the same page.
The four that go missing
- Inference and retrieval run cost. Unlike a licence, this scales with usage, so it has to be modelled per unit of work — per answer, per document processed, per conversation — and multiplied by realistic volume. Decide the ceiling before the feature is designed, because retrofitting it means changing the architecture: setting a cost ceiling for an AI feature up front.
- Monitoring and on-call. The tooling line is small and the human line is not. Somebody answers the alert at 02:00, and if the answer is "whoever built it", you have a staffing cost disguised as a rota. The failure modes that generate those alerts are catalogued in what actually breaks with AI agents in production.
- Dependency and platform upgrades. A Node.js or Python release drops out of maintenance, Postgres reaches end of life, a framework ships a major version, a provider deprecates an endpoint on its schedule rather than yours. None of it is visible to a user, which is why it gets deferred until it is urgent.
- The internal time of the people who own it. The product owner who answers questions, the administrator who maintains the configuration, the analyst who cleans the data it depends on, the trainer who onboards new staff. This is real capacity and it is invisible in every budget that counts only external spend.
Why it only works comparatively
A total cost figure quoted on its own is unfalsifiable. It depends on your volume, your existing stack, whether you already run an on-call rota, how clean your data is, and how many integrations you have. Two organisations describing the same requirement can land 10x apart on identical scope, and neither is wrong.
That is why we publish no figures for this work, and why you should be sceptical of anyone who does. A benchmark number invites you to skip the structure, and the structure is what changes the decision.
The cheapest option to build and the cheapest option to own are different options often enough that a build-only budget is not a budget, it is a deposit.
Filling it in without inventing numbers
- Model run cost bottom-up, from a unit. 1 measured transaction times projected volume beats a monthly estimate somebody felt was about right.
- Use ranges, and state the assumption beside each. A range with a named assumption survives review; a single confident figure invites the reviewer to test it, and it usually fails.
- Separate one-off from recurring in every row. Finance reads those differently and returns the case if they are blended — a cause behind a business case that finance rejected twice.
- Name an owner per line item. An unowned cost is an unmanaged cost, and the exercise doubles as an allocation of responsibility.
- With 2 candidate builds, fix the decision gate before filling anything in — setting the gate between two candidate builds stops the model being tuned toward the preferred answer.
For AI systems the structure holds but the weight shifts: run and change are larger relative to build, because the model layer moves underneath you and evaluation is a permanent line rather than a launch task. That is a conversation we have at the start of an AI agents and automation engagement, not the end. The decisions this structure feeds sit in deciding what to build and who builds it, inside the library.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What should a total cost of ownership model include for custom software?
Four phases: build, run, change and exit. Build covers discovery through launch including migration and environments; run covers hosting, licences, inference, observability and the human cost of support and on-call; change covers upgrades, model or provider changes and regression testing; exit covers export, rework, retraining and notice periods. Fill in every phase for every option, even where a phase looks small — that is where the surprises are.
How far out should a TCO model run?
Long enough to include at least one major upgrade cycle, which in practice means 3 years for most systems. A 1-year horizon systematically flatters a build, because the first year is when run costs are lowest, no dependency has reached end of life, and nobody has left the team yet. If the decision horizon is genuinely shorter than that, say so explicitly rather than modelling to it silently.
Does TCO apply to buying a product as well as building one?
Yes, and applying it symmetrically is the whole point. A purchased product still carries integration work, configuration ownership, internal administration, version upgrades you do not control, and an exit cost that is frequently higher than a build's because the data model is somebody else's. Running the identical structure across build, buy and assemble is what makes the three genuinely comparable.
- budgeting
- business case
- procurement
- cost modelling
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Finance sent it back again and did not say whyA second rejection with no stated reason is not obstruction. Ask which number would have to change for approval, and the reply identifies which of four defects you have.diagnostic
- "Dedicated team" defined by what it does not promiseThe phrase commits a supplier to almost nothing on its own. What it usually means in practice, and the three artefacts that turn it into something you can verify.definition
- Everything is now a change requestArguing about whether a change request is fair goes nowhere. Sorting the last 10 into 3 buckets says whether the bid was underscoped, the scope grew, or nobody decided.diagnostic
- The engineers who pitched are not the engineers writing the codeAn impression that the team changed is unarguable and useless. Commit authorship against the names in the proposal is measurable, and it separates a legitimate rotation from a silent downgrade.diagnostic
- The supplier you want cannot pass a policy written for someone elseProcurement policies rarely require a certificate universally. They require one when a condition is met, and four of those conditions can be changed by how the engagement is designed.diagnostic
- It worked on five hundred documents and broke at fifty thousandNothing regressed when the corpus grew. A candidate budget that comfortably held the answer at 500 documents now competes against a hundred times as many near-neighbours, and k never moved.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation