How do you make a build vs buy decision?

The differentiation test

Ask whether a customer would ever pick you over a competitor because of this piece. Auth, billing, email delivery, error tracking — almost never. Your matching algorithm, your pricing engine, your core editing experience — possibly yes.

Buying a commodity frees engineers for the parts that matter. Building a commodity spends your scarcest resource proving you can rebuild something that already exists.

When building the hard thing is the strategy

Figma's decision to render a design tool in the browser using WebGL was a build decision on the highest-difficulty setting. No vendor solution existed, and the browser wasn't obviously capable. It took years before the bet looked sane.

It was correct because the component was the product. Browser-native collaborative design wasn't a feature of Figma; it was the entire reason Figma could exist against incumbents. Nobody outsources that.

Vercel's business is the mirror image — it exists because deployment infrastructure is something most teams should buy rather than build, and it made buying dramatically easier than the DIY alternative.

The questions worth actually asking

How long until value, on each path? Buying is usually weeks, building is usually quarters, and the gap is often decisive on its own.

What's the exit cost if you buy and the vendor disappoints you? Shallow integration is cheap to leave; a vendor woven through your data model is not.

And who owns it in two years? Built components need a permanent owner. If you can't name the team that maintains this after the people who built it have moved on, you're accumulating orphaned infrastructure — the most expensive category there is.