Buy, build or integrate? A framework for custom software decisions

“Just buy something off the shelf” is good advice right up until it isn’t. Whether it’s right for you comes down to one thing: how central the process is to the way you actually run.

The test: is this your edge?

If a process is generic, buy it. Payroll, email, accounting. Someone has already built a better version of those than you ever will, and rolling your own would just be a maintenance bill you signed up for on purpose. The calculation flips when a process is your edge, the thing you do differently and do well. Bend that to fit someone else’s software and you can quietly file off the exact advantage you were trying to protect.

Three options, plainly

Buy when the need is common and the fit is good. It’s the fastest and cheapest path, and the one where you own the least.

Integrate when you’ve already got several decent tools that won’t talk to each other. A lot of the time the smartest move isn’t replacing any of them, it’s wiring up what you already have so the data stops getting re-typed between systems.

Build when the process is core, the off-the-shelf fit is poor, and owning the thing matters. It’s more work up front. In return you own the code and you own the roadmap.

The trap people fall into is assuming buy is always the cheaper option. It often isn’t, once you add up the workarounds, the data someone keys in twice, and the process you quietly reshaped to suit the tool instead of the other way round. Run the numbers over five years and bespoke is sometimes just the cheaper answer.