Should you buy existing software or build a custom tool?

Write down the work first

Before you look at any product, describe what happens today. Who does the work, what steps do they repeat, how often, and which tools and information do they use along the way? Then mark the moments where it goes wrong: details typed in twice, messages chased by hand, a spreadsheet only one person understands.

Split what you need into two lists. Must-haves are the things the solution has to do for the work to get done. Nice-to-haves are preferences. Keep the first list short. It is what you will judge every option against, and it stops a long feature list distracting you from the job.

Here is a made-up example. A small clinic takes bookings by phone and direct message, records deposits in a spreadsheet and sends reminders by hand. Its must-haves might be online booking, a deposit taken at checkout and automatic reminders. A booking page in the clinic’s own branding is a nice-to-have. Written down like that, the clinic can test any booking product in an afternoon.

Give existing software a fair trial

Most common business tasks already have good software built for them, and a product that handles your must-haves is usually the quickest and cheapest way to get the work done. Someone else looks after the hosting, security and updates, and you can start this week.

Trial it with a real piece of your work, not the sample data in a demo. While you do, check:

• The must-haves. Does it do each one without a workaround you would have to repeat every day?
• The people. Can the people who will use it every day actually find their way around it?
• Configuration and integrations. Which of your needs can be met by changing settings, and which integrations exist today rather than on a roadmap?
• Your data. Can you export everything you put in, in a format another tool could read?
• The price as you grow. Is it charged per user, per booking, per transaction or as commission, and what will it cost in two or three years?

A product that does the essentials well and the rest adequately is a good result. A small compromise is often cheaper than building something new.

When a custom tool is worth investigating

A tool built around your work starts to make sense when a real gap is left after a fair trial. Some signs:

• The gap is in the core of the job, not at the edges.
• You are paying for it every week in workarounds, re-typing or chasing.
• The information you need is split across tools that don’t share it.
• The pricing model works against you, for example a commission that grows with every customer.
• You need control over how the process works or where the data lives.
• The way you do the work is part of what makes your business different.

If the gap is small, rare or a matter of taste, building is usually not worth it. Custom software is not a one-off purchase. It is something you own and have to look after.

It is also rarely all or nothing. You might change some settings, connect two tools you already use, or build one small piece that fills the gap and leave everything that works alone.

Compare the full commitment

The first price tells you little. Over a few years, compare what each option asks of you.

For an existing product: the subscription at your expected size, likely price changes, add-ons you will need, and the cost of moving your data out if you leave.

For a custom tool: the build itself, hosting, third-party services such as payments and email, and ongoing maintenance, security updates and fixes. Ask who will do that work and how quickly.

Some questions apply either way:

• Personal data. If a provider or developer handles personal data for you, UK GDPR requires a written contract that covers security and what happens to the data when the arrangement ends. The ICO sets out what the contract must include.
• Security. Ask whether you can require two-factor sign-in for everyone, where your data is stored and how it is protected. With hosted software you are still responsible for setting your own account up well. The NCSC’s guide to using SaaS securely lists the questions worth asking.
• The way out. What happens if the vendor closes, changes direction or raises prices, or the developer is no longer available? For a custom tool, check who owns the code, whether the hosting and accounts are in your name, and whether there is enough documentation for someone else to take it on.

An example from my own work

ProfileBooking is a booking system I am building. Marketplace booking tools are quick to start with, but they can take commission on new clients, use generic booking flows and put someone else’s branding in front of a business’s customers.

Building it showed me how much of booking is the same everywhere: availability, customer details, deposits, reminders and an admin view. That shared core is why good off-the-shelf booking tools exist. The parts that differ, such as the questions asked at booking, the deposit rules and the branding, are what ProfileBooking turns into configuration.

The lesson for anyone deciding: a custom tool earns its place only where those differences matter to the business. If a standard booking app does the job, use it. ProfileBooking is a working project with a demonstration deployment. It has not yet been used by a paying customer, and its payment, reminder and operator workflows still need launch checks.

A sensible next step

1. Write a one-page description of the work, with your must-haves and nice-to-haves.
2. Trial two or three existing products against the must-haves, using real work.
3. Write down any gap that remains and what it costs you each week.
4. Ask every vendor or developer about full costs, data, security and the way out.
5. Then decide: buy, combine, or build the part that is missing.

If you have done that and a gap is still there, I’m happy to talk it through. Email me with what you have in mind. You don’t need to know the technical details.