Build or buy: the three cuts that actually matter
Most build-vs-buy frameworks are too abstract to use. Three questions that force a real answer in under an hour.
The worst hour of any engagement is the one where a team debates build-versus-buy using a five-dimensional matrix nobody can defend. Here are three cuts I use instead. They take about twenty minutes and they end the argument.
Cut 1 — Is this your moat?
If the capability is what you get paid for, build it. If it's table stakes or plumbing, buy it.
A retailer's recommendation engine is a moat. Its payroll pipeline isn't. A law firm's contract review is a moat. Its video conferencing isn't. People confuse "important" with "differentiating" and end up building things Microsoft sells for $20 a seat.
Cut 2 — How fast does it move?
If the space is moving faster than your release cadence, buy. You will never keep up.
Frontier model performance moves weekly. Vector DB pricing halves every quarter. If you're standing up a retrieval stack in 2026 and your team can't ship on a weekly cadence, you're buying, and you're buying soon, because the thing you built in January is already behind by March.
Cut 3 — What's the switching cost in eighteen months?
Every vendor decision is a lease, not a purchase. The question isn't "is this the best today" — it's "how hard is it to leave when it stops being the best."
Cheap switching costs mean you can buy aggressively. Expensive switching costs mean you should build the parts that force the lock-in, even if they're not your moat. API-compatible interfaces, standard data formats, boring architecture — those are the difference between a lease and a trap.
Apply in order
Moat first, then velocity, then lock-in. If the answer flips between cuts, go with cut one. Moats compound; everything else is commodity sooner or later.