Build vs Buy in 2026: The Upkeep Line That Turns a $45,000 Build Into $90,000
The estimate that comes back from engineering is for version one. It answers "how long would this take to build", not "what will this cost us". The two questions differ by every month the thing exists after it ships: the bug that surfaces in week nine, the dependency upgrade, the security patch, the person on call for it at 2am.
Buying fails in the opposite direction. The monthly price looks trivial beside a build quote, then runs unquestioned for three years while nobody re-opens the decision.
Below is the arithmetic both ways, using the figures the build vs buy engine carries as its own defaults. Every number is worked arithmetic for a hypothetical feature, not a forecast about yours.
Quick answer
A three-engineer-month build at $15,000 a month costs $45,000 to write and $90,000 to own over three years, once one engineer-month a year of upkeep is counted. The same job bought at $500 a month with a $2,000 setup fee costs $20,000 across those three years — $70,000 less. That build never catches up, because upkeep alone runs $1,250 a month against a $500 bill. The condition that flips the answer is the vendor's price: at $4,000 a month, building the identical thing is $66,500 cheaper and pays for itself in month 17.
The estimate is for version one
Upkeep decides most of these arguments and is the line that gets left off the slide. The engine puts it at 15% to 25% of the build effort every year, and more on a small build — bug fixes, dependency upgrades, security patches, the migration when the platform underneath changes. Its default of one engineer-month a year is 33% of a three-month build, and the tool says so where it asks for the number: being on call, upgrading dependencies and patching security holes have a floor that does not shrink with the feature.
That single row is what turns $45,000 into $90,000. It is not a contingency and it does not taper: software you own is a standing obligation, and the fixed costs of owning it — someone who understands it, someone on call for it — do not scale down when the feature is small.
An engineer-month is not a salary divided by twelve
The engine asks for the cost of one engineer per month, not a salary, and it means fully loaded: payroll tax, health cover, equipment, software licences, space. Its default is $15,000 a month, labelled as roughly a $140,000 salary once loaded — a multiple of about 1.3. That is the bottom of the band the same page states: a US engineer on $140,000 to $220,000 costs $15,000 to $24,000 a month at that multiple. The cheapest figure in the range is the default on purpose, because a low engineer cost is the one that flatters building.
It is a default, so treat it as one. Enter $19,500 a month — a $180,000 salary at that multiple — and the three-month build's three-year cost goes from $90,000 to $117,000, widening the gap against buying from $70,000 to $97,000. Nothing changed except the pay band.
Three years, in both columns
| Over three years | Build it | Buy it |
|---|---|---|
| Up front | $45,000 — 3 engineer-months at $15,000 | $2,000 setup |
| Running | $45,000 — 1 engineer-month a year, three years | $18,000 — $500 × 36 months |
| Total cost of the decision | $90,000 | $20,000 |
| Cost per month after launch | $1,250 | $500 |
| Month it pays for itself | never — upkeep outruns the subscription | — |
The verdict the engine returns on those inputs is "Buy it: building would cost about $70,000 more", and the rule that fires is the blunt one — building costs more than twice as much as buying over the period. Nothing in that table is exotic. It is the ordinary cost of the ordinary decision with the second row left in.
Where the break-even actually is
Payback is the first month the build's running total falls to or below the subscription's. The build starts $43,000 behind — $45,000 spent against $2,000 — and closes that gap only if upkeep costs less per month than the subscription.
At one engineer-month a year it does not close at all. Upkeep is $1,250 a month against a $500 bill, so the build falls further behind every month it exists. That is what the engine means by "Never": it prints that word only when a month of upkeep costs at least as much as a month of subscription, so the two running totals diverge and no amount of time closes them.
A crossover only exists once upkeep drops below $500 a month — below 0.4 engineer-months a year — and even then it is distant. At a quarter of an engineer-month a year, $313 a month, the engine returns month 230: about nineteen years out. It reports the month rather than giving up past a horizon, which matters, because "Never" and "month 230" are different facts that happen to lead to the same decision. One says the arithmetic never crosses; the other says it crosses, long after the feature and probably the company are gone.
That reframes the question usefully. It is not "is building cheaper". It is how long this feature has to live for building to have been the cheaper choice — a month you can get out of your own upkeep estimate in one pass. If it lands beyond the product's roadmap, buy.
The two cases where building genuinely wins
The vendor's pricing scales against you. Seat-, volume- and usage-priced tools convert your growth into their revenue, and the bill you signed at twelve people is not the bill at eighty. Rerun the decision against a vendor now charging $4,000 a month:
| Over three years | Build it | Buy it at $4,000 a month |
|---|---|---|
| Up front | $60,000 — 4 engineer-months | $5,000 setup |
| Running | $22,500 — half an engineer-month a year | $144,000 |
| Total | $82,500 | $149,000 |
| Verdict | Build — about $66,500 cheaper | |
| Month it pays for itself | 17 |
Same engine, same rules, opposite answer. Stretch it to five years and the gap widens to $147,500, because the build's running cost is $7,500 a year and the vendor's is $48,000.
It is core to what customers choose you for. This carries less weight than founders expect, because the engine checks its rules in order: a commodity is bought; a high-risk build is bought; a build costing more than twice as much as buying is bought; only then does "core" argue for building. Mark the first example core and the verdict does not move — still Buy, because the build costs 4.5 times the subscription. Core breaks a tie; it does not overturn a 4.5× gap. And "we might differentiate on this one day" is not the test. The test is whether a customer would notice and choose you for it.
Risk overrides both. Take the $4,000-a-month case building wins by $66,500, mark it "unclear scope or new ground", and the verdict flips back to Buy — a late or failed build costs more than the subscription ever will.
The line that is in neither column
The engine is explicit about what it does not model: the value of shipping sooner, what your engineers would have built instead, vendor price increases, and the cost of switching vendors later. The second of those is usually the largest number on the page.
Four engineer-months here is a third of a year of one person not on the roadmap. There is a defensible way to price that: if you know what a dollar of spend currently buys in new annual recurring revenue — your burn multiple — you know roughly what those months were worth pointed somewhere else, and the figure belongs in the build column before you compare totals.
The buy column has omissions of its own. Migration and training are real months of someone's time, and the 36-month total assumes the price never rises. Put migration and training in the setup cost, enter the price you expect in year three rather than today's, add your opportunity cost to the build side, and then compare the two totals with your own figures. A verdict that survives all four adjustments is a decision rather than a preference.
FAQ
Our estimate is two weeks, not three months. Does any of this still apply?
Yes, in proportion. Upkeep tracks what exists, so a two-week build carries a smaller tail — but not a zero one, because on-call, upgrades and security patching have a floor. Enter it in quarter-month increments. What matters is the monthly running cost, not the total: if upkeep costs more per month than the subscription, the build never catches up however cheap it was to write. Against a $500 subscription, that threshold is 0.4 engineer-months a year.
How much buffer should I add to the engineer-months?
Fifty per cent, entered in the field rather than held in your head. The McKinsey and Oxford study of large IT projects found an average 45% budget overrun and 7% schedule overrun. Moving three engineer-months to 4.5 takes the first build from $90,000 to $112,500 and widens the gap from $70,000 to $92,500. On the $4,000-a-month case, four months to six leaves building ahead by $36,500 instead of $66,500 and pushes payback from month 17 to month 26.
It is core to our product. Doesn't that settle it?
Not by itself. The cost test runs before the core test, so a build costing more than twice as much as buying is a Buy even when marked core. Core is the tie-breaker when the money is close, not a licence to spend 4.5 times more. Where it does decide is a case that already passes the cost test — the $4,000-a-month example, where building is 45% cheaper and pays back inside two years. There, owning it is worth the tail.
What are the hidden costs on the buying side?
Setup and migration, which take months of someone's time rather than the weekend the demo implied; training, hours per user across everyone who touches it; annual price rises, which compound across the three years you are comparing; and switching cost later, which can rival the original setup. The engine counts only the setup fee and the monthly price, so it understates buying unless you load the setup field and enter a forward price. The honest comparison is a loaded build number against a loaded buy number.
Sources
- McKinsey & Company and the University of Oxford, study of large IT projects — the 45% average budget overrun and 7% schedule overrun cited above
- US Bureau of Labor Statistics, Employer Costs for Employee Compensation — the published series behind any fully-loaded multiple of salary, and the place to check the multiple you use
- Investor Sam's build vs buy engine — the defaults used throughout ($15,000 an engineer-month, one engineer-month a year of upkeep, $500 a month plus $2,000 setup, three years), the four ordered rules and the payback definition, all documented on the tool page
General information about how a build-versus-buy comparison is constructed, not financial or legal advice. Engineering costs, upkeep effort and vendor pricing vary enormously between companies, and every figure above is worked arithmetic for a hypothetical feature rather than an estimate for yours.