Total cost of ownership over five years: how to estimate
The build price is a third of what software costs over its life. The five lines to estimate, how to weight them, and the comparison that matters.
The short answer
The price on a software proposal is the build, and the build is usually a minority of what the software will cost over five years. Four more lines follow it: running infrastructure every month, maintenance and support to keep it updated and secure, change and development as the business moves, and your own people’s time to test, learn, support and manage it. Comparing options on the build quote alone picks the wrong one with some regularity: the cheaper build with expensive running costs or no maintenance is the dearer option by year three. Estimate all five lines over five years, add the cost of the alternative, and compare the totals.
The five lines
| Line | What it contains | How it behaves over five years |
|---|---|---|
| 1. Build | Discovery, design, development, testing, migration, launch | One-off, front-loaded |
| 2. Running | Hosting, database, storage, third-party services, monitoring | Monthly, growing gently with use |
| 3. Maintenance and support | Updates, security, backups, monitoring response, small fixes | Monthly, steady; lower on a well-built mainstream stack |
| 4. Change and development | New features, integrations, adaptations as the business changes | Lumpy; a change budget plus projects |
| 5. Your people | Testing, training, reviewing, supporting colleagues, managing the supplier | Highest in year one, steady after |
Estimating it
- Build: from a proposal that shows discovery, data work, integration, evaluation and launch, not a single line.
- Running: monthly cost at today’s usage and at the usage you expect in year three, from the providers’ prices, in your own accounts.
- Maintenance and support: the monthly fee with its scope, or the hours if internal, times sixty months.
- Change: a realistic yearly change budget plus one larger project every year or two, because the business will change.
- Your people: hours per month in year one and after, valued at what those hours would otherwise produce.
- The alternative: the current process’s cost, or the product’s five-year fees plus integration and adaptation.
- Compare totals, then weigh fit, control and exit.
What drives the total down
A mainstream, typed, tested stack keeps maintenance and change cheap for years. Managed infrastructure in your own accounts keeps running costs visible and flat. Ownership and documentation keep supplier change possible, which keeps prices honest. A staged build that delivers value early shortens the time before the software pays back. And a scope that says no to features nobody asked for keeps all five lines smaller. Most of the total is decided by how the software is built, not by who charges the least to build it.
What this means for you
Approve software on its five-year total, not its build price: build, running, maintenance and support, change, and your own people’s time, compared with the alternative. Insist that proposals show all five. Prefer builds that make the later lines small: mainstream stack, managed infrastructure, ownership, staged delivery, disciplined scope. The build is one of five rows. The others are hosting and services, maintenance and updates, support, and the changes the business will want; five rows on one page is how you compare two offers that quote different subsets.
Frequently asked questions
How much does maintenance cost relative to the build?
Over five years, the maintenance, support and change lines together commonly exceed the build, because software must be kept updated, secure and adapted to a business that changes. The exact proportion depends on how well it was built and how much the business changes; a well-built system on a mainstream stack keeps the lines lower. Whatever the number, it is not zero and it is not optional.
How do we compare a custom build with licensing a product?
Five-year totals on both: the product's fees at your growth, plus configuration, integration, training and the cost of adapting your process to it; the custom build plus five years of running, maintenance and change. Then the qualitative differences: fit, control, exit. Products often win for standard processes; custom often wins where the process is the business.
What is the biggest error in these estimates?
Forgetting your own people: the hours labelling, testing, reviewing, learning, supporting colleagues and managing the supplier. They are real costs in every option, including doing nothing, and they are the line most estimates omit. Estimate them in hours and value the hours.