Every growing business eventually faces the same question: do we buy a product for this, or build our own? Both answers can be right. The expensive mistakes come from deciding by habit, either “we always build” or “there must be an app for that”, instead of by fit.
Here is a practical way to decide.
What each option really means
Off-the-shelf (buy): a ready-made product, usually SaaS, that you subscribe to and configure. Accounting, HR, payroll, CRM, helpdesk and project management are classic examples.
Custom (build): software designed and built for your organisation, which you own and control. It can be an internal system, a customer-facing platform or a product you sell.
Hybrid: buy products for standard functions, then build custom software, extensions or integrations around them. This is how most mature organisations end up working.
When buying is the better choice
Buy when:
- The process is standard. Paying suppliers, running payroll and tracking leave work much the same everywhere. A mature product already encodes good practice.
- Speed matters more than fit. A product can be configured in weeks.
- It is not where you compete. If customers would never notice the difference, don’t spend engineering effort on it.
- Compliance is built in. Good products keep up with tax, security and regulatory changes for you.
When building is the better choice
Build when:
- The process is your advantage. How you price, serve, match, schedule or deliver may be exactly what sets you apart. Forcing it into a generic tool erodes that.
- No product fits without heavy workarounds. If people keep spreadsheets alongside the “system”, the system doesn’t fit.
- Integration is the real job. When value comes from connecting several systems and data sources, a custom layer is often simpler than bending one product to do it.
- Licence costs at scale outweigh build costs. Per-user pricing that is cheap for 20 people can be expensive for 2,000.
- You need control. Over the roadmap, data, hosting location or user experience.
Compare total cost, not the first invoice
| Cost | Off-the-shelf | Custom |
|---|---|---|
| Upfront | Low: setup and configuration | Higher: discovery, design and build |
| Ongoing | Subscriptions that grow with users and modules | Hosting, maintenance and improvements |
| Integration | Connectors, or custom work when they don’t fit | Designed in from the start |
| Workarounds | Time lost when the product doesn’t fit | Low, if built around real workflows |
| Change | Limited to what the vendor offers | Anything, at the cost of building it |
| Exit | Data export and migration if you switch | You own the code and data |
Look at a three-to-five-year horizon and include the hidden items: training, data migration, integration, admin time, and the cost of the workarounds people will invent.
Risks on both sides
Buying: vendor lock-in, price increases, features you need never arriving, limits on data access and export, and customisations that break on upgrade.
Building: you own maintenance, security and support for as long as the software lives. Projects can overrun without good discovery and delivery discipline, and knowledge can leave with the team that built it unless code, documentation and ownership are in good order.
Five questions to decide
- Is this process part of how we win? If yes, lean towards building.
- Does a product fit at least most of the workflow without workarounds? If yes, lean towards buying.
- How much of the value comes from connecting systems? If most of it, plan an integration or custom layer either way.
- What will each option cost over five years at our expected scale?
- Who will own it afterwards? Make sure there is an answer before you start.
The usual answer: buy the commodity, build the difference
Most organisations get the best result from a mix: proven products for finance, HR and other standard functions, and custom software for the customer experience, operations or data flows that make them distinct, all connected through APIs so data is entered once.
Whichever way you lean, start with a short discovery phase, and if you build, choose a partner carefully (here is a checklist). Mapping the real workflow and its integrations usually makes the build-or-buy decision obvious, and protects you from paying for the wrong one.