Quick checklist
- Have you tried configuring an existing tool properly?
- Is the mismatch in your process, or just the setup?
- Would three competitors solve this the same way?
- Who maintains it in three years?
- What happens to the business if it stops working?
We build custom software. We also talk people out of it fairly regularly, and this article is mostly about why.
The decision usually gets made backwards. Someone tries a tool, it doesn’t fit, they conclude they’re unusual, and they start pricing a build. Sometimes that’s right. More often the tool was never set up properly for how they work, and a custom build would have replaced a bad configuration with an expensive one.
Start by separating two different problems
There are two very different reasons off-the-shelf software doesn’t fit, and they have opposite answers.
The tool is wrong for the job. You’re using a bookings tool for stock control because it was already there. No amount of configuration fixes this. Get the right category of tool.
The tool is right but badly set up. This is far more common. The software could do what you need, but nobody configured the fields, the stages, or the automation to match your actual process, so everyone works around it. The answer here is a few hours of setup, not a build.
Before anything else, it’s worth being honest about which one you have. The second is much cheaper to fix, and much more common than people expect.
The question that settles most cases
If three of your competitors looked at this problem, would they solve it the same way?
If yes, buy something. Quoting, invoicing, bookings, basic CRM, payroll, accounting — these are solved problems, solved well, by companies who have spent years on the edge cases you haven’t thought of yet. Building your own version means paying to rediscover those edge cases personally.
If no — if the way you do this thing is genuinely unusual, and the unusualness is why customers choose you — that’s a real candidate for building.
The trap is that almost everyone believes their business is unusual. Being genuinely different in a way that software should encode is rarer than it feels from the inside.
What custom actually costs
The build is the part people price. It’s not the part that matters most.
Custom software has to be hosted, updated, backed up, and occasionally fixed when something it depends on changes. It needs someone who understands it. When your business changes — and it will — the software doesn’t change with it unless someone changes it.
None of that is a reason not to build. It’s a reason to be clear that you’re taking on an ongoing commitment rather than making a purchase. Any developer who doesn’t raise this with you before quoting is not doing you a favour.
When building genuinely is the right call
It tends to be worth it when:
Your process is the product. The specific way you handle jobs, or route work, or price things, is a genuine reason people use you. Encoding that properly is an investment in the thing that makes money.
You’re paying for five tools to do one job. Sometimes the subscriptions plus the manual joining-up between them already cost more per year than building the thing once would.
The workaround has become the job. When someone’s role is substantially “moving information between systems”, you’re already paying for custom software — you’re just paying a person to be it, and they can’t work weekends.
Nothing in the category exists. Occasionally true, particularly in niche trades and specialised services. Worth verifying properly first; “I couldn’t find one” and “one doesn’t exist” are different findings.
A sensible middle path
The choice isn’t actually binary, which is the bit most people miss.
The most common good outcome we see is a proven tool doing the heavy lifting, with a small custom piece handling the part that’s genuinely specific to you — and the two connected so nothing gets retyped. You get the reliability of software other people maintain, and the fit of something built for you, without paying to rebuild invoicing from scratch.
That’s usually the cheapest thing that actually works, and it’s rarely what people ask for when they first get in touch.
Before you get a quote from anyone
Write down what happens now, step by step, including the workarounds. Then note which steps are genuinely specific to your business and which are just normal business admin.
Almost always, the normal parts should be bought and the specific parts should be built — and having that written down makes any conversation with a developer dramatically more useful, including with us.
If you want a hand working out where the line falls, that’s what a conversation about business systems is for. We’ll tell you if the answer is “configure what you’ve got” — that happens often enough that it’s worth asking.
Bottom line
Build when the way you work is genuinely a difference worth keeping. Buy when you're doing a normal thing in a normal way — which is most of the time, and there's nothing wrong with that.
Want a hand with this?
Tell us what you're trying to sort out and we'll give you practical, plain-English advice before you spend money.
