โ† All work
Point of view How I think

How I decide
buy vs build

Buy-vs-build isn't a gut call or a cost spreadsheet โ€” it's the same four questions every time. The interesting part: run two honest decisions through the same rubric and they can come out opposite. That's the rubric working, not failing.

The rubric

Four questions, every time

01
Differentiator or infrastructure?
Will customers ever choose us because of this? Or is it table stakes everyone needs and no one rewards?
02
What's the true cost of ownership?
Not the build โ€” the forever. Maintenance, the roadmap tax, the eng time quietly spent keeping it alive.
03
How much regulatory surface?
Every line we own in a regulated path is a line we have to defend, audit and keep compliant as rules change.
04
How fast do I need to be right?
If speed-to-correct matters more than control, that pulls toward partnering. If the learning is the point, build.
Same rubric, opposite answers
Verification (KYB/KYC) The PLG demo
โ† Build in-houseBuy / partner โ†’
Differentiation
Cost of ownership
Regulatory surface
Speed to be right
Verification scores toward buy on every axis; the demo scores toward build. The dots cluster on opposite sides โ€” which is exactly why both calls were right. [Nudge any marker if your read differs.]

Two decisions

The rubric in practice

Verdict ยท Buy
KYB/KYC verification
Low differentiation, high cost of ownership, heavy regulatory surface, and speed mattered. Every axis pointed to partner โ€” so we moved to a specialist provider and kept only the risk policy on top, where the advantage actually lives.
Verdict ยท Build
The PLG demo experience
Here the experience was the differentiator, the regulatory surface was light, and AI made building fast enough that owning it cost little. So we built it ground-up โ€” and learned more by doing than any vendor could have taught us.
"Buy the infrastructure. Build the thing that only you can."