Build vs buy: a framework for the decision, not a rule of thumb

The default should be buy

For most business software, the right default is to buy, not build. Off-the-shelf tools benefit from being used, tested and improved by thousands of other businesses; a bespoke build starts from zero and carries all of its own maintenance burden indefinitely. That is not a compromise — it is usually the better engineering decision, not just the cheaper one.

Where the calculus actually flips

Building makes sense when the process you are supporting is a genuine point of competitive difference — something that works differently at your business than at a competitor’s, and where forcing that process into an off-the-shelf tool’s shape would mean losing the difference that makes it valuable.

It also makes sense when you would otherwise need three or four separate tools stitched together with manual workarounds to cover a single workflow, and the integration cost and fragility of that stitching starts to exceed the cost of a single purpose-built system.

Ask what you are actually protecting

The useful question is not "can we build this" — most competent teams can build most things given enough time. It is "does this process need to be ours to control, or would a good off-the-shelf tool do the job while we spend that engineering time on something that actually differentiates the business." Answered honestly, that question resolves the decision far more often than a feature comparison spreadsheet does.