A build vs buy calculator puts two options that feel incomparable onto the same footing. Building is a large sum now followed by a small recurring one. Buying is a small sum now followed by a large recurring one that grows every year. Comparing them requires a stated horizon, a discount rate and an honest maintenance figure, and most build-versus-buy arguments go wrong because one of those three was never agreed.
Arb Digital publishes this in the free tool library at arbsbuy.com for owners weighing a custom system against a subscription, an in-house team against an agency, or a bespoke platform against an off-the-shelf one. It differs from the live automation savings calculator, which measures the time a process saves once automated; this page ignores the benefit entirely and compares only the cost of two routes to the same outcome.
What This Build vs Buy Calculator Does
Both options are modelled as a one-off cost at the start plus a stream of annual costs across the horizon, and every annual cost is discounted back to today at the rate you supply. The build option adds the value forgone during the months before it is ready, which is a real cost that comparisons routinely omit. The buy option compounds its annual figure by an escalation rate, because renewal prices very rarely stay flat.
The hero names the cheaper option in present value terms and the size of the gap. The grid gives both totals, the difference, and the crossover year — the first year in which the running discounted total for building falls below the running total for buying. If that crossover never arrives inside the horizon, the tool says so rather than implying one.
The bars split each option into its one-off and ongoing components. That split is the part worth showing anyone who has to approve the decision, because two options with the same total can have completely different cash profiles, and a business short of cash today cares about the profile more than the total.
How to Use It
- Set the horizon before you look at any cost. Deciding it after you have seen the numbers is how a comparison gets reverse-engineered into the answer someone already wanted.
- Cost internal build time at a fully loaded rate. Salary plus employer taxes, benefits, equipment and management overhead — not the headline salary, which typically understates the real figure substantially.
- Be realistic about annual running cost. Software that is finished still consumes time: dependency updates, security patches, browser and platform changes, and the person who has to remember how it works.
- Set escalation from the contract, not from hope. Many agreements permit annual increases at a stated cap, and that cap is the number to model.
- Run the horizon at several lengths. If the answer flips between three years and seven, the honest conclusion is that cost is not what should decide this.
The Formula / How It's Calculated
Each option's present value is one-off cost + Σ (annual cost in year t ÷ (1 + r)^t) summed from year one to the horizon. For the build option the one-off is the delivery cost plus months of delay multiplied by the monthly value forgone. For the buy option the annual cost in year t is the year-one figure multiplied by (1 + escalation)^(t−1).
Run the defaults. Building costs 180,000 to deliver plus six months at 8,000 of forgone value, so the one-off is 228,000. Annual running cost is 36,000, and discounted at eight percent over seven years that stream is worth 187,429, giving a build present value of 415,429.
Buying costs 15,000 to implement, then 78,000 in year one rising five percent annually. Discounted at eight percent over the same seven years, that stream is worth 465,323, giving a buy present value of 480,323. Building is cheaper by 64,894 over seven years. But look at the crossover: at the end of year five the running totals are 371,738 for building and 356,599 for buying, so buying is still ahead. Building only pulls in front during year six. Over a five-year horizon the same inputs favour buying; over seven they favour building. The horizon, not the costs, decided it.
The Inputs Dominate the Answer, and You Should Say So
This is the most important section on the page. A build-versus-buy model is not a machine that discovers the right decision. It is an arithmetic engine that turns your assumptions into a number, and the assumptions carry almost all of the information.
Three inputs do the heavy lifting. The horizon can reverse the result on its own, as the worked example above demonstrates with nothing else changed. The annual running cost for the built option is chronically underestimated — a useful sanity check is that ongoing maintenance for custom software commonly runs at a meaningful fraction of the original build cost every year, and any figure far below that deserves justification. The build cost itself is subject to the same optimism that affects every project estimate; the tendency of estimates to be too low is well enough established that public-sector estimating guidance, such as the GAO Cost Estimating and Assessment Guide, builds risk and uncertainty analysis into the process rather than treating a single-point estimate as the answer.
The practical response is to run the model three times: with your expected figures, with a pessimistic build case, and with an optimistic one. If building wins in all three, the decision is robust. If it wins only in the optimistic case, the model has told you something genuinely useful — that the cost argument for building is fragile, and the decision should rest on the non-financial reasons instead.
The Costs Almost Nobody Enters
Several real costs sit outside the obvious fields, and leaving them out biases the comparison towards building every time.
Key-person risk is the largest. Custom software written by one or two people carries a hidden liability that becomes visible the moment they leave, and the cost of rebuilding institutional knowledge is real even though it never appears on an invoice. Opportunity cost is the second: the team building this is not building something else, and if that something else was closer to what the business actually sells, the cost of the build is not the salary but the forgone alternative. The opportunity cost calculator is a way to put a figure on that comparison directly.
On the buy side the omissions run the other way. Switching costs compound with time — the longer a bought system holds your data and your processes, the more expensive leaving becomes, and the more pricing power the vendor has at each renewal. Integration effort is routinely underestimated, and vendor risk is real: a supplier can be acquired, can discontinue the product, or can reprice at renewal well beyond the escalation you modelled. Neither list is exhaustive, and neither belongs in a spreadsheet cell without a note explaining the assumption behind it. The same trade-off between short-term flexibility and long-term ownership appears in the Small Business Administration's guidance on how to manage your business finances, which frames the lease-or-buy question for equipment in exactly these terms.
When Cost Should Not Decide
A cost model is the right tool when both options genuinely produce the same outcome. Frequently they do not, and then the model is answering a question nobody asked.
Build when the capability is what the business sells, or is the thing customers choose you for. Nobody outsources their own product, and a cost comparison that recommends buying your core differentiator has been fed the wrong question. Build when no product on the market fits the process closely enough, and when bending the business to fit a bought tool would cost more than the tool saves.
Buy when the capability is necessary but undifferentiated — payroll, accounting, email, payments. A bought system in these categories is maintained by people whose entire business is maintaining it, and the cost comparison usually favours buying anyway. Buy when speed matters more than fit, because the delay field on this page rarely captures the full cost of being late to a market. And buy when the alternative is building something you will have to keep staffed for a decade, since the payback period calculator and the NPV calculator tend to look far less appealing once a permanent headcount is attached to the outcome.
Choosing a Discount Rate You Can Defend
The discount rate converts future money into today's money, and it is the field people are least confident about setting.
The principled answer is the business's weighted average cost of capital — the blended cost of its debt and equity funding — which the WACC calculator derives from the capital structure. That is the rate at which the business genuinely trades money now against money later. A common shortcut is to use the marginal borrowing rate, on the reasoning that cash spent today is cash not used to repay debt, and the cost of debt calculator produces that figure from interest expense and total debt.
What matters most is applying the same rate to both options, because the discount rate systematically favours whichever option pushes cost further into the future — here, buying. A high rate makes the deferred subscription look cheap; a low rate makes the upfront build look expensive. Since the rate is a judgement, the safest practice is to test the decision at a rate a few points either side and check whether the recommendation survives. If it does not, that fragility is itself the finding worth reporting.
Arb Digital designs and builds business websites, and will tell you plainly when a platform you can buy would serve you better than something bespoke.
Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Setting the horizon after seeing the costs — it is the input most able to flip the answer, so it has to be agreed first.
- Understating maintenance — finished software still consumes patching, upgrades and someone's attention every year for as long as it runs.
- Costing internal time at base salary — a fully loaded rate including taxes, benefits and overhead is materially higher.
- Assuming the subscription price stays flat — renewal escalation compounds, and over seven years it is a large part of the buy total.
- Ignoring the months before the build works — the bought option delivers value from day one, and that head start is a genuine cost of building.
Related Free Tools From Arb Digital
Pair this with the NPV calculator for the discounting mechanics in isolation, the payback period calculator for how fast an outlay returns, the WACC calculator for a defensible discount rate, the opportunity cost calculator for what the build team would otherwise produce, the automation savings calculator for the benefit side this page deliberately ignores, and the break-even calculator when the question is volume rather than time. The full free online tools hub lists everything else.
Frequently Asked Questions
Put both on a stated horizon, discount every future cost back to today at the same rate, and include the build option's ongoing maintenance and its months of delay. Comparing an upfront build cost to one year of subscription is the most common unfair comparison.
Whatever period you can honestly say the capability will still be needed and still be fit for purpose. Agree it before looking at costs, and test the decision at a shorter and a longer horizon to see whether the answer survives.
Because building front-loads cost and buying spreads it. A short horizon favours the option with the small upfront cost, and a long one favours the option with the small recurring cost. On the default figures buying wins over five years and building wins over seven.
Maintenance, hosting, security patching, dependency upgrades and the share of a person's time the system permanently consumes. This is the field most often set too low, and a figure far below a meaningful fraction of the build cost deserves justification.
Your cost of capital is the principled choice, and your marginal borrowing rate is a common shortcut. The critical part is applying the same rate to both options, since a higher rate always favours whichever option defers cost further into the future.
Only when both options genuinely deliver the same outcome. If the capability is what your business sells, or if no product on the market fits, the strategic reason should decide and the cost model simply prices it.
The first year in which the running discounted total for building drops below the running total for buying. If it falls outside the horizon you set, the tool reports that rather than implying a crossover that the model does not support.
Because the bought option starts working immediately. Any benefit the capability would have produced during the build period is genuinely given up, and leaving it out biases the comparison towards building.
This calculator performs arithmetic on figures you supply and is provided for general information only. It is not financial, accounting or procurement advice, and its output is driven almost entirely by your assumptions about horizon, maintenance and discount rate — confirm any figure used in a real purchasing or investment decision with a qualified professional.
