The short version
- Buy off the shelf when your process is ordinary. Build when the process is the thing that makes you money.
- The real cost of off-the-shelf software is rarely the licence. It is the workarounds, the exports and the person who reconciles two systems every Friday.
- Bespoke is not all or nothing. The best answer is often a small custom layer joining good off-the-shelf tools together.
- If your team maintains a spreadsheet alongside the software they were given, that spreadsheet is your specification.
Most businesses arrive at this question the same way. Something has been outgrown. The software that was fine at ten people is creaking at forty, or the workflow the business actually uses has drifted so far from what the system supports that everyone has invented their own way round it.
The instinct is to look for better off-the-shelf software. Sometimes that is right. Often it means changing the pain rather than removing it.
When off the shelf is the right answer
Buy, and do not think twice about it, when the process is genuinely standard.
- Accounting. Your bookkeeping is not a competitive advantage. Use a mainstream package and move on.
- Email, documents and calendars. Solved problems.
- Payroll and HR. Heavily regulated, frequently changing, and somebody else is paid to keep up with it.
- Ecommerce, for a conventional catalogue. The platforms are mature and building your own is rarely justified.
- Anything a regulator inspects. Let the vendor carry the compliance burden.
The test is simple. If a competitor doing this task slightly better than you would not change your position in the market, buy it.
When building is the right answer
Build when the process is the business, or when the cost of not building has quietly become larger than the cost of building.
Your process is genuinely unusual
Not “we do it a bit differently”, which everyone says. Genuinely unusual, as in your pricing logic, your workflow or your product configuration has no equivalent in the market. Forcing that into generic software means encoding your advantage as a workaround.
You are paying people to be integration middleware
Somebody exports from one system, reformats it and imports it into another. Somebody rekeys orders. Somebody reconciles two lists every week. That is a salary being spent on a problem software solves permanently, and it is worth pricing.
The licence cost scales badly
Per-seat pricing is comfortable at ten users and painful at a hundred. If you can see the point where the annual licence approaches the cost of building, and you expect to keep growing, the calculation changes.
You need it to talk to everything else
Off-the-shelf products integrate on their terms, not yours. When the value is in joining several systems into one coherent picture, a custom layer is usually the only thing that can do it.
Find the spreadsheets your team maintains alongside the official system. Ask why each one exists. That collection of workarounds is the most accurate specification you will ever get, and it was written by the people who do the job.
The middle path most businesses actually need
The buy-versus-build framing is misleading, because the answer is usually both.
Keep the mainstream tools that work: the accounts package, the email platform, the ecommerce front end. Then build a thin custom layer that does the specific thing your business needs, and connects them so information is entered once and appears everywhere.
This is far cheaper than replacing everything, and it fails more gracefully. If the custom layer needs replacing in five years, your accounts history is not tangled up in it. We do a great deal of this kind of integration work, and it is frequently the highest-return software a business buys.
Not sure whether to buy or build? We will map your current systems, find where the manual work is, and tell you honestly which parts are worth building and which are not. Sometimes the answer is that you should buy something and we will say so.
What building actually commits you to
Bespoke software is not a purchase either. Be clear about the commitment before you start.
- Maintenance. Dependencies, security patches, browser and platform changes. Budget for it annually or the system will decay.
- Change. Your business will change and the software must follow. That is a feature of building, not a defect, but it needs a budget.
- Documentation and handover. Insist on it. Software only one person understands is a risk, whether that person works for you or for your developer.
- Ownership. Get it in writing that you own the code and have access to the repository, from day one.
Ask any prospective developer what happens if you stop working with them. The answer tells you a great deal about how the relationship will feel in three years.
How to reduce the risk
Most bespoke projects that go wrong go wrong for the same three reasons: the scope was never really agreed, the users were not involved, and the first release was too big.
- Start with the worst process, not the biggest. Pick the thing that causes the most daily friction. It is easier to justify, easier to scope, and it builds confidence.
- Ship something small early. Working software in front of real users in weeks, not a specification signed off in months. Every assumption in a specification is a guess until somebody uses it.
- Involve the people who do the job. Not just their manager. The person who has been keeping the workaround spreadsheet knows more about your process than anyone in the room.
- Keep the data yours and portable. Standard database, documented structure, exports that work. Whatever happens later, you keep what matters.
Common questions
Is bespoke software always more expensive?
Up front, usually. Over five to seven years, often not, once you account for licences, workarounds and staff time spent moving data between systems. Compare total cost over a realistic period rather than the initial invoice.
What if we build it and then outgrow it?
Well built software is extended rather than replaced. That depends on how it was built, which is why architecture and documentation are worth paying for even though they are invisible on a demo.
Can we start with off the shelf and build later?
Yes, and it is often sensible. Use a standard product to learn what you actually need, then build once the requirements are proven rather than imagined. Just make sure you can get your data out cleanly when the time comes.
Who owns the code we pay for?
You should. Make it explicit in the contract before work starts. If a developer resists that conversation, treat it as information. Our approach to bespoke development and CRM work is set out on those pages.
