Custom software TCO: model 3‑year costs, switching risk, and hidden line-items

Custom software TCO must be the first question you answer before greenlighting a multi-quarter engineering program. The decision isn't academic: a 5-engineer team in the U.S. runs roughly $1.0M–$1.3M per year fully loaded; a $200k–$400k/year SaaS that solves the same surface problem changes the math materially.

Three concrete numbers anchor every model: loaded engineer cost, recurring SaaS spend, and switching cost. Use $180k–$220k/year per senior engineer, $50k–$300k/year for commercial SaaS lines, and 20–40% of one-year spend as a conservative switching-cost estimate for integrations, data migration, and business-process rewrites.

Direct answer: You should build custom software when the 3-year TCO of an in-house team plus operations is lower than vendor cost plus a realistic switching multiplier, and the custom capability drives at least one of: >20% margin uplift, an IP asset you can monetize, or strategic lock-in that reduces churn by ≥5 points. Example: five engineers at $200k/yr = $3.0M over three years versus a SaaS at $300k/yr + $150k migration = $1.05M — buy unless your custom work nets >$2.0M in NPV or reduces churn by material amounts.

Custom software TCO model

A defensible 3-year TCO model separates line-items into build, run, and optional debt servicing. Build: salaries, onboarding, initial integrations, and one-time licensing (example: $300k integration contractor). Run: cloud costs, observability, third-party APIs, and SaaS for support (example: $60k–$250k/yr). Debt servicing: bug-fix backlog, refactors, and performance tuning budgeted as 10–25% of yearly dev effort.

Every dollar in your model must map to an owner and a cadence. Example single-sentence line-items: 'A senior backend engineer costs $200,000/year fully loaded.' 'A production Postgres instance on Amazon RDS for a B2B product with 100k monthly active users will run $3,500–$10,000/month depending on replica strategy.' 'Third-party search (Algolia) starts at $1,000/month and climbs to $10,000+/month once you index heavy traffic.'

Treat switching cost as a first-class output, not a soft paragraph. For integrations with customer data, count: data export tooling ($60k–$150k), re-onboarding/training ($40k–$100k), temporary dual-write windows (infrastructure + support, $20k–$80k), and opportunity cost from delayed roadmap work (your engineer-rate × weeks of delay). Sum these, then apply a 10–20% risk premium for unknowns.

Model switching cost as a line-item and the build vs buy question stops being opinion and becomes arithmetic.

Where the hidden costs hide (and how to surface them)

Hidden costs cluster into three buckets: operational load, incremental SaaS creep, and technical debt servicing. Operational load is observability, runbooks, SRE time, and incident carry; expect an SRE/ops overhead of 10–30% of engineering headcount costs, i.e., $20k–$60k per engineer annually in a mid-stage org.

SaaS creep is the slow growth of subscriptions as you productize. A feature that starts with a $5k/month API often requires logging, alerting, and enterprise support that adds $2k–$8k/month within 18 months. Put a 20% annual growth rate on third-party vendor spend in your TCO by default.

Technical debt servicing is the habitual underbudget. If your roadmap is 20% new features, reserve another 10–25% of engineering capacity purely for debt and platform improvements; otherwise plan for a one-time 'debt holiday' rewrite that will cost 0.5–1.0x a year's base engineering budget.

What this means for a CTO or technical founder

You must make three commitments before you build: commit to a measurable business outcome that justifies the incremental spend; commit to a 3-year budget with named owners for each line-item; and commit to a migration plan that contains switching cost estimates. Without those, the default decision should be to buy.

If you decide to build, start with a 12–18 month roadmap that intentionally buys time: ship a thin, testable integration with a vendor (e.g., Stripe Billing or Auth0) and replace it only after you have 12 months of usage data. This approach converts speculative engineering into a buy-or-build decision with real metrics like MAU, average invoice size, or auth requests/day.

If you decide to buy, negotiate vendor SLAs that align with your TCO model: include data portability clauses, export tooling paid upfront (so you don't amortize migration into perpetual vendor lock), and staging environments at no extra cost. Vendors like Stripe, Twilio, and Algolia publish clear volume breakpoints — use them to model future price steps in year 2 and year 3.

3 action items CTOs should execute this quarter

1. Build a 3-year TCO spreadsheet with columns for Build, Run, Debt, and Switching Cost; populate with committed quotes for cloud and vendor spend, and use $200k/year per senior engineer as your default salary line.

2. Run a one-week audit of vendor exportability: ask your top 5 vendors for data-export SLAs and costed migration plans; if any vendor refuses practical export, mark its switching cost at least 30% higher.

3. Require a measurable counterfactual: every internal build must state the NPV uplift or churn reduction it aims to achieve, with a three-point estimate (best/likely/worst) and a rolling 6-month checkpoint to reassess.

Key takeaways: model everything you can name, add conservative growth assumptions for SaaS creep, and treat switching cost as a primary output of any buy decision.

Restating the thesis: custom software TCO is arithmetic, not faith — when you treat switching cost, operations, and debt servicing as explicit, named line-items, the right decision becomes visible. The new twist is this: once you have a defensible TCO model, you can instrument it to become an ongoing governance tool — tie monthly spend and feature impact to the model and convert opinion into predictable capital allocation.