TL;DR
We calculate total cost of ownership (TCO) by adding build, operate, and maintain costs, plus integration risk and opportunity cost.
We use 3-year NPV for fair comparisons, then focus on the top 2-3 drivers that could change the outcome.
We put numbers on incidents, compliance, migration, and switching costs—because teams often overlook these.
We make decisions using a weighted scorecard and set clear exit or refresh triggers.
Our guardrails include privacy-by-design, accessibility, non-manipulative UX, and data portability.
Key terms (one-line definitions)
TCO: The complete cost to build, run, and maintain a system throughout its entire life.
Build: One-time expenses to create the first working version of a product.
Operate: Ongoing costs to keep the service running and serve customers each day.
Maintain: The work to update, fix, and improve systems over time.
Integration risk: Extra costs and headaches from connecting our system to others.
Opportunity cost: Value we lose by picking one option instead of the next-best one.
Sensitivity analysis: Checking how results change when we tweak key assumptions or budgets.
These terms help us see the full picture when we calculate ROI or think about depreciation.
A step-by-step TCO playbook
1) Set the frame
We start by setting clear boundaries for our TCO analysis.
Use a 3-year horizon as your default.
Set your discount rate based on your company’s finance hurdle rate. Most teams use 8-15% for this.
Pick which KPI this capability should impact. That’s your North Star for the analysis.
2) List the cost drivers
We need to spot every cost that drives TCO.
Direct costs hit engineering, project management, and design.
Implementation costs cover tooling, QA, and team enablement.
Operating costs hit cloud, third-party APIs, monitoring, and support.
Add maintenance like security patches and performance work. Don’t miss compliance costs—audits, data residency, and so on.
Remember integration, incident response, exit costs, and the opportunity cost from delayed projects.
3) Quantify build
Calculate acquisition costs with: Loaded cost per FTE-month × FTE-months.
Example: 3 engineers × 3 months × $20,000 per FTE-month = $180,000 total.
Use loaded rates that include benefits and overhead.
4) Quantify operate
Add infrastructure costs, usage-based vendor fees, and support seat licenses.
Don’t forget on-call stipends and monitoring tools.
Apply a 10-20% buffer for growth or price changes.
Write down your assumptions for later.
5) Quantify maintain
Use this rule of thumb: 10-20% of build costs per year for maintenance and refactoring.
Add predictable upgrades like framework migrations or security updates. Track these as ongoing indirect costs.
6) Put numbers on risk with EV
Calculate incident expected value: Probability of incident × Impact.
Impact = revenue at risk per hour × duration + SLA credits + staff time.
Example: 2 incidents per year × (2 hours × $15,000/hour + $10,000 credits + $3,000 staff) = $64,000 annually.
7) Account for integration and migration
Migration costs = hours × loaded rate + dual-run infrastructure + rollback prep.
Score complexity from 1-5 based on testing and data migration needs.
8) Add opportunity cost (be explicit)
Pick the next most likely project you’ll delay.
Calculate: Value per month × months delayed.
If a feature worth $25,000/month gets delayed 3 months, that’s $75,000 in opportunity cost.
9) Compute 3-year NPV (apples-to-apples)
Use: NPV = C₀ + Σ (Cₜ / (1 + r)ᵗ) where C₀ is Year 0 cost, r is discount rate.
Put purchase price and build costs in Year 0. Spread operating costs over future years.
10) Run sensitivity checks (keep it simple)
Test three variables: usage growth, vendor pricing, and incident rates.
Show base, best, and worst cases. Focus on big swings, not tiny details.
11) Decide, document, and set triggers
Create a TCO scorecard with weighted scores from 1-5.
Set exit triggers, like price increases over 30% or repeated SLA misses.
Write down 5 key assumptions. Schedule reviews every 6-12 months to check your analysis.
Trade-offs that shape TCO
Operating costs change a lot based on deployment choices.
Managed services cut operational headaches but raise unit costs. Self-hosted solutions save at scale but demand more maintenance.
Hidden costs pop up with integration complexity and migration.
Deep integrations feel seamless but make testing and transitions expensive. Multi-region deployments boost performance but add infrastructure overhead.
Resource allocation shapes long-term financial outcomes.
Open source cuts licensing fees but means more internal support. Opportunity costs hit when teams get stuck on maintenance instead of building new stuff.
Worked example (B2B): event ingestion pipeline
We need a streaming pipeline for product analytics.
Two options: buy a managed ETL service or build our own with open-source tools.
Managed ETL costs:
- Year 0: $60k integration
- Years 1-3: $216k/year ($18k monthly usage + $10k incidents)
Build-in-house costs:
- Year 0: $320k development (4 engineers × 4 months × $20k)
- Years 1-3: $230k/year:
- Infrastructure: $96k
- On-call: $30k
- Maintenance: $64k (20% of build)
- Incidents: $40k
The service life analysis looks different for each.
The managed option has predictable costs over three years. Our custom build needs more upfront cash but less ongoing infrastructure spend.
Using a 10% discount rate over three years:
- Buy option: $622k total
- Build option: $892k total
If usage doubles in years 2-3, the managed service jumps to $432k/year, totaling $897k.
Worked example (B2C): push notifications at scale
We need to send 80 million push notifications monthly.
Two options: use a third-party service or build our own gateway.
Third-party costs:
- $0.0005 per notification × 80M = $40,000/month
- Support: $4,000/month
- Setup: $25,000 one-time
- SLA: 99.95% uptime
Own gateway costs:
- Build: $240,000 (3 engineers × 4 months × $20,000)
- Infrastructure: $12,000/month
- SRE: $20,000/year
- Maintenance: $48,000/year
Downtime costs swing a lot:
- Vendor downtime: $8,000/hour × 5 hours = $40,000 yearly, minus $10,000 SLA credits = $30,000 net
- In-house downtime (Year 1): $8,000/hour × 10 hours = $80,000 expected
The third-party option wins for faster time-to-value and lower risk. Re-evaluate if you hit 120M+ notifications monthly or if vendor prices jump over 40%.
Quick calculation: the “TCO sanity triangle”
Try this quick check before deep modeling.
If build cost divided by months of vendor fees to break even is longer than your expected payback window, default to Buy.
If your differentiation score is high (4 out of 5 or better) and run-rate COGS will top in-house run cost by 25%+ for 12+ months, lean toward Build.
If distribution or credibility is the bottleneck, consider Partner even if coordination costs more.
Guardrails & ethics (non-negotiable)
We keep strict standards to protect our customers and business.
Privacy and security come first—data minimization and encryption are table stakes. This builds trust and long-term value.
Our accessibility commitments follow WCAG 2.1 AA. We budget time for testing so everyone can use our product.
Fair design principles keep us honest:
- Transparent pricing
- Reversible consent
- No manipulative UX
We require data portability through open formats and clear APIs.
Vendors must show SOC2 evidence and spell out data residency.
Pitfalls & better alternatives
Counting only build costs leads to budget surprises. We should factor in ongoing operations, maintenance, compliance, and incident costs right from day one.
Treating integration as an afterthought disrupts supply chain management. Honestly, it makes sense to price adapters, migration, dual-run periods, and contract tests up front.
Ignoring opportunity costs hides the true price of our decisions. Let’s actually quantify what we delay and add it as a clear line item.
Using false precision wastes time. It’s usually better to work with ranges and consider best, base, and worst-case scenarios instead.
Denying vendor lock-in can create expensive exits later. Building in abstraction layers, export rights, price caps, and clear exit triggers makes things a lot safer.
Overlooking maintenance causes unexpected downtime costs. Reserving 10-20% of build costs each year for upgrades and security work seems like a smart move.
Mini FAQ
Why three years? One year just hides maintenance and compliance cycles. Three years feels like the sweet spot for balancing realistic planning with accurate forecasting.
What discount rate should we use? Use your company’s finance hurdle rate, which usually falls somewhere between 8-15%. Stick with the same rate for every option you compare.
How do we value opportunity cost? Pick the most likely alternative. Multiply monthly value × months delayed. It really helps to state your assumptions clearly so the analysis doesn’t get skewed.
When should we accept higher TCO? Go for higher costs when they buy us differentiation, resilience, or a compliance posture that our market actually values.
How often do we refresh TCO calculations? Update at renewal time, during major usage shifts, or when specific triggers pop up. Otherwise, refreshing every 6-12 months keeps things current enough.
TCO worksheet (paste into a sheet)
We built this worksheet to help you track real costs across a project’s entire lifecycle.
Copy this table into your own spreadsheet. Fill in the numbers that fit your situation best.
| Category | Assumption | Unit cost | Qty/Frequency | Annual cost | Notes |
|---|---|---|---|---|---|
| Build (staff) | $20,000 | FTE-months | Loaded cost per FTE-month | ||
| Tooling/tests | $ | One-time | |||
| Operate – cloud/COGS | $ | Per month | |||
| Operate – vendors | $ | Per unit | Usage-based | ||
| Support/on-call | $ | Per year | |||
| Maintain – upgrades | $ | Per year | |||
| Maintain – refactors | 20% of build | Per year | Rule of thumb | ||
| Compliance/audits | $ | Per year | |||
| Integration/migration | $ | One-time | Adapters, dual-run | ||
| Incidents (EV) | P×Impact | Per year | e.g., 2×($15k/h×2h+$10k credits+$3k staff) | ||
| Exit/switch | $ | One-time | Data export, parallel run | ||
| Opportunity cost | $ | Per month×months | Next best bet delayed |
This format should capture both the obvious costs and those sneaky hidden ones that teams tend to overlook.
