Buy or build: how to decide your company's software

There is a question that comes up in almost every diagnostic we run: should we buy this or build it?

The honest answer is that it depends. But it does not depend on the budget, it depends on the process. And you can get there in half an hour of conversation, as long as the questions are asked in the right order.

Start with the process, not the tool

The most expensive mistake we see in an SME is not choosing the wrong software. It is choosing software before understanding the process.

When a company starts by comparing tools, it ends up comparing features it does not know it will use, prices it does not know it will pay and integrations it does not know it needs. The conversation becomes about the product when it should be about the operation.

Before looking at any tool, it is worth writing down in plain language what happens today: who does it, with what information, how often, and what goes wrong. If that description fits on half a page, there is almost certainly an off-the-shelf product that solves it. If it runs to three pages full of exceptions, the answer stops being obvious.

When buying is the right call

In most cases it is. And we say so to clients who came to us specifically to build.

The process is the same everywhere

Invoicing, accounting, payroll, document management, email. These are regulated or standardised processes where your company does nothing different from anyone else, and where doing it differently brings no advantage. Building here means paying to reinvent something that already exists, tested by thousands of companies.

Maintenance stops being yours

Bought software comes with legal updates, security patches and support. Built software hands that responsibility to you. For a process that changes by decree once a year, that is a permanent burden not worth taking on.

You need it working this month

A bought tool is running in days. Custom development, even a small piece, is measured in weeks. When the urgency is real, buying now and revisiting in a year is a legitimate decision, not a compromise.

When building pays off

There are situations where buying costs more, and it is rarely the licence price that does it.

The process is what sets you apart

If the way you quote, plan production or serve customers is part of why you win work, bending that shape to fit a generic tool destroys the advantage to save on a licence. It is the one situation where we recommend building without hesitation.

Per-user licensing has stopped adding up

Many platforms charge per user, per month. On a team of five that is irrelevant. In an operation with forty people in the field who only need to record two things a day, the same model becomes the company's largest software line item. It is always worth running the five-year numbers before signing.

You have systems that need to talk to each other

When the problem is not a missing tool but the fact that the three you already have do not communicate, buying a fourth makes it worse. What is missing there is not new software, it is integration.

The middle path is almost always the right one

In practice, few decisions are entirely buy or entirely build.

The pattern we recommend most often is to buy the base and build the difference. The ERP stays the ERP. Accounting stays where it is. And on top of that you build the thin layer that handles what is specific to your operation: the form the field team uses on a phone, the automation that turns an email into a quote, the dashboard that joins data from two systems that never spoke to each other.

That layer is small, it is yours, and it is replaceable. If in three years an off-the-shelf product does the same thing, you throw it away without touching anything else.

The questions we ask before recommending

In a diagnostic it is almost always these five:

• Is this process regulated, or is it yours? If it is regulated, buy it.
• How many exceptions does it have? An off-the-shelf tool handles the normal case well and the exceptions badly.
• How many people will use this, and how heavily? That is what sets the cost model.
• What systems does it have to talk to? That is what tells you whether the problem is a tool or an integration.
• What happens if it does not exist? If the answer is that someone does it by hand in two hours a week, neither option may be worth it.

The mistakes we see most often

Bending the company to the tool

Buying is a decision about software. Changing the process to fit the software is a decision about the company, and it usually gets made by omission, months later, when nobody remembers there was a choice.

Building what already exists

It almost always happens for an understandable reason: the off-the-shelf version did not do one thing. Building everything from scratch to solve that one thing means paying a hundred per cent to fix five.

At enbia, the diagnostic starts with this conversation, not with a proposal. In many cases the recommendation is to buy something we do not sell, and we say so. When building pays off, we build, and the code is yours.