Build-versus-buy arguments are conducted over the build estimate, and the build estimate almost never decides the answer. On the inputs this calculator loads with, the licence costs $132.8K over five years and the build costs $1.1M — of which $842K, or 77.8%, is not the build at all. It is the engineers who keep it alive afterwards.
What the calculator computes
Both paths are run through the same sixty-month engine against an otherwise identical business, so the only difference between them is the software decision. On the buy path you pay seats times price every month, indexed by price inflation at 3.4% a year. On the build path you pay the one-time build cost spread evenly across the build duration, and then, from the month after the system ships until month 60, you pay the maintenance engineers, indexed by salary inflation at 4.5% a year.
Two modelling choices are worth stating plainly. First, seats are set at 1.8 per engineer, not one. A platform bought for an engineering team is invariably paid for by adjacent staff too — support, data, security, product, whoever needs read access. At the loaded headcount of 8 engineers that is 14 seats, and under-counting seats is the single most common way a buy case is made to look artificially cheap. Second, both cost lines inflate. A licence signed today is not the licence you renew in year four, and neither is the salary.
Everything else — revenue, growth, payroll, cloud — is held identical across all three paths, so the profit and cash columns are directly comparable. The cash runway calculator takes the same engine from the other end.
The maintenance tail
Here is the whole argument in three numbers. The annual licence bill at the loaded inputs is $24,360. The annual maintenance bill is $174,000 — 7.1 times larger, from 1.2 of an engineer at a $145K loaded salary. Over sixty months that tail comes to $842K against a build estimate of $240K.
Maintenance gets forgotten for three reasons, and they compound. It is small: 1.2 of an engineer disappears inside a team of 8 without anyone filing a requisition. It is invisible: it lands on a payroll line that already existed, so no invoice arrives and no procurement process is triggered — precisely the scrutiny a vendor quote attracts. And it is permanent: a build cost shrinks in relative terms every year the system survives, while maintenance is an annuity that rises with salary inflation for as long as it exists.
The crossover, two ways
Ignore the build cost for a moment and compare only the two things you pay forever. Buying costs seats times price times twelve a year. Building costs maintenance headcount times loaded salary. Set them equal:
crossover seats = (maintenance FTE × loaded salary) ÷ (12 × price per seat)
At the loaded inputs that is $174,000 divided by $1,740, or 100 seats. You have 14. Read the same equation the other way and the licence would have to cost $1,036 per seat per month before the maintenance burden alone broke even; it costs $145. That is the sentence to take into the meeting. Seven times below the crossover, the build estimate is not a variable in the decision — it could be halved, or zeroed, and the answer would not move.
| Price per seat | Your annual bill | Crossover | Engineers implied |
|---|---|---|---|
| $75 | $12,600 | 193 seats | 107 engineers |
| $145 | $24,360 | 100 seats | 56 engineers |
| $250 | $42,000 | 58 seats | 32 engineers |
| $400 | $67,200 | 36 seats | 20 engineers |
| $600 | $100,800 | 24 seats | 13 engineers |
| $1,000 | $168,000 | 15 seats | 8 engineers |
The second crossover is the one that includes the build. Over sixty months a single seat costs $9,483 in inflating licence fees, so the licence total catches the full build total at about 114 seats — roughly 63 engineers. Below the run-rate crossover, nothing can rescue the build. Between the two crossovers the build wins eventually but not inside five years. Above both, it wins outright.
Where the answer actually flips
Because the build cost and the maintenance load do not scale with headcount but the licence bill does, seat count is the variable that decides these arguments. There is one headcount on either side of which the answer is unambiguous, and it is not close at either extreme.
| Headcount | Seats | Licence | Build | Cheaper path |
|---|---|---|---|---|
| 4 engineers | 7 | $66.4K | $1.1M | Buy, by $1M |
| 8 engineers | 14 | $132.8K | $1.1M | Buy, by $949.3K |
| 16 engineers | 29 | $275K | $1.1M | Buy, by $807K |
| 32 engineers | 58 | $550K | $1.1M | Buy, by $532K |
| 64 engineers | 115 | $1.1M | $1.1M | Build, by $8.5K |
| 120 engineers | 216 | $2M | $1.1M | Build, by $966.2K |
At 4 engineers buying is cheaper by roughly an order of magnitude. At 120 it is the build that wins by $966.2K. The interesting rows are in the middle, where the two totals converge and the decision stops being a cost decision at all: the calculator flags any gap under 15% of the licence total as too close to call, because at that margin the model error exceeds the difference.
The build-in-house scenario in the full simulator: 22 engineers, an $850K build over twelve months, and 2.5 maintenance FTE carried against a real revenue line and a real cash balance.Open in simulator →The build-duration artefact
Lengthen the build duration in the calculator and the five-year build cost falls. Take that at face value and you would conclude that slower delivery is cheaper, which is obviously wrong, so it is worth being explicit about why the model does it.
| Build duration | Months maintained | Maintenance total | Five-year build cost |
|---|---|---|---|
| 3 months | 57 | $931,130 | $1.2M |
| 6 months | 54 | $886,824 | $1.1M |
| 9 months | 51 | $842,029 | $1.1M |
| 12 months | 48 | $796,737 | $1M |
| 18 months | 42 | $704,646 | $944.6K |
| 24 months | 36 | $610,505 | $850.5K |
| 36 months | 24 | $415,892 | $655.9K |
The one-time cost is the same in every row; what changes is that maintenance does not start until the system ships, so a longer build simply pushes more of the tail past month 60. A 36-month build shows a five-year cost of $655.9K against $1.1M for a 9-month one, and every dollar of that difference is deferred, not saved. It reappears in year six.
It also ignores the vendor bill you keep paying while you build, which the build column never shows. Treat the duration input as your honest estimate of when the system ships, and read five-year totals for builds past eighteen months as understated.
The hybrid nobody argues for
The widget shows a third row: license the commodity layer, build only the slice that is genuinely differentiated. In the model it carries 45% of the seats and 60% of the build and maintenance, and at the loaded inputs it lands at $708,958 — between the $132,758 of buying and the $1,082,029 of building.
Be clear about what that means: on cost alone, the hybrid is never the cheapest of the three, at any seat count, any price and any build estimate. It carries a fraction of both bills, and a fraction of both is always more than the cheaper one alone. Anyone selling the hybrid as a saving is selling something the arithmetic does not support.
Its case is a risk case. It caps the maintenance surface at the part you actually differentiate on, and it keeps a vendor alive so a failed build has somewhere to fall back to. It gets skipped most often because it is nobody’s preferred outcome in the argument — the build advocates want the build, the finance side wants the licence — and it is frequently the right answer anyway.
What is excluded, and how to adjust
Four costs sit outside the model. Two favour buying, two favour building, and all four have to be added by hand:
- Opportunity cost of the engineers. The largest omission by some distance. The build costs $240K of engineering and 1.2 FTE forever; the question is what those people would otherwise have shipped. If the answer is revenue-generating product work, add its value to the build column. The maths on what an engineer actually costs over five years is worked through in the engineering-hire guide.
- Build overrun risk. The calculator takes your estimate at face value. Software estimates are systematically low, and the correct adjustment is not a contingency percentage but a scenario: run it once at your estimate and once at double, and see whether the decision changes. Below the run-rate crossover it will not.
- Vendor lock-in and switching cost. The licence column assumes you can leave at renewal. If your data model, integrations and internal processes are shaped around the vendor, you cannot, and the price rise at renewal is not a negotiation. Add an allowance for migration to the buy column, or treat the price-inflation input as a lever rather than a constant.
- The value of control. Roadmap independence, data residency, and the ability to build something the vendor will never ship are real and genuinely favour building. They are also the easiest thing in this decision to overstate, so put a number on them rather than invoking them.
How to use the output
Run the run-rate crossover first, before opening any build estimate. If your seat count is far below it, you have your answer and the estimating exercise is theatre. If you are near or above it, the build estimate becomes decisive — and only then is it worth the two weeks needed to produce one you can defend.
The full argument
A calculator gives you the number. These work through what it means.
Written by
Assaf Schwartz
Assaf Schwartz builds and maintains SimulateFin — the projection engine, the guides and the site around them. The methodology is published in full precisely so it can be argued with: corrections, disagreements and missing metrics are welcome by email.
Educational content, not financial advice. This tool models the assumptions you enter and excludes taxes, financing and one-off items. Check any figure that matters with a qualified accountant before you act on it.

