Build vs. Buy Calculator
Enter your developer costs and the price of a ready-made solution to see which option saves more money over the long run. The calculator works out the full cost to build (including overhead and a realistic buffer for scope creep), annual maintenance, annual buy cost, and how many years it takes for building to pay off. Results update as you type.
What the calculator measures
The build vs. buy decision comes down to one financial question: does the one-time cost of building in-house get paid back quickly enough through avoided license fees? This calculator answers that by estimating the fully loaded development cost (including a scope-creep buffer), the recurring maintenance burden, and the annual savings you would earn by not paying a vendor. It then divides the upfront investment by those annual savings to give you the break-even year, and compares cumulative costs over your chosen horizon so you can see which option is cheaper at any point in time.
How the formulas work
First, the effective developer cost per month is the gross salary multiplied by (1 + overhead fraction), where overhead covers payroll taxes, benefits, equipment, and workspace. The raw build cost is: developers x months x effective monthly cost. That is then multiplied by the scope-creep buffer (default 1.5x) to account for the near-universal tendency for software projects to overrun their initial estimates. Annual maintenance is the developer-days per month spent on bug fixes, security patches, and upgrades, converted to an annual cost using a 22-working-day month. Annual savings from building equals the annual license fee minus annual maintenance. Break-even equals the upfront build cost divided by annual savings, expressed in years.
The scope-creep buffer and why it matters
Academic research and industry surveys consistently find that custom software projects overrun their initial time and cost estimates by a factor of 1.5 to 2. The Standish CHAOS Report, for example, has tracked software project outcomes for decades and finds that the majority of projects deliver late and over budget. Setting the buffer to 1.0 gives you the optimistic case; 1.5 is a realistic baseline; 2.0 is conservative and defensible for complex or novel systems. If your team has a strong track record of accurate estimation, use a lower number. If the domain is new or the requirements are vague, use a higher one.
Beyond break-even: strategic factors
The break-even calculation is necessary but not sufficient. A build decision also carries opportunity cost (what else could the engineering team deliver instead?), technical debt risk (in-house systems age and accrue maintenance burden), data ownership benefits (no third-party lock-in), and customization upside (the solution can match your exact workflow). A buy decision trades financial predictability and faster time-to-value for vendor dependency and the risk of price increases. The numbers from this calculator should anchor a broader conversation that includes those qualitative factors.
Build vs. Buy decision guidelines
| Break-even period | Verdict | Key consideration |
|---|---|---|
| Under 1 year | Strong build case | Verify capacity and long-term maintenance commitment |
| 1-2 years | Build favored | Confirm the in-house solution matches all feature requirements |
| 2-4 years | Build viable | Assess team retention and technology lifecycle risk |
| 4-6 years | Borderline | Opportunity cost and risk of technical debt often tip the balance to buy |
| Over 6 years | Buy recommended | Subscription flexibility usually outweighs long-term savings |
| Never | Buy clearly wins | Maintenance costs exceed the license - building is not financially justified |
General industry benchmarks for interpreting the break-even result.
Frequently asked questions
What is the scope-creep buffer and what value should I use?
The scope-creep buffer multiplies the raw development estimate to account for the well-documented tendency of software projects to take longer and cost more than originally planned. A value of 1.5 means the final cost is assumed to be 50% higher than the initial estimate, which is a common real-world outcome. Use 1.0 if you have a very well-defined specification and a track record of on-time delivery. Use 2.0 or higher for novel, complex, or poorly defined projects.
What should I include in the overhead percentage?
Overhead covers employer-side costs on top of gross salary: payroll taxes (varies by country but is typically 10-20%), health and dental insurance, retirement contributions, equipment (laptop, licenses), workspace, and any training budget. For a US-based salaried engineer, 25-40% is a typical range. For contractors, overhead is often lower because those costs are the contractor's responsibility, but a small buffer for management time is still appropriate.
How do I estimate maintenance days per month?
A widely used rule of thumb is that maintaining a live software system requires roughly 15-20% of the initial build effort per year. For a 6-month, 2-developer project that is 12 developer-months, 15% would be 1.8 developer-months per year, or about 3-4 developer-days per month. Highly regulated systems, systems with frequent external dependencies (APIs, third-party libraries), or consumer-facing products typically need more. Internal tools with stable requirements can often get by with less.
What does the break-even year actually mean?
The break-even year is the point at which cumulative savings from not paying the license fee exceed the upfront build cost. Before that year, buying would have been cheaper. After that year, building is cheaper. If the break-even is beyond your analysis horizon, or if annual maintenance exceeds the license cost (break-even is "never"), buying is the more economical choice under these assumptions.
Does this calculator account for price increases in SaaS subscriptions?
Not automatically. It assumes the license fee stays constant. If the vendor has raised prices historically, you can model the worst case by entering a higher monthly cost. Alternatively, run the calculator twice, once at the current price and once at a projected future price, and see how the break-even shifts.
Should I factor in the time value of money?
This calculator uses nominal cash flows without discounting. For decisions with a horizon under three years, the difference is usually small. For longer horizons (five or more years), a discounted cash flow model is more rigorous because a dollar saved five years from now is worth less than a dollar saved today. If your finance team requires a DCF, use the cumulative cost numbers from the year-by-year chart as inputs into a separate NPV calculation.