Every growing business reaches the same fork. The way you work has outgrown the tools you started with, and someone has to decide: buy a ready-made product, or have something built? Vendors of both will tell you their answer is obvious. It rarely is. The right choice depends on what makes your business different, how much change you can absorb, and what you can afford to own for the next five years, not only what you can afford to buy this year.
This article gives you a practical way to make that decision without guessing.
First, be precise about the options
"Custom versus off-the-shelf" is really a spectrum with at least four points:
- Off-the-shelf, used as is. A standard product (accounting, HR, CRM, inventory) adopted with its own workflows. You change your process to fit the software.
- Off-the-shelf, configured. The same product, set up with your fields, approval rules and reports, within what the vendor allows.
- Off-the-shelf core plus custom extensions. A standard system for the common work, with purpose-built modules or integrations for the parts that are specific to you.
- Fully custom. A system designed and built around your process, which you own and maintain.
Most good answers sit at points 2 or 3. The mistake is treating the decision as all or nothing.
The core question: is this process a differentiator?
Split your operations into two groups.
- Commodity processes are done in broadly the same way by every business: payroll, general ledger, leave management, basic invoicing. There is little advantage in doing them differently, and plenty of risk.
- Differentiating processes are where your business wins or loses: how you cost and quote an order, how you plan a production line, how you track material through a floor, how you serve a key customer.
As a starting rule: buy for commodity processes, consider building for differentiating ones. If you force a differentiating process into a generic product, you either lose the advantage or you end up with spreadsheets around the product to make up the gap.
Buy what everyone does the same way. Build only where doing it your way is the reason customers choose you.
A decision framework in six questions
Score each question honestly. The pattern of answers matters more than any single one.
1. How well does the best available product fit?
Take your three most important workflows and test them, step by step, in a trial or a scripted demo using your own data. Do not accept a generic presentation. Note every place where the product needs a workaround. A few small gaps are normal. Gaps in your core workflow are a warning.
2. How often does your process change?
If buyer requirements, product mix or regulations change your workflows several times a year, you need software you can change on your own timetable. With a packaged product, you wait for the vendor's roadmap. With custom software, you need a partner, or a team, ready to make changes.
3. What must it connect to?
List every system the new software must exchange data with: accounts, banks, buyer portals, machines, existing databases. Check whether the product has proper, documented APIs for each. Integration is often where the real cost hides on both sides.
4. What is the five-year cost, not the first-year cost?
Compare total cost of ownership over a realistic period:
- Off-the-shelf: licences per user per year, implementation, customisation, training, annual price increases, add-on modules and the cost of workarounds.
- Custom: discovery and build, hosting, support and maintenance, and an allowance for enhancements each year.
Subscription costs grow with headcount. Custom costs are front-loaded. Neither is automatically cheaper; work out the numbers for your own size and growth plan.
5. Who will own it?
Custom software needs an owner inside the business who understands the process and can set priorities, and a technical partner who will still be there in three years. If you have neither, a packaged product with a solid vendor may be safer, even if the fit is weaker.
6. What happens to your data if you leave?
Ask any vendor: can we export all of our data, in a usable format, at any time? For custom work, make sure the contract gives you the source code, the database and the documentation. Lock-in is a real cost, even if it does not appear on the invoice.
Reading the results
- Good fit, stable process, few integrations: buy and configure. Do not over-engineer.
- Good fit for most work, but one or two critical gaps: buy the core and build focused extensions or integrations for the gaps.
- Poor fit in the core workflow, frequent change, clear differentiation: build, in phases, starting with the part that hurts most.
- Poor fit, but no internal owner and no budget for ongoing support: pause. Fix ownership first, or a custom build will drift.
Warning signs on either path
When buying
- The vendor says "yes, it can do that" but cannot show it with your data.
- Key features are "on the roadmap".
- Customisation requires the vendor's own consultants for every small change.
- Your team is already planning the spreadsheets they will keep "on the side".
When building
- The proposal has a fixed price but no discovery phase.
- Nobody has asked to see your current process in person.
- There is no plan for regular demos, testing or handover.
- Ownership of code and data is unclear in the contract.
A sensible way to start
Whatever you lean towards, begin with a short, paid discovery: map the processes, list the integrations, identify the commodity and differentiating parts, and test the leading products against your real workflows. The output should be a recommendation you could take to any supplier, not a sales document for one. A few weeks spent here routinely saves months later.
Where RAED fits
We build custom software, but we often recommend a packaged product, or a packaged core with targeted integrations, when that is the better fit. Our discovery work is designed to give you a clear, supplier-neutral answer before any build begins.
