Build versus buy: the only test that actually settles it

Every build-or-buy conversation we join has already been running for months. Someone has a vendor quote. Someone else has a spreadsheet showing internal cost. Both are wrong in the same way: they compare the price of the software rather than the consequence of the decision.

There is a single question that settles it faster than any feature matrix: could your closest competitor buy the same license tomorrow and get the same result? If yes, buy it. If no, the difference is the thing you should own.

Why the feature matrix misleads¶

Feature matrices measure coverage, and coverage is the wrong axis. A platform covering 85% of your requirements sounds like a strong result until you notice that the missing 15% is invariably the part that is specific to you, which is to say, the part that is the reason you are competitive.

What follows is predictable. The unmet requirements become workarounds. The workarounds become undocumented process. Within eighteen months the platform is doing 85% of the work and a person is doing the other 15% by hand, on the clock, forever. The license fee was never the real cost.

A better decomposition¶

Rather than deciding at the system level, split the process into three categories and decide each one separately.

• Commodity: payroll, email, general ledger, HR records, expense reports. Everyone does this roughly the same way. Buy it, integrate it, and never think about it again.
• Differentiating: the process that makes your margin, your speed or your service level better than the alternative. Own this. It is the only category where custom software reliably returns its cost.
• Contextual: necessary, specific to you, but not a source of advantage: internal approvals, onboarding checklists, compliance workflow. Buy if something fits well; build cheaply and unambitiously if nothing does.

Most organizations we meet have the allocation inverted. They have built a bespoke expense tool because a director disliked the vendor’s interface, and they are running their genuinely differentiating operation on a platform that constrains it.

Federal buyers are made to work this way by regulation, which is a useful sanity check on the instinct to build. The Federal Acquisition Regulation requires agencies to state requirements in terms of functions to be performed, performance required, or essential physical characteristics, and to write them so as to enable and encourage offerors to supply commercial products. Buy is the default and building is the exception you have to justify. That is roughly the right posture for a commercial buyer too, provided you apply it per category rather than to the whole estate.

The costs both sides forget¶

Buy-side estimates routinely omit implementation and configuration, integration into the surrounding estate, data migration, the internal administrator the platform will require, per-seat costs at your three-year headcount, and the escape cost the day you leave. That last one is the largest and the least discussed.

Build-side estimates routinely omit that software is not finished when it ships. Hosting, dependency upgrades, security patching, on-call, and the ongoing change budget for a system that will be asked to do new things. A reasonable planning figure is 15–25% of the original build cost, annually, forever. If that number makes the case collapse, the case was never there.

Hybrid is usually the answer¶

The most durable architectures we build are rarely all-custom. They buy the commodity, own the differentiator, and invest properly in the seams between them. A client of ours runs a purchased ERP for finance and inventory and a custom system for the scheduling logic that is their actual product. Neither decision would have been right for the whole estate.

That approach makes the integration layer load-bearing, which is precisely why it deserves real engineering rather than a nightly CSV. But it is a far better problem to have than a platform that quietly caps what your business is allowed to become.

How to run the decision in a week¶

1. 1.Write down the process end to end, including every step a person currently performs outside a system.
2. 2.Tag each step commodity, differentiating or contextual, with the operator, not just the executive.
3. 3.For the differentiating steps only, ask whether any product on the market permits the behavior you want, rather than merely storing the data.
4. 4.Price both paths over five years, including escape cost on one side and maintenance on the other.
5. 5.Decide per category, not per system.

We run a version of this in the first week of every discovery, and roughly one inquiry in five ends with us recommending a product we don’t sell. That is not generosity. Building the wrong system is the most expensive thing either of us can do together.