Buy or build: choosing between software you can purchase and software you own

The buy-or-build conversation usually starts as arithmetic. Someone adds up the annual subscription, compares it to a build quote, notices the build is cheaper over three years, and concludes.

That comparison is wrong in a specific way, and the error always points the same direction — toward building.

What the arithmetic leaves out

The subscription price includes things that do not appear in a build quote. Hosting. Security patches. Someone fixing it at two in the morning. Compliance when the rules change. A product team adding features you have not thought of yet. Support when a new employee cannot log in.

When you build, you buy all of that too — you just pay for it in attention rather than invoices, which makes it invisible until it is urgent.

The build is the smaller number. It is almost never the smaller cost.

The question that actually decides it

Not "which is cheaper" but: is this part of how we work genuinely ours?

Some of how a business operates is the same as every other business in its category. Invoicing. Payroll. Email. Storage. Nobody wins by doing these differently, and an off-the-shelf tool encodes years of other people's experience for a monthly fee.

Some of it is not the same. The way you quote, the way you schedule, the sequence your operation runs in — sometimes that is the actual advantage, the reason customers stay. Software that encodes it makes it repeatable. Software that forces it into someone else's shape quietly removes it.

The first category: buy, without agonising. The second: consider building, carefully.

Buy when

The process is standard, even if it does not feel like it. Most processes feel unique from the inside. If a category of product exists for it and thousands of businesses use them, it is standard.

The tool almost fits. Almost is usually good enough, and adapting how you work to a well-designed tool is often an improvement rather than a compromise. "The software does not work the way we do" sometimes means the software encodes a more sensible process than the one you are defending.

You cannot own it properly. Building something nobody has time to maintain produces a system that rots in eighteen months, and rotting software is worse than a subscription you resented.

Build when

People are paid to be glue. Someone exports from one system, reformats it, and imports it into another, every week. That is a clear rule, pure cost, and the highest-return thing to build.

The integration you need does not exist. You have good tools and they will not talk to each other in the way your business requires.

You pay per seat for a fraction you use. Ten users on a platform where you use four of its forty features is a common and expensive shape.

The process is the product. If customers choose you because of how you do something, and no tool supports it, that is the case.

The answer most businesses need

Almost nobody needs to build everything, and almost everybody assumes the choice is all-or-nothing.

Buy the accounting. Buy the email. Buy the storage. Build the one piece that is genuinely yours — the quoting logic, the scheduling rules, the operational data nobody else models — and connect it to the rest.

This keeps the surface you own small, which is what makes owning it affordable. The failure mode of custom software is not that it does not work. It is that it works, and then nobody can afford to keep it working.

Before deciding either way

Write down the process as it actually happens, including the parts people work around. Most buy-or-build arguments are really arguments about a process nobody has agreed on, and no amount of software settles that. The same is true of automation: the tool is the easy part.