Build vs Buy TCO: The Real 3- and 5-Year Cost
Total cost of ownership is the full three- to five-year sum of every cost a path creates, not its sticker price. Build hides its cost in the maintenance tail and opportunity cost; buy hides it in seat growth, integration, and renewal escalation; modernize spends incrementally against a system that keeps running. Cost all three over the same horizon before you choose.
Part 1 laid out the three honest paths for a system that matters: build it new, buy a product, or modernize the one you already run. It ended on the question everyone reaches for first and almost nobody can actually answer — which one is cheaper? You cannot answer it from a sticker price, a vendor quote, or a gut feel about engineering salaries. You answer it with a worksheet, run over the same horizon for all three paths, with every line the decision actually incurs.
This part is that worksheet. It is a mid-funnel article on purpose: no framing, no persuasion, just the cost math — the line items, two fully worked numeric examples, how the answer moves with company size, and a sensitivity check on the assumptions that actually decide it. Copy your own numbers in as you read.
The sticker price is the smallest number
Every path quotes you a headline figure designed to look small. Build quotes the initial engineering effort. Buy quotes the first-year license. Modernize gets quoted as “a big services project.” All three headlines mislead in the same way: they front-load the visible cost and hide the tail.
The tail is where the money is. A bought product’s first-year license is often the lowest it will ever be — seats grow, prices escalate at renewal, and the admin to run the vendor never stops. A built system’s initial engineering is frequently smaller than the maintenance it demands over the following four years. And the run cost you are already paying on the legacy system — the one both build and buy quietly assume you’ll switch off — keeps running until the day you actually cut over, which is later than planned more often than not.
So the rule for the rest of this article: cost the whole horizon, not the purchase. Three years is the minimum honest window; five is where the paths separate for good. Anything shorter flatters whichever option has the lowest upfront number — which is exactly the number you should trust least. And use the same horizon for all three: a five-year build compared against a one-year license is not a comparison, it is a sales tactic.
Costing the build path
Building is the path whose true cost is most consistently underestimated, because the part you can see — writing the first version — is the cheap part. The lines that matter, and how to size each:
- Initial build. Use loaded engineering cost, not base salary: salary plus benefits, payroll taxes, tooling, and overhead — typically 1.3–1.5× base. A four-engineer team for a year is not four salaries; it is four loaded seats plus the management, product, and design around them. Size it by team × months, and be honest that first estimates of “months” run long.
- Ongoing maintenance. The line people leave off entirely, and the one that decides the five-year number. A non-trivial system needs a standing team — bug fixes, dependency and framework upgrades, platform and OS changes, and the new edge cases production surfaces every quarter. Budget it as staff, not a percentage afterthought: one to two engineers, permanently, for as long as the system lives. As a sanity check, annual maintenance commonly runs 15–25% of the original build cost, every year, indefinitely — which means over five years the tail alone can exceed the build.
- Infrastructure and cloud. Compute, storage, data transfer, non-production environments, observability, backups. It scales with usage, so it is larger at year five than year one.
- Security and compliance. Penetration tests, SOC 2 or ISO 27001 upkeep, dependency and vulnerability scanning, and the remediation when something is found. On a bought product this is the vendor’s problem, priced into the license; on a built one it is a recurring line you own forever.
- Hiring and ramp. Easy to forget: recruiting the team, and the months before new engineers are productive on your codebase. Real money, and it recurs with every departure.
- Opportunity cost. The largest and least-tracked line of all — it gets its own section below, because it deserves it.
The shape to remember: the build’s five-year cost is usually dominated by the maintenance tail, not the initial build. If your worksheet shows the opposite, you have under-costed the tail.
Costing the buy path
Buying looks clean because the vendor absorbs the maintenance, the security, and the infrastructure. It is genuinely the cheapest path for commodity capability. But its worksheet has its own tail, and buyers reliably under-model it:
- Subscription and licenses — with growth. Do not cost the first-year price flat. Seats grow as you roll out, list prices rise at renewal (5–15% a year is common once you are locked in), and per-seat AI add-ons quietly lift the effective rate. A modest 15% annual growth roughly doubles the license line by year five. Cost the curve, not the quote.
- Implementation and onboarding. The one-time cost of standing it up — configuration, data migration into the vendor, training, and the professional-services engagement most enterprise products require to go live.
- Integration and customization. Wiring it into your stack and bending it toward how you actually work. The more the product’s defaults diverge from your workflow, the faster this line grows — and a runaway here is the classic sign you bought the wrong thing (Part 4’s territory). Every customization is also a future upgrade tax.
- Admin and vendor management. Someone owns the relationship, the renewals, the seat hygiene, the SSO and access reviews, the escalations. Budget it as a fractional FTE; it is real and recurring.
- Exit cost, held in reserve. Not in the run-rate, but real: the price of getting your data out and off the platform if you leave. Part 4 prices reversibility in full; for now, just know the buy path’s cheapest-looking years can carry the most expensive exit.
The shape to remember: buy’s cost compounds through the renewal, not the purchase. The number that decides the five-year total is the growth rate on the license line — the one the sales quote is least eager to show you.
Costing the modernize path
Modernize costs differently from the other two, and the difference is the whole point of the option. You are not funding a system from zero and you are not renting one from a vendor. You are spending incrementally against a system that keeps running and keeps earning while you transform it. That changes the worksheet in four ways:
- Discovery and parity baseline. A one-time cost up front: recover what the system actually does today, and establish a way to prove each change behaves identically to the original. This is the work that lets modernization be safe rather than a disguised rewrite — and it is why the modernize path can promise something build and buy cannot: no behavior lost in translation.
- Incremental transformation. The core spend — transforming the system a slice at a time. It is front-loaded but bounded, and critically it is stoppable: because each slice ships proven and standalone, you can pause with value already banked rather than a half-finished cutover. That optionality has real cash value that never shows up as a line.
- Transition overlap. For a while the old and new run side by side. That overlap is a genuine cost — but it is bounded and declining, and it is what buys you the ability to roll a wrong step back to a known-good state instead of a failed launch.
- Run cost of the modernized system. Infrastructure and light maintenance on what you have transformed — which replaces, rather than adds to, the legacy run cost you were already paying.
The line modernize doesn’t carry is the expensive one build and buy both hide: rediscovering the business logic. A new build has to re-derive every rule the old system absorbed over the years; a bought product has to be customized until it can reproduce them. Modernize carries that logic forward intact, which is why — for a differentiated system — it often lands cheapest despite looking like “the big project.” One caveat that decides whether this path is even on the table: modernize only exists when there is a system worth carrying forward. For a greenfield capability with no incumbent, or a commodity function whose logic is worth nothing, it is a straight build-versus-buy and modernize drops out. The next two examples show both cases.
Worked example A: a differentiated, business-critical system
Here is one scenario costed all the way through. A mid-size company weighing a business-critical capability that already runs the business and encodes rules it competes on — the case where all three paths are live. Loaded engineering cost is taken at $190k per seat per year.
Every figure below is illustrative — a plausible composite, not a benchmark. The point is the shape, and to give you a template. Put your own numbers in the legacy cost calculator.
Build
| Line item | 3-year | 5-year |
|---|---|---|
| Initial build (4 eng × 12 mo, loaded) | $760k | $760k |
| Ongoing maintenance (~2 eng/yr) | $760k | $1.52M |
| Infrastructure & cloud (~$60k/yr) | $180k | $300k |
| Security, compliance & audits (~$40k/yr) | $120k | $200k |
| Subtotal (excl. opportunity cost) | ~$1.82M | ~$2.78M |
Buy
| Line item | 3-year | 5-year |
|---|---|---|
| Subscription / licenses (start ~$120k/yr, +15%/yr) | $417k | $810k |
| Implementation & onboarding (one-time) | $150k | $150k |
| Integration & customization | $130k | $180k |
| Admin / vendor management (~0.25 FTE) | $150k | $250k |
| Subtotal | ~$847k | ~$1.39M |
Modernize (incremental, against the running system)
| Line item | 3-year | 5-year |
|---|---|---|
| Discovery & parity baseline (one-time) | $80k | $80k |
| Incremental transformation (slices, front-loaded) | $480k | $640k |
| Transition overlap (old + new running) | $90k | $120k |
| Run cost of the modernized system | $70k | $180k |
| Subtotal | ~$720k | ~$1.02M |
Side by side
| Path | 3-year | 5-year | What the number buys |
|---|---|---|---|
| Build | ~$1.8M | ~$2.8M | A new system — and you re-derive every rule the old one knew |
| Buy | ~$850k | ~$1.4M | A maintained product — with heavy customization if the fit is poor |
| Modernize | ~$720k | ~$1.0M | The same logic, modernized — the asset carried forward |
Read the shape. For a differentiated, running system, modernize lands lowest and build lands highest, and the gap widens at year five as build’s maintenance tail compounds. Buy sits in the middle on this worksheet — but the buy number here is optimistic, because it assumes the product can reproduce your differentiating rules with only $130–180k of customization. When it can’t (the usual outcome for a system you compete on), that line balloons and the buy column climbs toward build. Which brings us to the case that inverts everything.
Worked example B: a commodity capability
Same mid-size company, same loaded cost — but now the capability is a commodity: an internal tool a mature product already does well, encoding no logic you compete on (think generic expense handling, an internal CRM, a document-workflow app). Watch the tables invert.
Build (a “good enough” internal tool)
| Line item | 3-year | 5-year |
|---|---|---|
| Initial build (3 eng × 9 mo, loaded) | $430k | $430k |
| Ongoing maintenance (~1 eng/yr) | $380k | $760k |
| Infrastructure & cloud (~$30k/yr) | $90k | $150k |
| Security & compliance (~$30k/yr) | $90k | $150k |
| Subtotal (excl. opportunity cost) | ~$990k | ~$1.49M |
Buy (clean fit, minimal customization)
| Line item | 3-year | 5-year |
|---|---|---|
| Subscription / licenses (start ~$60k/yr, +12%/yr) | $203k | $381k |
| Implementation & onboarding (one-time) | $30k | $30k |
| Integration & customization (light) | $25k | $40k |
| Admin (~0.1 FTE) | $57k | $95k |
| Subtotal | ~$315k | ~$546k |
Side by side
| Path | 3-year | 5-year | What the number buys |
|---|---|---|---|
| Build | ~$990k | ~$1.5M | Undifferentiated software you now maintain forever |
| Buy | ~$315k | ~$546k | A maintained product — the obvious answer |
| Modernize | — | — | Nothing to carry forward; not on the table |
Buy wins roughly three-to-one, and it should. There is no modernize column because there is no embedded value to preserve — this is exactly the “acquire a fresh legacy system in three years” waste Part 1 warned against. Same company, same salaries, opposite answer. Nothing changed but which capability you were costing — which is why any TCO comparison that doesn’t first pin down whether the function is commodity or competitive is measuring the wrong thing.
How the answer moves with scale
Company size bends every line, and it does not bend them the same direction. The differentiated scenario above assumed a mid-size org; here is how the decisive line shifts as you move toward the extremes.
| As the organization gets larger… | Build | Buy | Modernize |
|---|---|---|---|
| Usage / seat growth | Infra and maintenance rise modestly | License line climbs steeply (per-seat × headcount) | Run cost rises modestly |
| Talent to staff it | Harder — a bigger standing team to hire and hold | Easier — the vendor is the team | A partner absorbs the transformation spike |
| The line that decides | The maintenance tail | Seat growth at renewal | Transformation scope |
The reversal worth knowing: at very large seat counts, buy’s per-seat model can cross above build. A product that is obviously cheaper at 50 seats can be the expensive option at 5,000, which is why large enterprises sometimes build or self-host capabilities a smaller company would rightly rent. It runs the other way too — a small company that could never staff a standing maintenance team should discount its own build estimate as optimistic, because the tail it is signing up for is the part it is least able to sustain. Cost the path at your scale, and re-cost it at the scale you expect in five years, because the answer can flip in between.
Sensitivity: which assumptions actually decide it
You will not know most of these numbers precisely, and you do not need to. What you need is to know which assumptions move the answer so you can pressure-test those and stop agonizing over the rest. Five inputs do almost all the work:
| Assumption | If it’s higher than you guessed… | Tilts toward |
|---|---|---|
| Loaded engineering salary | Build and modernize both cost more | Buy |
| License seat-growth / renewal escalation | Buy’s five-year total balloons | Build / Modernize |
| Customization needed to make “buy” fit | Buy’s integration line runs away toward build | Build / Modernize |
| Maintenance staffing the build truly needs | Build’s tail dominates the horizon | Buy / Modernize |
| Value of the system’s embedded logic | Rediscovery cost on build and buy rises | Modernize |
Two of these are where estimates go wrong most often. Customization-to-fit is the assumption buyers flatter — the demo fits, so the worksheet assumes a light integration line, and then reality delivers a runaway. Maintenance staffing is the assumption builders flatter — the launch team is real and the standing team is a hope, so the tail gets under-costed. If you stress-test only two lines, stress-test those two. A useful discipline: run each path’s worksheet twice, once at your base case and once with these two lines at 1.5×, and see whether the ranking changes. If the ranking holds under stress, you have your answer. If it flips, you have found the real decision — and it is a fit question, not a cost one.
The line every worksheet leaves blank: opportunity cost
Every table above excludes the biggest number, because it is the hardest to pin and the easiest to ignore: opportunity cost. Every quarter your best engineers spend building or babysitting commodity software is a quarter they did not spend on what customers actually pay you for. It never appears on an invoice, so it never appears in the comparison — and it is frequently larger than any line that does.
Opportunity cost cuts differently per path. Build carries the most — your scarcest people, tied up the longest, on work that may not differentiate you. Buy carries the least on delivery but reintroduces it through integration drag and ongoing admin. Modernize sits in between, and can be steered: because the work is sliceable, you can point in-house effort at the differentiating parts of the system and hand the commodity edges to a partner or a product. Add opportunity cost back in and the picture sharpens in a predictable direction — build’s disadvantage on a commodity capability gets worse, and modernize’s advantage on a differentiated one gets larger. You will not get a precise figure. You do not need one; you need the direction, and the direction is consistent.
Read the shape, not the dollars
Do not fixate on the exact figures — yours will differ, and they should. Read the shape the worksheet reveals:
- Build’s cost lives in the tail. Maintenance, security, and opportunity outweigh the initial build over five years. If yours don’t, you’ve under-costed the tail.
- Buy’s cost lives in the renewal. Seat growth and price escalation, not the first-year license, decide the five-year number — and they decide it upward.
- Modernize’s cost is incremental and stoppable — and it skips the rediscovery bill that build and buy both hide when the system encodes logic you compete on.
- The scenario decides everything. Commodity inverts differentiated; large scale inverts small. Pin down which capability at what scale before you trust any total.
Whichever path’s headline looks cheapest is the one whose worksheet you should scrutinize hardest, because the headline is engineered to hide the tail.
Put your own numbers in
The composites above are templates, not answers. The variables that move them most — loaded salary, seat count and growth, how much customization a bought product would actually need, and the run cost you are already paying on the legacy system today — are specific to you. The legacy cost calculator models the status-quo and modernization sides over one, three, and five years from your own inputs, so you can anchor the modernize column in real figures before you weigh it against build and buy. Build the build and buy columns alongside it using the line items above, on the same horizon, and you will have a worksheet you can actually defend to finance.
Where this leads
Cost tells you what each path takes — it does not tell you which one fits. A path you can afford but will outgrow is no bargain, and the cheapest column on the worksheet is not automatically the right one; the sensitivity check above already showed that the moment a ranking flips under stress, the real decision was never about the money. Fit is a separate question with its own inputs, and it is the one that decides the outcome once the numbers are on the table. Part 3, The Build vs Buy Decision Framework, scores fit against the cost you just built — a copyable weighted matrix that stops the numbers from deciding on their own.
Frequently asked questions
- What is the total cost of ownership (TCO) of software?
- TCO is the full cost of a system across its useful life, not just the price to acquire it. For build that means the initial engineering plus years of maintenance, infrastructure, and security. For buy it means licenses plus implementation, integration, admin, and every renewal increase. For modernize it means the incremental spend to transform a system that keeps running the business while you do it. Sticker price is usually the smallest line in the worksheet.
- Is it cheaper to build or buy software?
- For a commodity capability, buy is almost always cheaper because the vendor spreads development across every customer and you skip the maintenance tail entirely. For a capability that already runs your business and encodes rules you compete on, buy often costs more than it looks once you add heavy customization, integration, and the work of rediscovering behavior the old system already got right — and modernizing what you have can beat both. The honest answer depends on which capability you are costing.
- How do you calculate the 5-year cost of building vs buying?
- Build a line-by-line worksheet for each path over the same horizon. For build: initial engineering (loaded salaries, not base), ongoing maintenance staff, infrastructure, and security and compliance. For buy: licenses with annual seat and price growth, one-time implementation, integration and customization, and admin or vendor management. Total each path at year three and year five, then add opportunity cost — the revenue work your team did not do because it was building or babysitting the tool.
- What costs do people forget when comparing build vs buy?
- On the build side: the maintenance tail (often larger than the initial build over five years), security and compliance upkeep, and opportunity cost. On the buy side: seat growth, annual price escalation at renewal, per-seat AI add-ons, integration drift, and the admin time to manage the vendor. On both sides: the cost of rediscovering the business logic the old system already encodes, which only modernizing avoids.
- Why is modernizing sometimes cheaper than building or buying?
- Because it spends against an asset that keeps running instead of funding a replacement from zero, and because it carries the system's existing business logic forward instead of paying to rediscover and re-implement it. Build has to re-derive every rule the old system absorbed over years; buy has to be customized until it can reproduce them. For a system whose embedded logic is the value, that rediscovery is the largest hidden cost — and modernizing is the only path that skips it.