Build, Embed or Buy: The Analytics Decision Every SaaS Hits

There is a moment in the life of every B2B software product when a customer asks to see their own data inside the application. It sounds like a front-end request. It is mostly a data engineering request wearing a front-end costume, and the path you choose at that moment determines your cost structure for years.

Three paths exist. Here is an honest account of each.

Path One: Build It

You own the pipeline, the storage, the query layer and the interface. In 2026 this is far less heroic than it used to be — a columnar store, a transformation layer and a thin API in front of parameterised queries will carry a serious product a long way. The stack is commoditised.

Build when analytics is genuinely part of why customers pay. If your differentiation is the insight itself — a benchmark nobody else can produce, a model output competitors cannot match — you cannot outsource the layer that expresses it. Build also when customers contractually require that data never leave your infrastructure.

Do not build because it looks cheap. The visible cost is the first release. The invisible cost is everything afterwards: query performance regressions as customers grow, schema migrations that silently break three charts, a permissions model that has to survive an enterprise security review, and someone on call when the overnight rollup fails. Budget a standing allocation, not a project.

Path Two: Embed

Specialist vendors provide a component that renders inside your product, authenticates against your tenancy model and inherits your styling. You keep the data; they provide the query engine, the chart layer and usually a self-service explorer.

This is the right default for most B2B products, and it is chronically under-considered because engineers enjoy building dashboards.

The value is not the charts. It is the three years of edge cases already absorbed: spreadsheet exports with correct number formatting, timezone handling that does not shift a day boundary, drill-down state that survives a refresh, and a query builder that will not let a customer write something that takes down your cluster.

Two things to check before signing. Pricing is usually per end user or per query, which means unit economics degrade exactly as you succeed — model it at five times your current customer count. And test the escape hatch: if the vendor vanished, how much is portable?

Path Three: Buy a Separate BI Tool

You give customers access to a standalone reporting tool pointed at their slice of your data. Fastest to stand up, and usually wrong for a product company.

A separate login is a retention leak — customers leave your product to get value. You also lose visibility into what they look at, so you cannot tell which insights drive renewals.

It genuinely works for one segment: large, technical customers with their own analysts who would rather pull your data into their environment. For them, a clean, well-documented data share beats any dashboard you could build. Serve that segment deliberately, not as a way to dodge the decision.

What It Actually Costs

The cost breakdown surprises people because the part everyone estimates is the smallest one. Roughly in order of how badly each gets underestimated:

• Data modelling and metric definitions — often a third of total effort, almost never in the estimate
• Query performance engineering — recurs every time you land a bigger customer
• Multi-tenant isolation — non-negotiable, frequently uncosted
• Support load — permanent, not a launch spike
• Infrastructure — scales with customers and usage, not revenue
• Front-end build — the part everyone estimates, and the smallest line

The consequence: with no data engineering capability today, embedding is usually cheaper over three years even when the licence fee looks alarming, because it removes the two biggest lines. If you already run a warehouse, building is cheaper than it looks.

The Rule That Saves More Than the Platform Choice

Whatever path you pick: five metrics, not fifty.

The requirements list from customer interviews contains everything anyone could imagine wanting, because proposing a chart is free and objecting to one is socially expensive. Building all of it forces a general data model, and generality — extra joins, extra indexes, rollup permutations, a permissions system that scopes anything by anything — is where the schedule disappears.

Define five precisely, including the awkward parts. Ship internally first so your own team finds the definition disagreements. Then release narrowly and let usage data pick the sixth. Roughly half the original list goes unopened once the core five exist.

Full guide, with the architecture and the AI angle: product analytics dashboards.

Frequently Asked Questions

Which path is right for a small team with no data engineers?

Embedding, almost always. It removes the two largest cost lines — designing the data model and keeping queries fast — which are precisely the ones a team without data engineering capability is least equipped to absorb. Revisit the decision if analytics becomes a primary reason customers choose you.

How do we evaluate embedded analytics vendors?

Check pricing shape at five times your current scale rather than today's, since per-user and per-query models degrade as you grow. Check connector and API depth for the queries you actually need. And test portability: work out how much of your implementation survives if you had to leave.

Why is data modelling the biggest cost?

Because it is the work of deciding what every metric means and making every surface agree, and that is organisational as much as technical. It involves reconciling definitions between departments, documenting edge cases, and enforcing the result. Charts are quick; agreement is slow.

Can we start by building and switch to embedding later?

Switching is easier in that direction than the reverse, because your data model and metric definitions carry over even when the interface does not. Keep your metric definitions in a semantic layer independent of the presentation layer and the migration stays tractable.

What is the single most common scoping mistake?

Building every chart on the requirements list. The list is produced by a process that only grows, and building all of it forces a general and therefore slow and complicated foundation. Five well-defined metrics deliver more value and cost a fraction as much to keep running.