Build or buy: when a custom tool beats another subscription
Custom is wrong far more often than the people selling it admit. The honest signals that you have outgrown off-the-shelf, and the hidden costs on both sides.
Build or buy: when a custom tool beats another subscription
Every business with more than a few staff eventually has this argument with itself. Another subscription has crept onto the credit card, another login has been issued, and someone in the corner says, “couldn’t we just build something for this?” Most of the time the answer is no. Occasionally the answer is yes, and it’s worth knowing which is which before you sign anything or commission anything.
This isn’t a pitch for custom software. It’s a decision framework you can run in your head, because the honest truth is that custom tools are wrong more often than the people who sell them let on.
Start with the boring answer
Some problems are solved. Accounting is solved. Payroll is solved. Email is solved. Rostering, point of sale, booking calendars for straightforward appointments — solved, solved, solved. These categories have had thousands of businesses and years of refinement poured into them. The software handles tax changes, compliance updates, security patches and edge cases you haven’t thought of yet, and it does it as part of a subscription you didn’t have to think twice about.
If you’re tempted to build your own version of any of these, stop. You are not going to out-engineer a category that mature with a tool built for one business. The cost of getting it slightly wrong — a payroll error, a bungled return, a security hole in something holding customer details — is far higher than the annoyance of paying for software you only half use. Buy the boring stuff. Always.
Where custom starts to make sense
The case for building something of your own shows up in a handful of recognisable situations, not as a general feeling that “there should be an app for this”.
- Your process is genuinely unusual, and the software is fighting you. If you find yourself renaming fields to mean something else, creating workaround statuses, or explaining to every new staff member “we don’t actually use it the way it’s designed”, that’s a sign the tool was built for someone else’s business, not yours.
- You’re paying per seat for a fraction of the product. A lot of software charges per user regardless of how much of it each user touches. If half your team logs in once a week to check one number, you’re funding a platform for a job that’s really one small feature.
- The real process lives in a spreadsheet next to the expensive system. This is the clearest signal of all. If your team maintains a shadow spreadsheet — the one with the actual up-to-date numbers, the one people trust more than the system you pay for — the paid system has already lost. You’re paying twice: once for the software, once for the labour of keeping the spreadsheet in sync.
- You have three tools that don’t talk to each other, and the “integration” is a person. If someone’s job includes retyping information from one system into another, you don’t have a software gap, you have an unpaid interface sitting at a desk. That’s expensive in a way that doesn’t show up on an invoice, and it’s fragile — it breaks the moment that person is on leave.
None of these are about wanting something shiny. They’re about a mismatch between what you actually do and what the software assumes you do.
The hidden costs on both sides
Subscriptions feel cheap individually and expensive collectively. Nobody notices one more tool joining the stack; everybody notices the total a year later. Per-seat pricing punishes growth — the tool gets more expensive exactly as you succeed. And subscription creep is a management problem in its own right: someone has to know what you’re paying for, why, and whether anyone still uses it.
Custom tools have their own hidden costs, and it would be dishonest to pretend otherwise. Something has to be maintained. Something can break, and when it does, you need someone who understands it — which is a real risk if that someone is one person who might not be available. A commercial product has a support line and a roadmap funded by every other customer paying the same subscription; a custom tool has whoever built it, and only whoever built it, unless that’s planned for properly from the start.
| Buying | Building |
|---|---|
| Cost scales with seats and usage | Cost is mostly upfront, then maintenance |
| Fixes and updates come from the vendor | Fixes depend on who built it, and whether they’re still around |
| You adapt your process to the tool | The tool adapts to your process |
| Support exists but queues behind everyone else | Support is whoever you can call, when you can reach them |
A custom tool that nobody can maintain isn’t cheaper than a subscription. It’s a subscription with worse support and a single point of failure, and you’re the one holding it when it breaks on a Friday afternoon.
What changed the maths
Five years ago, custom software meant a proper development project: a scoping phase, a build phase, a testing phase, and a bill that only made sense for a genuinely large operation. That’s no longer the whole story. Building a focused internal tool — a booking system with your actual rules built in, a lightweight CRM that matches how you sell rather than how a generic platform assumes everyone sells, a form that pushes straight into the system you already use — takes a fraction of the time it used to, because a lot of the scaffolding that used to be hand-built now isn’t. That doesn’t make custom free, and it doesn’t make it right for every business. It does mean the size of business for whom “just build it” is a sensible option has grown considerably. A small operator with one genuinely awkward process is now a realistic candidate, where a decade ago they simply weren’t.
Being honest about the failure mode
Anyone whose business is building custom software has a reason to tell you that you need one. Treat that the way you’d treat a locksmith telling you your locks are all wrong — probably worth hearing, definitely worth a second opinion. The honest failure mode of custom tools is scope creep: a tidy tool that solves one real problem slowly grows a dozen extra features nobody asked for, until it’s as bloated and hard to use as the platform it replaced, except now there’s no vendor to complain to. Good custom tools stay small on purpose. If a custom build keeps growing before it’s even shipped, that’s worth pausing on.
The five-minute test: write down the process you actually follow, not the one the software assumes. Now count how many of those steps happen outside the tool you’re paying for — in a spreadsheet, a notebook, someone’s memory, or a string of messages. If it’s more than one or two, you’re already running a custom process. The only question is whether it’s supported, or held together with sticky tape.