Few questions burn more time in analytics teams than build versus buy. Should we adopt a warehouse-native transformation tool or write our own? Buy a customer-data platform or assemble one? Licence a forecasting product or build the model in-house? The debates are long, the opinions strong, and the framing usually wrong.

Build-versus-buy is not, at its core, a technology decision. It’s a decision about where your differentiation lives and what you’re willing to own for years.

Start with differentiation, not features

The first question is not “which option is better?” but “is this capability a source of competitive advantage for us?”

If a capability is genuinely differentiating — the pricing model at the heart of a marketplace, the risk engine at a lender — building can be worth it, because owning it end-to-end is part of the moat. If it’s undifferentiated plumbing that every company in your industry needs and none competes on — ingestion, scheduling, identity resolution — buying is almost always right. You are not going to out-engineer a vendor whose entire company exists to solve that one problem.

Build what makes you different. Buy what makes you the same as everyone else.

Most teams get this backwards. They buy the differentiating thing (and inherit its limitations) while lovingly hand-building the commodity infrastructure (and inheriting its maintenance).

Count the total cost of ownership honestly

The seductive thing about building is that the cost looks like zero — there’s no invoice. But the invoice is real; it’s just paid in your team’s time, forever. A fair comparison includes:

  • The build itself, then the long tail of edge cases that surface in production.
  • Ongoing maintenance: upgrades, breakages, the on-call burden when it fails at 2am.
  • The bus factor — what happens when the one engineer who understands it leaves.
  • Opportunity cost: every hour maintaining commodity plumbing is an hour not spent on the differentiating work.

Buying has its own real costs — licence fees, lock-in, the feature you need that’s on a roadmap you don’t control. The point isn’t that buying always wins. It’s that the comparison is only honest when both columns are filled in.

The switching-cost test

A useful tie-breaker: how expensive is it to change your mind later?

Decisions that are cheap to reverse should be made quickly and revisited often — favour buying, try it, switch if it disappoints. Decisions that are expensive to reverse — anything that becomes load-bearing for the whole organisation — deserve far more scrutiny, and often favour the option that keeps you in control of your own data and definitions, even if it costs more today.

The classic trap is letting a “quick” purchase quietly become load-bearing. The tool you bought to solve one problem ends up holding your canonical metrics, and now switching means re-deriving the numbers the whole company trusts.

A simple default

When genuinely unsure, we lean toward: buy the infrastructure, own the logic. Use mature, well-supported tools for ingestion, storage, and orchestration — the commodity layer. Keep your transformation logic, your metric definitions, and your models in version-controlled code that you own and can move. That way the plumbing is someone else’s problem and the part that’s actually yours stays yours.

It’s not a universal answer — there isn’t one. But it puts your effort where your differentiation is, and keeps the expensive-to-reverse decisions in your hands. That’s most of what a good framework is for.