July 25, 2026
'Build vs. buy' gets treated as a binary choice, but in practice it's a spectrum -- and most teams have never actually mapped where a given internal tool falls on it.
A generic process, like basic task tracking, is well served by an off-the-shelf tool. A workflow specific to how your team actually operates rarely is.
Tools that need frequent adjustment favor something you can change yourself over something that requires a vendor request every time.
A low-stakes internal tool can tolerate an imperfect off-the-shelf fit. A tool tied to revenue or compliance usually can't.
The three questions, with real examples
A basic task list for a small team is generic, low-change, low-stakes -- buy it, and don't spend another minute deliberating. A claims-adjudication workflow tied to a specific compliance requirement is specific, subject to frequent regulatory change, and expensive to get wrong -- that one's worth building, even though it's more work upfront.
Why teams get this backwards
It's common to default to buying for the high-stakes, unique workflow because it feels safer to hand it to an established vendor, and to default to building the generic one because it feels more ambitious. Run through the three questions honestly and the right call is usually the opposite of the instinctive one.
This isn't a one-time decision
Revisit the framework as a workflow matures. Something that started generic enough to buy can become specific enough, six months in, to justify building -- once you know exactly what it needs to do that the off-the-shelf version doesn't.
The honest answer for most teams isn't 'always build' or 'always buy' -- it's knowing which axis matters most for a given tool, and choosing accordingly.