Buy or build: how to decide without regretting it in two years

We are a custom software company, so you would expect the answer to be “build”. It is not. Most of what a business runs on should be bought, and a company that builds its own accounting package has made an expensive mistake.

The interesting question is which few things are worth building. This article is the test we apply before quoting, including the cases where we tell a client to buy something instead.

The question that settles most cases

Ask this about the process, not the software:

Is this how we compete, or is this just plumbing?

Payroll is plumbing. So is accounting, email, file storage, and in most companies, HR. Everybody does it roughly the same way, the rules come from outside your business, and doing it better than your competitors wins you nothing. Buy it. Every hour spent building it is an hour not spent on the thing customers pay you for.

But there is usually one process that is genuinely yours — the way you price a complex order, the way you route a delivery, the way you assemble a quote from twelve variables that only your people understand. That process is why customers choose you, and it is the one that no product fits, because products are built for the average and you are not the average.

Build that. Buy the rest.

Where the real costs hide

Both sides of this decision hide costs, and they hide different ones.

Buying hides configuration and compromise. The licence is the visible number. The invisible ones are implementation and configuration, the consultant who knows the system, the annual increases, the integration to everything else you run, and the process changes your team makes to fit the software rather than the other way around. A product that fits 80% of your process sounds excellent until you meet the 20% — which is usually the part that makes you money.

Building hides the years after launch. The build is the visible number. The invisible ones are 15–20% of that per year to keep it alive, the fact that platforms change under you whether or not you are finished, and the risk that the people who understand it leave. Software you build and abandon stops working within about eighteen months. That is not a failure of the build; it is how dependencies work.

Three signals that you should buy

The rules come from outside you. Accounting, tax reporting, payroll. The rules change by law, and somebody else is paid to track that. Building it means you inherit that job forever.

A product exists and people you trust use it happily. Not “a product exists” — that is always true. Ask two companies your size and in your sector what they actually use and what they hate about it. Their complaints tell you more than any feature comparison.

The process is not yours yet. If you are doing something for the first time, buy the cheapest thing that works and learn what you actually need. Build later, when you know. The most expensive custom software is the kind specified by people who have not yet done the job.

Three signals that you should build

You are paying people to be the integration. Someone spends their week retyping between two systems, or exporting from one and importing into another. That person is a running cost with no end date, and they are the cheapest thing in the world to replace.

Your exceptions are the business. “It always works like this, except when…” — if those clauses are what your customers pay for, no product will hold them. Products are built for the rule, and you are selling the exception.

The product’s licence scales with something you plan to grow. Per user, per order, per document. Model it at three times your current volume. If the number stops making sense, you are renting a ceiling.

The answer is usually neither

The framing is a trap. Most of the good decisions we see are a third thing: buy the platform, build the difference.

Keep the ERP. Keep the accounting package. Then build the thin layer that makes them work the way your business actually works — the integration between them, the screen your warehouse team needs that the product does not have, the automation that turns an approved order into an invoice without anyone retyping it.

That layer is small, it is genuinely yours, and it costs a fraction of replacing a platform. It is also most of the work we are asked to do, which is not a coincidence: it is the shape the answer usually takes.

How to run the decision in an afternoon

1. Write the process down
   • Not the software. The process, in steps, including the exceptions.
   • If nobody can write it in one page, that is the finding. Fix that first.
2. Mark each step
   • Plumbing, or how you compete.
3. Price both paths over five years
   • Buying: licence + implementation + annual increases + integration.
   • Building: build + 15–20% a year + the platform changes you cannot avoid.
4. Ask what happens when you want to leave
   • For the product: can you export everything, in a format someone else can read?
   • For the build: is the code and documentation yours, in your repository?

That last question decides more than people expect. Both paths can lock you in, and neither vendor will raise it.

What we tell clients

If the honest answer is “buy it”, we say so, and we lose the project. That is a better outcome than building something you regret in two years, because the second conversation is much harder than the first.

If you are between the two, send us the one-page process description. We will tell you which parts have a product behind them and which do not, and the assessment costs nothing.