Build vs Buy Decision Tool
Answer 12 questions to get a data-driven build vs buy recommendation for your software need. Includes scoring rationale and next steps.
Build vs Buy Decision Tool
Adjust the inputs — your estimate updates live.
Answer each question about your software need. The tool scores your answers and recommends whether to build custom or buy an off-the-shelf product.
🔒 Runs entirely in your browser — your data never leaves this tab.
How this estimate works
The build vs buy decision is one of the most consequential software choices a business makes — and one of the most commonly under-analysed. Teams often default to buy because a shiny SaaS exists, or default to build because their engineers want to code. This tool scores 10 weighted criteria to give you a data-driven starting point for the conversation.
The four key criteria that matter most
Uniqueness of requirements: if your process is the same as thousands of other businesses (expense management, email marketing, CRM), buy. If your process is genuinely differentiated (proprietary pricing logic, unique workflow, custom data model), build. Competitive differentiation: software you compete on should be owned; commodity software should be bought. Integration depth: the more your needs require deep, bi-directional integration with your core systems, the more a custom build earns its cost. Existence of good off-the-shelf options: if three good products already cover 85% of your needs within budget, you need a compelling reason to build.
The hidden cost of buy decisions
SaaS costs are often underestimated. The advertised per-seat price is just the start — add integration cost, training time, workaround cost for the 20% the product does not cover, and the compounding effect of vendor price increases. A £300/month SaaS costs £3,600/year. Over three years with 15% annual price increases, that is over £12,000 — comparable to a custom build that perfectly fits your needs and that you own outright.
The costs each side of the decision hides
Build-versus-buy comparisons usually fail because they compare a known price against an underestimated one. Both options have costs that do not appear in the obvious column.
| Buying hides | Building hides |
|---|---|
| Per-seat cost as headcount grows | Maintenance at 15–20% of build cost yearly |
| Implementation and consultants | Hosting, monitoring, backups |
| Integration and middleware | Security patching and dependency upgrades |
| Workarounds for poor fit | Key-person risk when the builder leaves |
| Price rises at renewal | Opportunity cost of months without the tool |
The question that settles most cases
Is this process a differentiator or a commodity? Nobody wins customers with better payroll software — buy it. If how you quote, route or price work is genuinely part of why customers choose you, encoding that in someone else's tool caps it at what their configuration allows.
Cost the workarounds
The strongest argument for building is usually already visible in your operations. Count the hours per week your team spends in spreadsheets, duplicate entry or manual reporting because the current tool cannot do something. Six hours a week across a team is typically £15,000–£25,000 a year in loaded staff cost, and it belongs in the comparison alongside licence fees.
The hybrid most people should choose
Buy the commodity layer, build only the differentiated part, and connect them by API. You get mature software at commodity prices and bespoke capability exactly where it matters — usually cheaper than either extreme and much lower risk, because a disappointing custom component still leaves you with working software.
Frequently asked questions
When the process is a genuine differentiator rather than a commodity, when licence costs have overtaken build costs over a five-year horizon, when no available product fits your actual workflow, or when you are already spending heavily on integrations and workarounds to make a bought tool behave.
Maintenance at 15 to 20% of build cost every year, hosting, monitoring, backups, security patching, dependency upgrades, and the opportunity cost of months without the tool. Key-person risk matters too — who maintains it when the person who built it leaves?
Per-seat pricing as headcount grows, implementation and consultant fees, integration and middleware to connect it to your other systems, the staff time lost to workarounds when the fit is poor, and price rises at renewal once you are dependent.
Buy the commodity layer, build only the part that differentiates you, and connect them by API. It is usually cheaper than either extreme and much lower risk, because if the custom piece disappoints you still have working software underneath.
Count the hours per week your team spends in spreadsheets, duplicate data entry or manual reporting because the current tool cannot do something. Six hours a week across a team is typically £15,000 to £25,000 a year in loaded staff cost, and that figure belongs in the comparison.
Decided to build? Let's scope it.
ruxox builds custom software for growing businesses. Share your requirement and get a free scoping estimate within 48 hours.