- Buy anything that isn't part of your core differentiator, almost without exception.
- Build only what directly creates the advantage customers are actually paying for.
- A recurring build-vs-buy debate for the same category signals a missing team policy.
- The framework should be fast to apply, not a week-long analysis each time.
Buy anything outside your core differentiator
Authentication, payments, email delivery, basic CRM functionality — these are almost never what makes a startup's product special, and mature, reliable tools exist for all of them. Building these in-house is time spent not building the thing customers are actually paying for.
Build only the actual differentiator
The one area worth the time and risk of building custom is whatever specifically creates the competitive advantage the business is betting on — the unique algorithm, the specific workflow that makes the product feel magical to its first users. Everything else is a distraction from that core bet.
A recurring debate signals a missing policy
If the same build-vs-buy argument comes up repeatedly for a category of decision — 'should we build our own analytics again' — that's a sign the team needs an explicit, written default policy for that category, rather than re-litigating it every time it comes up.
Speed of the decision matters as much as its accuracy
A build-vs-buy analysis that takes two weeks to reach a conclusion has already cost more in delay than most wrong decisions would have cost in rework. The framework should be fast enough to apply in an afternoon for most decisions, reserving deep analysis only for the rare, genuinely close calls.
Revisit 'buy' decisions as the company matures
A tool that was the right 'buy' decision at ten customers might become a limiting factor at ten thousand. The framework isn't a one-time decision — it's worth periodically revisiting whether a past 'buy' still holds, especially for anything adjacent to the core differentiator.