A practical framework for choosing between buying and building software, including the middle path of configuring a platform or starting no-code.
Buy, or configure, the software that is the same for every business in your field, and build the software that makes yours different. If a mature product already fits most of your workflow, buying is faster, cheaper to start and lower risk. Build when the software is part of how you compete, when no product fits without painful workarounds, or when you need to own the data and the roadmap.
The choice is rarely all or nothing. Most organisations end up with a mix, so the useful question is not 'build or buy?' but 'which parts belong where, and what would make us move a part later?'
Start with core versus commodity
**Core** software supports what customers choose you for, or a process that is genuinely unique to you. **Commodity** software does a job every organisation has: accounting, payroll, email, a standard help desk, a basic CRM. A simple test: if a competitor could buy the same tool and get the same result, it is commodity, and you gain little by building it.
Core also changes over time. Something that differentiates you today can become a commodity once a product category matures, and a commodity can become core if you find a different way to use it.
The factors that decide it
| Factor | Points toward buying | Points toward building |
|---|---|---|
| Differentiation | The task is the same for your competitors | The software is part of your advantage |
| Fit | A product covers most of the workflow | Every product you try needs workarounds in the core of your process |
| Integrations | Standard connectors already exist | Many unusual systems must work as one |
| Speed | You need to be running soon | You can wait, or a first version can be small |
| Cost over time | Subscription costs stay manageable as you grow | Per-user fees would grow faster than owning a build would cost |
| Control and data | Export and APIs are good | You must hold the data and decide the roadmap |
| Security and compliance | The vendor can show evidence of the controls you need | Requirements are specific, or data must stay in a particular place |
| Vendor risk | Several alternatives exist | Few alternatives, or the vendor is small or changing |
Compare over several years, not at the moment of purchase. Buying means a subscription (often per user, so it grows with headcount), setup, integration, training, workarounds for the gaps and the cost of migrating away. Building means design and development, hosting, security reviews, maintenance and the team time to own the system.
Neither is free, and the honest answer to 'which is cheaper?' is 'it depends'. A table with both options side by side over several years usually shows which one wins for you. If you build, the engagement shape changes your risk: see [pricing models](/company/pricing-models).
A bought product holds your data in its own format and on its own schedule. Before you sign, ask how to export everything, whether a documented API exists and what happens to your data if you leave or the vendor closes. A custom build gives you the data and the roadmap, but only if the agreement says you own the code and the accounts. Settle that in writing before work starts.
Buying does not hand your responsibility to the vendor. You still decide who has access, what data goes in and whether the vendor's hosting and controls meet your obligations, so ask for evidence rather than statements. Building gives you control of the threat model, and also the duty to do the work: threat modelling, secure coding, testing and a review before launch. Confirm legal obligations with qualified counsel. Our approach is in the guide to [secure app development](/guides/secure-app-development).
Buying gets you to a working first day sooner. But the vendor sets the roadmap and can change pricing, retire a feature or be acquired. Building carries its own risks: delay, growing scope and dependence on the team that built it.
The middle path: configure, then no-code, then custom
Think of a ladder rather than a fork. Each step gives you more control and takes more effort:
Start as low on the ladder as the problem allows, and decide in advance what would make you step up: cost that grows faster than the value, a limit the platform cannot pass, a data or security requirement it cannot meet, or performance that suffers under load. Plan the exit from day one by keeping data clean, documenting the logic and checking that you can export everything.
A decision checklist
Answer honestly. For the first four, a yes points toward building. The last four decide how you build or buy, not whether.
Several yes answers to the first four justify a closer look at custom software. None suggests buying. For a fuller walk-through, read [choosing how to build your product](/guides/choosing-how-to-build-your-product).
Three hypothetical scenarios
These are invented examples to show the reasoning. They are not client work.
Reminders are a commodity, and several products already do the job. Buy and configure, check where the data is hosted, and keep data export in the contract. Building would add cost for no advantage.
Its dispatch logic is how it beats competitors, and no product fits without workarounds. Build that part custom, and buy accounting, e-signature and messaging. Connect them through APIs so each piece can change on its own.
The main risk is whether anyone wants it, not whether it can scale. Build the first version on a no-code platform, learn from real use and write down the triggers for moving to custom code. [When no-code is the smart first version](/blog/when-no-code-is-the-smart-first-version) goes deeper.