How to decide build vs buy for analytics

"Build vs buy" in analytics is rarely a single decision — it is a separate decision at every layer of the stack, and the right answer differs by layer even within the same company. A team that should buy its ingestion connectors outright often should build (in the sense of owning, in code) its own transformation logic. This guide gives a way to reason about each layer rather than a single rule, because a single rule applied uniformly is how companies end up either buying things they should own or building things they should not.

The real cost of "build" is rarely the initial build

The build option's cost is almost never dominated by the first version — it is dominated by what happens after: the maintenance burden when a source API changes its schema without warning, the on-call rotation for a pipeline that fails at 2 a.m., and the opportunity cost of an engineer's time spent maintaining a connector instead of working on something specific to your business. Before comparing a build estimate to a vendor's price, price in maintenance across a realistic multi-year horizon, not just the sprint it takes to ship a first version.

The real cost of "buy" is rarely the sticker price either — it is what happens at the edges: the connector the vendor does not support and now you build anyway, the usage-based pricing that scales faster than expected as data volume grows, and the cost of migrating away if the vendor's roadmap diverges from your needs.

A framework: ask four questions per layer

For any component of the stack — ingestion, storage, transformation, orchestration, the BI layer — ask:

1. Is this differentiated, or is it plumbing? A connector that pulls Salesforce data into a warehouse is identical in every company that has this problem; a vendor amortizing that cost across thousands of customers will almost always build and maintain it better than you can justify building for one company. Your own business logic — how you define an active customer, what your reporting looks like — is not plumbing; it is the thing that makes your analytics yours, and it belongs in something you control.
2. Does a mature vendor option already exist? For ETL/ELT connectors, warehouse compute, and orchestration, mature, well-supported options exist and are the default unless you have an unusual reason not to use them. For a genuinely novel problem specific to your business, no vendor option may exist yet, and building is not really a choice.
3. What does exit cost, if you are wrong? Some vendor choices are cheap to reverse (a BI tool, if the underlying data model does not depend on it) and some are expensive (a proprietary data warehouse format that only that vendor's tools can read efficiently). Favor open formats and open interfaces at the layers where you are least certain of the long-term choice.
4. Who owns this once the original builder leaves? A built-in-house pipeline with no documentation and one engineer who understands it is a liability regardless of how well it works today. A vendor product has an entire company responsible for keeping it running; an internal build needs the equivalent discipline (documentation, tests, a bus factor greater than one) or it is not actually cheaper, just riskier.

Applying it layer by layer

Ingestion. Almost always buy. Fivetran's or Airbyte's hundreds of maintained connectors save more engineering time than almost any internal build could justify, and connector maintenance is exactly the kind of undifferentiated plumbing question one above describes. Build only for a genuinely internal or unusual source no connector covers.

Storage. Buy the underlying compute (a managed cloud warehouse) essentially always — running your own database cluster at analytics scale is a specialized operational skill most companies should not be developing in-house. The real decision here is which vendor and deployment model, not whether to self-host the infrastructure.

Transformation. This is the layer to own, even when the tool that runs it is a vendor's product. dbt is a good example of the right split: the tool is bought (or used as free, open-source software), but the SQL models that encode what "revenue" and "active customer" mean are yours, version-controlled, and not something you would want locked inside a vendor's proprietary logic layer.

Orchestration. Buy or self-host an established open-source orchestrator such as Airflow or Dagster rather than building a custom scheduler — this problem has been solved thoroughly enough that a custom build rarely earns back its maintenance cost.

BI and the semantic layer. Genuinely mixed, and the layer most worth deliberating rather than defaulting on. A vendor BI tool such as Looker or a self-hosted option such as Metabase both work; the harder question is where metric definitions live, since that decision is expensive to reverse. See how to build a metrics layer for that decision specifically.

Open source is not automatically "free"

An open-source tool avoids a license fee but not the cost of running, patching, and being the on-call team for it. Self-hosting Airbyte or Metabase is a legitimate choice — for data residency requirements, for cost at large scale, or for control — but budget the hosting, maintenance and incident response it requires as a real, ongoing cost, not a free alternative to a vendor subscription.

A short decision aid

Measuring whether the decision was right

Revisit build-vs-buy choices against actual Analytics ROI a year in, not just against the original estimate — a "build" that consumed far more maintenance time than planned, or a "buy" whose usage-based bill outgrew the original quote, are both common enough that a planned review catches the mismatch before it compounds for another year. Governance around who owns each layer, from the data governance guide, should extend to build-vs-buy decisions themselves — someone should own the choice, not just the resulting system.

Related reading: how to build a modern data stack for the layers this framework applies to, and how to reduce data warehouse costs for what "buy" costs in practice once usage scales.