Build, Buy, or Customize? A 6-Question Test

The build-vs-buy debate usually gets settled by whoever argues hardest in the room, not by analysis. That’s how companies end up with software that doesn’t fit — a custom build for something generic, or an off-the-shelf tool forced onto a workflow that needs its own shape. There’s a better way: six questions that, answered honestly, point you to the right call.

The six questions

1. How unique is the workflow? Generic (most businesses do it the same way) points to buy. Highly specific — with industry or company rules — points to build.

2. How much time does it cost weekly? A few minutes argues for buy. Many hours across the team argues for investment.

3. What does one error cost? Trivial points to buy. Severe — lost deals, compliance exposure — raises the value of a system designed for your error modes.

4. How well does off-the-shelf fit? If a proven tool fits cleanly, buy it. If nothing fits and you’re forcing it, that’s a build signal.

5. How does the team treat the generic tools? Adoption means buy works. Workarounds and shadow spreadsheets mean the fit is wrong.

6. What’s the volume? Low and occasional rarely justifies a build. High and growing makes small efficiencies compound.

How to read your answers

Lean toward buy when the workflow is generic, low-volume, and well-served by a proven tool. Lean toward customize — a thin layer on top of off-the-shelf — when a tool gets you most of the way but the gaps cost real time. Lean toward build when the workflow is specific, high-volume, expensive to get wrong, and your team already routes around the generic options.

Build-vs-buy isn’t a one-time religious position. It’s a calculation you re-run per workflow, every couple of years, as your business and the software market both change. (For the deeper framework, see Build vs. Buy: How to Know Which Path Is Right.)