The two costs of building, and only one of them gets estimated
Every build estimate is a number of developer-months multiplied by a loaded cost. That part is usually done with care. What follows it rarely is: once the system exists, somebody patches it, upgrades its dependencies, answers questions about it, fixes what breaks when an upstream API changes, and implements the changes users ask for. That work does not stop while the system is in use, and it is the term that decides most build-versus-buy comparisons.
Expressing maintenance as a percentage of build cost is the standard convention in software cost estimation, and it has a useful property: it scales with the thing you built. A larger system costs more to keep running, which is exactly right and is why a build that takes twice as long does not merely cost twice as much — it also carries twice the annual maintenance for the rest of the horizon.
On the buy side the mirror image applies. The licence is visible and the implementation is not, and the licence escalates every year while your build's maintenance is anchored to a cost you incurred once. That is the structural reason long horizons favour building and short ones favour buying, and why the horizon is the input that most often decides the answer.
Discounting matters here more than in most comparisons because the two options have opposite cash shapes: build is front-loaded, buy is spread. At a 10% cost of capital, a dollar in year five is worth 62 cents today, which systematically favours the option that pays later. Comparing undiscounted totals quietly penalises building; this calculator reports both so you can see the effect.
Two cash streams, one present value each
The build stream is a lump at time zero plus an annuity: D + Σ mD/(1+r)^t for t from 1 to Y, where D is developer-months times loaded monthly cost and m is the maintenance fraction. Because maintenance is constant in nominal terms, that sum is mD multiplied by the ordinary annuity factor for your rate and horizon — 3.790787 at 10% over five years.
The buy stream is I + Σ L(1+u)^(t−1)/(1+r)^t. It is a growing annuity, so it discounts less favourably than a flat one when the uplift is positive: each year's payment is larger than the last, which partly offsets the discounting. When the uplift equals the discount rate, every term collapses to L/(1+r) and the stream is flat in present value.
The break-even year is found by accumulating both streams in present value and reporting the first year in which the build's cumulative total falls below the buy's. It is not always reached: if annual maintenance is at least the annual licence, the build's cumulative curve never catches up, and the calculator reports no break-even rather than an implausible one far beyond the horizon.
The overrun figure is a sensitivity rather than part of the comparison. Extra developer-months add to D, and because maintenance is a percentage of D, they also raise every subsequent year: the undiscounted impact is Δ × (1 + mY). At 18% maintenance over five years that is 1.9 times the raw overrun — which is why schedule risk on a build is more expensive than it first appears.
Worked example: 18 developer-months against a $180,000 licence
You need a capability for five years. Building it is estimated at 18 developer-months at $16,000 loaded per month, with maintenance at 18% of build cost a year. Buying it costs $180,000 a year with a 7% uplift plus $60,000 to implement. Your cost of capital is 10%.
- Development cost. 18 × $16,000 = $288,000 at time zero.
- Annual maintenance. 18% × $288,000 = $51,840 a year.
- Build present value. $288,000 + $51,840 × 3.790787 = $288,000 + $196,514.39 = $484,514.39.
- Build undiscounted. $288,000 + 5 × $51,840 = $547,200.
- Buy present value. $60,000 + the discounted licence stream $180,000/1.1 + $192,600/1.21 + $206,082/1.331 + $220,507.74/1.4641 + $235,943.28/1.61051 = $60,000 + $774,754.34 = $834,754.34.
- Buy undiscounted. $60,000 + $180,000 × 5.750739 = $60,000 + $1,035,133.02 = $1,095,133.02.
- Present-value advantage of building. $834,754.34 − $484,514.39 = $350,239.96.
- Break-even year. Cumulative present value: at year 1, build $335,127.27 against buy $223,636.36, so buying is still ahead. At year 2, build $377,970.25 against buy $382,809.92 — building overtakes during year 2.
- Overrun sensitivity. Six extra months is $96,000 of development and raises maintenance by $17,280 a year, so the undiscounted impact is $96,000 × (1 + 0.18 × 5) = $182,400.
Read steps 7 and 9 together. Building is $350,239.96 ahead on present value, and a six-month overrun costs $182,400 — about 52% of the advantage. A twelve-month overrun would consume all of it. That is the actual risk in this decision, and it is a delivery risk rather than a pricing one.
What the numbers do and do not settle
Treat the present-value difference as a threshold rather than a verdict. If building wins by less than the cost of a plausible overrun, the financial case is a coin toss and the decision should be made on capability, speed to value and strategic control instead. The calculator prices exactly one overrun scenario so you can make that comparison directly.
Check the break-even year against how long the capability is genuinely needed. A break-even in year two on a five-year horizon is durable. A break-even in year four on a five-year horizon means the entire case rests on the last twelve months, and any change of direction destroys it. The most common failure is a build justified over seven years for a business that changes its mind every three.
Then look at what is not in the model. The largest omission is opportunity cost: those 18 developer-months would otherwise have gone into something else, and if that something else was revenue-generating, its value belongs on the build side of the ledger. The second is time to value — a bought product delivering in six weeks against a build delivering in eighteen months is a year of benefit the comparison ignores. The third is the risk difference: a licence is a known quantity, and a build is an estimate.
Finally, consider the middle options. Buying a platform and building on top of it, adopting an open-source base with paid support, or buying now with an explicit intention to replace later are all real answers that this two-way comparison does not offer. Run the calculator on each variant rather than treating build and buy as the only two paths.
How long a build takes to repay itself against a $180,000 licence
| Developer-months | Build cost | Annual maintenance | Annual saving vs licence | Simple payback (years) |
|---|---|---|---|---|
| 6 | $96,000 | $17,280 | $162,720 | 0.59 |
| 12 | $192,000 | $34,560 | $145,440 | 1.32 |
| 18 | $288,000 | $51,840 | $128,160 | 2.25 |
| 24 | $384,000 | $69,120 | $110,880 | 3.46 |
| 36 | $576,000 | $103,680 | $76,320 | 7.55 |
Payback grows faster than build size because maintenance grows with it, shrinking the annual saving in the denominator. Doubling the build from 18 to 36 months multiplies payback by 3.4, not by 2. At maintenance of $180,000 a year — a build of 180,000 ÷ (0.18 × 16,000) = 62.5 developer-months at these rates — the saving reaches zero and there is no payback at all.
What this comparison leaves out
- Opportunity cost. The team building this is not building something else. If that something else was revenue-generating, its value belongs on the build side and is frequently the largest single term.
- Time to value. A bought product live in six weeks delivers a year of benefit that a build shipping in eighteen months does not. Nothing in a cost comparison captures it.
- Estimate risk. A licence is a contracted number; a build is a forecast, and software forecasts are famously optimistic. That asymmetry is why the overrun sensitivity exists.
- Key-person risk. A built system depends on the people who know it. When they leave, maintenance cost rises sharply and is rarely re-estimated.
- Feature drift. The bought product keeps adding capability at no extra cost; your build only gains what you fund. Over a long horizon this widens rather than narrows.
- Compliance and certification. If the capability touches regulated data, a vendor's existing certifications may be worth more than the entire cost difference.
- Exit and switching cost on both sides. Replacing a build and replacing a vendor both cost real money at the end of the horizon.
Choosing a maintenance percentage
This is the input people most often set too low. Maintenance covers security patching, dependency and framework upgrades, changes forced by upstream APIs, user support, and the small feature requests that never stop. A figure below 10% of build cost a year implies a system nobody is asking anything of, which is only true of software nobody uses. Rather than defending a number in the abstract, look at an existing internal system of comparable size and count the hours it actually consumes in a quarter — that ratio, applied to the new build's estimated cost, is a far better input than any published rule of thumb.
Where the decision usually lands
Buy anything that is not differentiating. Payroll, identity, ticketing, expense management and CRM are solved problems with mature vendors, and building them consumes the engineering capacity that could have gone into whatever your customers actually pay for. The cost comparison rarely favours building these, and even when it does, the opportunity cost usually reverses it.
Build where the capability is the product, where no vendor fits without heavy customisation, or where the vendor's pricing scales with something you expect to grow fast. That last case is worth checking numerically rather than by instinct: a licence that scales with usage can be modelled with the per-seat versus usage calculator, and a licence that escalates annually with the uplift calculator.
Whichever way it goes, make the comparison complete before deciding. The bought option's real cost includes administration and exit as well as the licence, which is what the total cost of ownership calculator adds; the built option's real cost includes the infrastructure it will run on, which the unit cost calculator can size. And if the decision is really about replacing something that already exists, the migration itself deserves its own case through the migration payback calculator.