The instinct in most businesses is to build, because off-the-shelf products never quite fit. The instinct is usually wrong, and the reasons why are worth understanding before you commit.
Start by assuming you will buy
Software companies have spent years and considerable money solving your problem for thousands of customers. They have found the edge cases you have not thought of. They handle the regulatory changes, the security patching and the browser updates.
Your bespoke system will not have any of that, and everything it lacks becomes your responsibility.
So the question is not "would custom be nicer" — it always would. The question is whether the gap between what you can buy and what you need is worth the difference in cost and risk.
The three cases where building is right
1. The process is your advantage
If how you do something is genuinely why customers choose you, forcing it into a generic product erodes the thing you compete on.
Be honest here. Most businesses believe their process is unique and most are describing an ordinary process with local vocabulary. The test is whether a customer would notice the difference.
2. The workarounds have a measurable cost
Available products exist, but using one would mean two people spending a day a week reconciling exports, or a step your team performs in a spreadsheet outside the system.
Price that. Two days a week of skilled time is a real annual number, and it frequently justifies a build inside three years.
3. The software is the product
If you sell access to it, or it is a differentiating part of what you sell, then building is not a cost decision at all.
The three cases where building goes wrong
"Nothing on the market does exactly what we want"
Usually true and usually not sufficient. The right question is what the gap costs, not whether one exists.
"It will be cheaper than the subscription"
Compare properly. Subscription cost against build cost plus hosting plus maintenance plus the development that will follow launch plus the internal time to specify and test it.
Custom software also has an unpriced liability: if the person who built it becomes unavailable, somebody must learn it. Subscriptions do not have that problem.
"We want full control"
Control means responsibility. You control the roadmap and you also own every security update, every browser change and every regulatory adjustment forever.
The option most businesses skip
Buy the platform, build the difference.
Use an established product for the substantial, well-understood parts — accounting, email, storage, payments — and build only the piece that is genuinely yours, connected to the rest.
A bespoke quoting tool that pushes accepted quotes into your existing accounting package is a fraction of the cost of a bespoke system that also does accounting, and infinitely less risky. That connective work is covered in how integrations actually work.
The best answer is usually not build or buy. It is buy the boring parts and build the two per cent that is actually yours.
Comparing the real cost
Take five years and be thorough on both sides.
Buying: subscription at today's user count, then at your projected count; implementation and configuration; data migration; training; integration work; annual price rises, which are routine; and the cost of any workaround you will still be doing.
Building: discovery and specification; build; your own team's time, which is real; hosting and monitoring; maintenance and security updates; continued development after launch; documentation; and the cost of somebody else picking it up if they must.
That last item is where custom projects quietly fail. A system nobody but its author understands is a liability regardless of how well it works.
If you do build, reduce the risk
- Start narrow. The smallest genuinely useful version, in real use, before specifying the rest.
- Use conventional technology. Whatever the widest pool of developers knows. This is not the place for novelty.
- Own the code and the hosting. Written into the agreement — see who owns your code.
- Insist on documentation and tests. They are what lets somebody else take over safely.
- Keep the data portable. If you can export everything in a usable form, you always have an exit.
A shortcut for the decision
Ask what happens if you buy the closest available product and simply live with its limitations for a year.
If the answer is "some irritation", buy it. You will learn a great deal about your actual requirements from using something real, and that knowledge makes a later build far cheaper and far more likely to be right.
If the answer is "we could not operate", you have your justification.
Our consultancy team works through this with UK businesses, including when the recommendation is to subscribe to something and not employ us to build anything. Start a conversation.
