Custom software vs off-the-shelf: how to decide

Every growing business hits this question eventually. The tools you started with have stopped fitting, and you are choosing between buying another product and having something built. Here is how I would work it out, including the cases where buying is clearly the right answer and you should not be paying a developer at all.

By Rashid, founder of Layerform System Ltd, based in London.

It is not a contest between two options

Most of the advice on this subject is written by people who sell one of the two, which is why it reads like a contest. It is not. Almost every business I have worked with ends up running both: bought products for the things everybody does the same way, and something bespoke for the handful of things they do differently.

So the useful question is not "custom or off-the-shelf". It is "which parts of this are standard, and which parts are actually us". Get that split right and the rest of the decision mostly makes itself.

Buy the product when the process is standard

There is a large category of work where somebody else has already solved the problem properly, they have been doing it for a decade, and no version I build is going to beat theirs. Buy the product when:

• The function is a commodity. Payroll, bookkeeping, email, calendars, video calls, file storage, e-signatures. These are solved. Building your own is a hobby, not an investment.
• The rules are set by someone else. If HMRC, a regulator or an industry body dictates the format, a product with a compliance team behind it is doing work you would otherwise have to keep doing forever.
• You would only use a fraction of what you built. If the honest scope is one screen and a report, a product with a cheap tier may cover it entirely.
• The product's way of working is genuinely better than yours. This happens, and it is worth being honest when it does. Sometimes the right answer is to change the process rather than encode the current one in software.
• You need it running this week. Nothing bespoke is live this afternoon. If the pain is urgent and short-lived, buy something.

Build when the process is the thing you are good at

The opposite case is narrower, but it matters more, because this is usually where the money is. Building is the right call when:

• Your team has already built it, out of spreadsheets. This is the clearest signal there is. A spreadsheet that half the company depends on, that one person maintains, that nobody dares change, is already custom software. It is just custom software with no backups, no permissions and no audit trail.
• The product almost fits, and the gap is manual work. If someone on your team spends part of every day copying information out of one system and into another, you are already paying for a custom build. You are paying for it in salary, every month, and getting no asset at the end.
• The way you work is why clients choose you. If a product would force you to work like everyone else, it is quietly removing the reason people pay you.
• You are paying for four tools to do one job. Per-seat licences on several overlapping products, none of which talk to each other, is a common and expensive place to end up.
• You need a record nobody can quietly edit. Who did what, when, and what the file looked like at the time. Plenty of products cannot give you that, and in regulated work it is not optional.

The costs people forget, on both sides

Both options carry a price that never appears on the quote.

What off-the-shelf really costs. The licence is the visible part. Underneath it sits the per-seat fee that grows as you hire, the annual price rise, the workarounds your team invents to make the product fit, the hours spent re-typing between systems, and the data you cannot easily get back out if you decide to leave. None of that appears in the comparison, and all of it is real.

What custom really costs. Software is not something you buy once. It needs somebody who owns it, it needs maintaining as the tools around it change, and the first version is never the last. There is also key-person risk: if one developer builds it and disappears, you have a problem. Anyone selling you a build who does not mention that is not being straight with you.

The middle answer is usually the right one

In practice, most of the work I do is neither replacement nor rebuild. It is a thin layer that sits over what you already have. Your accounting software, your inbox, your calendars and your existing tools stay exactly where they are, and the new system joins them up, removes the re-typing, and gives everyone one place to look.

That is a much smaller project than "replace everything", it does not drag your team through a migration, and it usually removes most of the pain. Replacing everything at once is how these projects fail.

A test you can run this week, without a developer

Before you speak to anyone, including me, do this. It takes an afternoon and it will tell you most of what you need to know.

1. Write the process down end to end. Every step, in order, including the awkward ones people work around.
2. Mark every step where a person re-types something a system already knows. Those steps are pure waste, and they are where the hours go.
3. Count the tools involved, and mark which pairs of them a human is currently acting as the bridge between.
4. Ask what you would have to change to use a standard product exactly as designed. Write the answer down honestly.
5. Read that last answer back. If it is "nothing important", buy the product. If it is "the thing our clients actually like about us", that part is worth building.

Where I sit on this

I build bespoke software for a living, so you would expect me to say build. I do not, and the reason is practical rather than noble: a system nobody wanted is a system nobody uses, and that becomes my problem as much as yours. If a product on the market does the job, buying it is the right answer and I will say so on the first call.

What I bring to the decision is that I have had to live with it afterwards. Over fifteen years building software, and six years running a logistics company where I was the one stuck with whatever tools I had chosen.

Each of those replaced something a person was quietly maintaining by hand. That is not a coincidence. It is the most reliable sign that a business has outgrown what it bought.

Where the line falls in different industries

The split between standard and specific lands in different places depending on the work. Law firms tend to have solid case management products and a gap around document chasing and matter updates. Estate agents usually have a CRM that handles enquiries and nothing that handles the property admin around them. Logistics and delivery firms have telematics and route tools, and almost nothing joining daily deployment, vehicle checks and compliance dates together. In each case the answer tends to be a connecting layer rather than a replacement.