Use a ready-made tool or build something custom?
Use a ready-made tool when it can do most of what you need through its settings and integrations. Build something custom when your process is unusual, the tool cannot be adapted or connected to what you already use, or you need to own and change the result. Before deciding, trial the ready-made option on the single hardest task you have, because one real test shows more than a feature list.
Start with the need, not the product
Write down the job in one sentence, for example "make sure every new enquiry gets a reply within a day and nothing is forgotten". Then list the few things the solution must do for that job. Anything beyond that list is a preference, and preferences are the usual reason a perfectly good tool gets rejected.
Also write down what the work costs you today in hours or mistakes. Without that, any price looks either too high or too low.
When a ready-made tool is usually enough
The GOV.UK guidance on defining a purchasing strategy is written for public sector teams, but its questions transfer well to a small business. It suggests buying may suit you when there is a commercially available way to meet most of your needs, when the supplier can configure settings or features to fit, when you do not need a high level of customisation, and when you can support what you buy.
It also warns that even small modifications to off-the-shelf software can remove most of its benefits, and suggests configuring settings instead so that product support continues when new versions are released. For a small team the lesson is practical: if you find yourself bending a tool in ways it was not meant to bend, that is a signal to look again.
When custom work starts to make sense
The same guidance lists reasons to build all or part of a solution. They include a need that is unique or rare, a market where few suppliers can meet it, an inability to scale, adapt or integrate commercial products to meet core needs, a need to own the technology so you can change it, and having the capability and resources to manage the project.
The last point deserves attention. Custom software is not finished when it is delivered. Someone has to keep it running, fix it and change it, so decide who that will be before you commission it.
Run a one-task trial
The GOV.UK guidance suggests that when you trial a product you try to solve one small but hard problem, test how it works with your current products, and check the user experience and accessibility. Copy that approach. Pick the awkward case rather than the easy one, run it for real with sample records, and see where the tool strains.
- Does it handle your hardest realistic case without a workaround?
- Can it connect to the tools you already use, such as your calendar, email or accounting system?
- Can the people who will use it do the task without help?
- Can you export your data if you leave?
- What will it cost across a year, including extra users and add-ons?
A hypothetical example
Imagine a three person cleaning company that wants customers to book visits online. A ready-made booking tool covers service types, time slots and reminders through settings, and connects to a calendar. The company trials it with its hardest case, a recurring visit with two cleaners. It works. A custom build would add cost and upkeep without adding anything the company needs. Now imagine instead that pricing depends on a formula only this company uses, and the quote must feed a supplier system no tool connects to. The trial fails on exactly that case, and a small custom piece around the ready-made booking tool becomes a sensible conversation. This example is hypothetical.
Decide and write it down
Record the decision, the reasons and what would make you revisit it, for instance "if we pass 200 bookings a month" or "if the tool drops calendar sync". A short note like this saves the argument later and helps whoever takes over.