Build, buy or configure: how to decide

Most build-versus-buy debates are really about a third option nobody names: buying a product and configuring it so heavily that you have built software, with worse tools and someone else’s upgrade schedule attached.

The three options, honestly described

Buy and adopt. Take the product as it is and change your process to match it. Cheapest to run, fastest to implement, and the option organizations claim to be choosing while doing something else.

Buy and configure. Take the product and shape it. Reasonable within the product’s intended flexibility. Past that point, every configuration is a thing that has to be retested at each upgrade, and a reason the vendor’s support will end a conversation.

Build. Write the software. More expensive up front, and you own it — which is both the cost and the benefit.

Five tests that settle it

Is this process a differentiator? If how you do this is part of why customers choose you, a product designed for the average will make you average at it. If it is not — payroll, general ledger, service desk ticketing — buy, and change to fit.

Does anything on the market actually fit? Not “is there a category”. Have you seen a product do this work, for a business shaped like yours? Many niche processes have a category and no product that fits it.

Are you willing to change how you work? The honest answer determines everything. Buying a product and then rebuilding your old process inside it produces the worst of both options, at the highest cost.

What happens at upgrade? Ask the vendor what a heavily configured deployment costs to upgrade, and ask a reference customer separately. The gap between the two answers is informative.

Who will maintain it in five years? For a build, this is the question that decides it. Software with one author and no documentation is a liability whatever it cost to write. For a bought product, the equivalent question is what happens if the vendor is acquired.

What has changed recently

The cost of building has fallen, substantially. Work that once needed a multi-quarter project now lands in a fraction of that, which moves the line: things that could never justify a business case now can.

That does not mean build more. It means the comparison has moved, and decisions made on the old economics are worth revisiting — particularly where a product was chosen because building was assumed to be out of reach.

The failure mode to avoid

Buying a product because it is “safer”, then spending more on configuration and integration than the build would have cost, and ending with something you cannot upgrade and do not own. It is the most expensive outcome available and it is chosen regularly, because each individual configuration decision looked small.