Start from buying
We build bespoke software for a living, so it may seem odd to begin here: most businesses should buy most of their software, and the default answer to any new need should be to look for a product first.
Off-the-shelf software has real advantages that a bespoke build cannot match. It exists today. Thousands of other businesses have already found its bugs. Its price is spread across all of them, so you pay a subscription rather than the cost of building it. It comes with updates, documentation and, usually, people you can hire who already know how to use it.
Accounting, payroll, email, file storage, video calls, a CRM for a sales team that sells in the ordinary way — these are solved problems. Paying someone to solve them again gets you a worse version of something you could have had for a monthly fee.
When buying stops working
The case for bespoke starts where a product's assumptions stop matching how you work. The signs are fairly consistent:
- The spreadsheet is still open next to it. The product handles most of the job, and the rest is done by hand, in Excel, by the one person who understands the workaround.
- You are paying for three products to do one job. Each holds part of the picture, and someone spends their week copying between them.
- The process is your advantage. The way you estimate, schedule or serve customers is the reason you win work. A generic tool makes you work like everyone else who bought it.
- Per-seat pricing has turned against you. A product that was cheap for five users is not cheap for sixty, especially if most of them only need one screen.
- It is being retired, or you have outgrown it. Either the vendor has stopped developing it or your business has moved past what it was built for.
One of those on its own is rarely enough. Several together usually are.
Build where the process is the product
The clearest case for building is when the software would encode the thing you are actually good at.
A construction and M&E group we work with had its estimating held together with spreadsheets and an ageing desktop tool. Buying an estimating product was the obvious move and the wrong one, because estimating is where the group's expertise lives — a generic tool would have flattened the thing that made them competitive. So that got built. Their software suite case study has the detail.
The inverse matters just as much. Nobody wins a contract on the strength of their payroll software. If a function is the same in your business as in everyone else's, it is a commodity, and commodities should be bought.
A useful question for each part of the operation: would a competitor be better off if they had your version of this? If yes, it may be worth owning. If no, buy it.
The hybrid answer
In practice the answer is often neither pure option. It is an off-the-shelf product for the commodity parts, plus a modest amount of bespoke work that joins them up or covers the gap.
That can look like:
- Keeping your accounting package, and building the small system that raises invoices in it automatically from completed jobs
- Keeping the CRM, and building a customer portal that reads from it so clients stop ringing for updates
- Connecting a payment provider to your own records so nobody reconciles by hand at month end
This is usually cheaper than either extreme. You keep the maintained, well-supported product where it fits, and you pay for custom work only where your business is genuinely different. Integrations covers that kind of work — most of which is in handling what happens when one of the systems misbehaves.
What bespoke really costs you
It would be dishonest to present bespoke as all upside. You are taking on things a vendor would otherwise carry.
- Up-front cost. A build costs more on day one than a subscription does. The cost guide has real figures.
- Time. The product exists now. The bespoke system exists when it is built.
- Ongoing responsibility. Hosting, security updates and changes are yours to arrange. A good supplier makes that straightforward; it does not make it go away.
- Supplier risk. If the code and the accounts are not in your name, you depend on the people who built it. That one is avoidable, and it is worth insisting on — see who owns the code.
Against that, what you get is software shaped around your operation, with no per-seat fees, no roadmap set by someone else, and no risk of a vendor retiring the product underneath you. An accountancy practice we build for replaced an end-of-life system that it had simply grown past; the Fortium case study describes what that looked like.
A short test
If you are still unsure, go through these in order and stop at the first "no":
- Have you looked properly for a product that does this, including asking people in your industry what they use?
- Having looked, is there a real gap — not a preference, a gap that costs time or money every week?
- Does closing it take more than connecting products you already have?
- Is the work in that gap specific to how you operate, rather than something every business in your sector does the same way?
A "no" at step one means go and look. At step two, it means buy. At step three, it means the hybrid: keep the products, and build only the piece that joins them. A "no" at step four usually means the product you need exists and step one deserves another look. Four answers of "yes" is where a proper bespoke system starts to make sense. We will tell you which of those we think you are looking at, including when the answer is to buy something.