Build or buy? A practical way to decide

We build custom software, so you might expect the argument that follows to be "build". It is not. Most businesses that ask us for custom software should buy something instead, and we tell them so.

Buying is usually cheaper, always faster, and the maintenance is someone else's problem. A product used by thousands of businesses has had its edge cases found by those businesses, not by you at your own expense. Starting from the assumption that you need something built is how budgets disappear.

But sometimes buying is the wrong answer, and the cost of that mistake is just as real. Here is how to tell the difference.

Five situations where building genuinely pays

1. The process that makes you money is the one nothing supports

Every business has a handful of processes that are simply how the industry works — and one or two that are genuinely theirs. The way you price a complex job, or schedule around a constraint your competitors do not have. If a package cannot support that, adopting it means giving up the thing you are better at. That is not a saving.

The test: if you changed this process to match the software, would you still be better than your competitors? If no, build.

2. You are paying people to move data between systems

Three subscriptions, and a person exporting from one and importing into another every week. That person's time is a recurring cost, and every manual transfer is an opportunity for error that surfaces later as a wrong invoice.

Add the annual cost of the subscriptions and the salary time. Frequently it exceeds the cost of building the thing once.

3. Licence costs scale with your success

Per-user pricing is reasonable at ten users and painful at two hundred. If growth makes your software bill grow proportionally forever, there is a crossover point where owning is cheaper. Work out where it is — it is often nearer than expected.

4. A spreadsheet has quietly become the real system

You bought the software, and the team also keeps a spreadsheet, because the software does not do the thing they actually need. The spreadsheet has no access control, no audit trail, no backup, and one person understands it.

That spreadsheet is a specification. It tells you precisely what is missing, and it is a business risk in its current form.

5. Nothing will integrate what you need integrated

Older systems, industry-specific tools, a supplier's portal, hardware on the floor. Integration is often the entire job, and no product will do it for your particular combination.

The reasons that are not good enough

Equally worth naming:

• "Off-the-shelf has features we don't need." Unused features cost nothing. Building to avoid them costs a great deal.
• "We want it to look like our brand." Configuration and theming usually solve this.
• "We'll own an asset we can sell later." Almost never true. Software built for one business rarely transfers, and maintaining a product is a different business from using one.
• "The subscription feels expensive." Compare it to the fully loaded cost of building and maintaining for five years — including the developer you will need when something breaks.

The questions to ask before committing

1. What happens if we do nothing for a year? If the answer is "not much", the problem is not urgent enough to justify a build.
2. Have we genuinely tried to buy? Not a web search — a proper shortlist, demos with your real process, and questions about the specific thing you need.
3. What is the smallest version that would help? Most projects fail because the first release tried to be complete. What is the one workflow that, automated, would make a visible difference next month?
4. Who maintains it in three years? Software is not finished at launch. If there is no honest answer, the risk is real — and it is an argument for a lean, conventional build rather than a clever one.
5. Can it be phased? Building the core and integrating a bought product for the rest is often the right answer, and almost nobody considers it.

How to lower the risk

If you decide to build, the biggest risk is not technical failure. It is building the wrong thing carefully.

Which is why a proper discovery — mapping the process as it actually runs, with the people who run it, before any code — is worth paying for on its own. A good discovery sometimes concludes that you should buy after all. That conclusion costs a fraction of a percent of what building the wrong system would have.

Then build the smallest genuinely useful version, put it in front of real users, and grow it from there. Long projects fail not because the team was weak, but because nobody found out the requirements were wrong until it was expensive to discover.