ruxox
Start
Start
Calculators

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.

About this tool

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.

FAQ

Frequently asked questions

When is "buy" almost always the right answer?
Buy for: payroll (ADP, Sage), email sending (SendGrid), auth/identity (Auth0), payments (Stripe), video calling (Zoom). These are complex, compliance-heavy, and have large engineering teams maintaining them. Building a Stripe alternative is not a good use of any company's resources. Buy commodity; build differentiator.
What is vendor lock-in and how serious is it?
Vendor lock-in occurs when migrating away from a SaaS becomes prohibitively expensive — your data is in a proprietary format, your workflows are built around the UI, or your integrations all point to their APIs. It is most serious in core data platforms (CRM, ERP), less serious in point solutions (a specific analytics tool). Mitigate it with data export requirements in the contract, open APIs, and regular data portability tests.
What does "build with selected buy components" mean in practice?
A common pattern: build the custom application logic (the part where you have unique requirements) but use SaaS for commodity sub-functions. For example: build a custom order management system, but use Stripe for payments, Auth0 for authentication, SendGrid for transactional email, and Datadog for monitoring. You own the core and use best-of-breed for everything peripheral.
How does this tool handle the case where we have no tech team?
No in-house technical resource is a strong signal toward buy — unless you are planning to engage an external agency like ruxox to build and hand over. A custom-built application without someone to maintain it creates technical debt risk. If you lack technical resource, factor in ongoing support retainer cost in any build scenario.
Custom software

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.