Build vs. buy

The real cost of building software in-house

By Assaf Schwartz · 31 August 2026 · 6 min read

Build-versus-buy arguments are usually conducted over the build estimate, and the build estimate is rarely what makes the decision wrong. The cost that decides it is the one nobody puts in the business case: the engineers the system consumes every year after it ships, for as long as it exists.

The sticker price is the small number

A vendor quote is legible. It arrives as a number per seat per month, it appears on a renewal date, and someone in finance owns it. That legibility is exactly why it attracts scrutiny — and why the alternative, whose costs are distributed across a payroll line that already exists, escapes it.

The full cost of an internal system has four parts, and most business cases contain only the first:

• Build cost. Engineering time to first production release. This is the number that gets estimated, argued about, and then exceeded.
• Maintenance. The permanent fraction of an engineering team required to keep it running: dependency upgrades, security patches, incidents, the migration when the underlying platform changes.
• Feature parity drift. The vendor ships continuously. Your internal system does not, unless you fund it to — and the gap compounds annually.
• Opportunity cost. The product work those engineers were not doing. This is usually the largest number and never appears in any spreadsheet.

The maintenance tail

Maintenance is the line that decides these arguments, and it is almost always modelled as zero. A useful rule of thumb from the industry: an internal system in steady state consumes 15–25% of the effort it took to build, every year, indefinitely.

Concretely: a system that took four engineers nine months to build — three engineer-years — will consume roughly 0.5 to 0.75 of an engineer permanently. At a $145,000 fully-loaded salary that is $72,500 – $108,750 per year, forever, before anyone adds a feature.

The crossover formula

Strip away the narrative and the run-rate comparison is one line. Buying costs you seats × price. Building costs you maintenance headcount × salary. Setting them equal gives the seat count above which building is cheaper to run:

crossover seats = (maintenance FTE × loaded salary) ÷ (12 × price per seat)

With 2.5 maintenance FTE at $160,000 and a platform at $180 per seat per month, the crossover is 185 seats. Below that, the vendor is cheaper on run-rate alone — before you have paid a penny of build cost. Above it, every additional seat favours the internal system.

Read this table before the build estimate, not after. If your seat count is an order of magnitude below the crossover, the build cost is irrelevant — the run-rate alone already settles it, and no amount of estimating discipline changes the answer.

A worked comparison

A 25-person company evaluating a $180-per-seat platform against building the equivalent internally, over five years, with 3.4% price inflation and 4.5% salary inflation:

The build costs roughly nine times as much and the gap widens every year. At 25 seats this is not a close call, and the interesting observation is that it was never going to be — the crossover table said 185 seats before anyone opened a spreadsheet.

Run the same comparison at 400 seats and it inverts: licences reach $864,000 a year while maintenance stays near $418,000, and the build pays for itself inside the second year.

When building genuinely wins

None of this is an argument against building. It is an argument against building for the wrong reasons. Building wins when:

• Scale puts you well past the crossover. Per-seat pricing is brutal at headcount, and vendors know it.
• The capability is your actual differentiator. If customers buy you partly because of this system, outsourcing it outsources your advantage.
• Integration cost with the vendor approaches the build cost. A platform requiring eight months of integration work is not really a nine-month saving.
• The vendor is a concentration risk. Single supplier, unfavourable renewal terms, or a roadmap heading away from your use case.
• Regulatory or data-residency constraints make the vendor genuinely unusable rather than merely inconvenient.

The hybrid is usually underrated

The framing is rarely binary. Licensing the commodity layer while building only the thin slice that is genuinely differentiated avoids both the full licence bill and the full maintenance burden — and it is the option that gets skipped most often, because it is nobody's preferred outcome in the argument.

A decision checklist

• What is the crossover seat count, and how far are we from it today?
• What is the maintenance FTE estimate, and who has committed to funding it in year three?
• What does the vendor cost after the renewal uplift, not at the discounted first-year price?
• What product work is being displaced, and what is that worth?
• If the person who champions this build leaves in eighteen months, who owns it?
• Is there a hybrid that buys the commodity and builds only the differentiator?

The last question on that list is the one that most often changes the answer, and the one least often asked.

The same discipline applies to customer acquisition spend — see CAC payback vs. LTV:CAC for why a cost's timing matters as much as its size.

Educational content, not financial advice. Figures here are illustrative and exclude taxes, financing and one-off items. Model your own numbers in the simulator and check them with a qualified accountant before acting.