Build or buy: when off-the-shelf software stops being cheaper

Build or buy gets argued as a philosophical position, usually by people who already hold one. It is a cost and control question, and it changes with the specific process under discussion. The same company should buy for some things and build for others, and often the argument is really about which category a particular process belongs in.

Why the usual comparison is wrong

The comparison presented is almost always a monthly subscription against a one-off build quote. Those are not comparable quantities, and the framing flatters the subscription.

Custom software does not stop costing money at launch. Research consistently puts maintenance at 60% to 80% of total lifecycle cost, so the build quote describes roughly a quarter to a third of the commitment. We cover that in what software maintenance really costs.

Bought software has costs that do not appear on the price page either. Configuration and rollout. Integration with everything else you run. Per-seat pricing that grows with headcount whether or not usage grows. Training on someone else’s model of your process. And eventually migration, because vendors get acquired, change direction or reprice.

Put both on a five-year horizon with all of that included and the gap narrows sharply. Sometimes it reverses.

The question that settles most cases

Is this process how you compete, or is it overhead you happen to have?

Payroll is not a competitive advantage. Nobody chooses you because of your expense approval workflow. These are solved problems, solved better by companies who do nothing else, and building them means paying to reinvent something you could rent.

But every business has a handful of processes that genuinely are the business. The way you price, schedule, match, route or assemble something, refined over years, that competitors cannot copy easily. If a packaged tool forces you to do that the way everyone else does, you have paid to become average at the one thing you were good at.

Where buying quietly stops being cheaper

Per-seat pricing at scale. Forty users at a modest monthly rate is obviously cheaper than a build. Four hundred users, five years later, often is not. Run the arithmetic at your projected headcount rather than today’s.

Integration tax. A bought tool that does not talk to your other systems generates manual work, or a stream of small integration projects that never appear in the comparison. Three or four such tools and you have built an integration layer by accident, badly.

Configuration that becomes development. Many platforms are configurable to the point of being programmable. If you end up employing specialists to write logic inside someone else’s system, you are building software with worse tools, less portability, and no ownership of the result.

Process distortion. The most expensive and least visible. If the tool cannot do things your way, your way changes. Sometimes that is an improvement. Sometimes you have discarded the reason customers chose you, and nobody wrote it down as a cost.

The answer most companies land on

Not build or buy. Buy the platform, build the thin layer that is genuinely yours.

Run the commodity on established products. Put custom effort into the narrow slice that encodes your advantage, and connect the two properly. You get maintained infrastructure for the boring parts and control where control matters, and the custom surface stays small enough to maintain.

That shape has a requirement attached: the boundary has to be deliberate. A thin layer that grows into a parallel system because nobody decided where it stopped is the worst of both, and it is how most accidental in-house platforms begin.

How to decide without a spreadsheet war

1. Write down the process. Not the feature list. What happens, in order, including the exceptions. Half of build-versus-buy arguments dissolve here, because the process turns out to be ordinary.
2. Trial the best-fitting product against the real process, including the awkward cases. Not a demo. Your data, your edge cases.
3. Cost both over five years. Build plus maintenance at 60% to 80% of lifecycle, against licence plus configuration plus integration plus headcount growth plus a migration allowance.
4. Ask what you lose in each case. Buying: which parts of your process change. Building: what else that money and attention would have funded.

More on scoping a build small enough to be worth it in deciding what to build first, and on what a build really costs in what custom software actually costs.

If you are weighing a platform against a build and want an outside read, describe the process. If the answer is buy something off the shelf, we will tell you.