Build vs. buy embedded analytics: an honest breakdown

Quick answers

"We'll build it ourselves" is the most expensive analytics decision most product teams make. Not because building is always wrong — it's sometimes exactly right. But the scope is consistently underestimated and the ongoing cost stays invisible until it's competing with everything else on your roadmap.

Here's an honest accounting of what each path actually involves.

What "build" actually means

When a team decides to build their own analytics feature, here's what's on the list:

Charting library integration. Pick a library, build wrappers for the chart types you need, handle responsive sizing, theming, and export. Non-trivial, but tractable.

Query logic. Either hardcode queries for each chart — which breaks every time the data model changes — or build a query layer that generates SQL dynamically from a UI. The latter is a serious engineering project that becomes load-bearing infrastructure.

Multi-tenant data isolation. Every query, every chart, every filter must be scoped to the right customer. There are no partial solutions here — a gap is a data leak. Building and maintaining this correctly under all conditions is one of the harder problems in the stack.

Permission model. Who can see which dashboards? Can customers build their own queries? Can they save and share reports? Every capability layer requires a permission model that's correct in every edge case.

Dashboard layout. A fixed grid your team maintains, or a drag-and-drop builder customers can use? Either way, it's ongoing engineering work.

Saved reports and sharing. Customers want to save what they build and share with teammates. Building the persistence layer, the sharing model, and the organization-scoped access controls adds significant scope.

Ongoing maintenance. This is the part teams consistently underestimate. Every time your data model changes, the analytics layer changes. Every time a customer asks for a new chart type, it's a sprint. Every new edge case in permissions is a bug. It doesn't end at launch — it accelerates as your product grows and customers ask for more.

What embedding Metabase actually involves

Getting started: npx @metabase/embedding-sdk-react@latest start spins up a local Metabase with an embedded dashboard in your app. Try it before making any commitments.

Production setup: Connect Metabase to your database, configure your first dashboard, set up token-based authentication for Modular Embedding. Most teams reach production in a sprint.

Multi-tenant isolation: Define data sandbox rules — "filter this table where tenant_id = {{ user.tenant_id }}". Configuration work, not engineering work. Metabase enforces it on every query.

Adding capabilities: New chart type? Already built. Customer wants to save reports? Enable SSO mode. Customer wants natural language querying? Add Metabot. Each addition is a configuration or a small SDK integration, not an engineering project.

Ongoing maintenance: When your data model changes, update the dashboard in Metabase's UI. When customers ask for a new metric, define it in Data Studio. Most analytics changes don't touch your codebase.

The hidden costs of building

Opportunity cost. Every sprint spent on chart rendering and permission edge cases is a sprint not spent on your core product. An analytics platform vendor has entire teams working on problems you'd be solving part-time.

Talent and knowledge concentration. Building a good query layer and visualization system requires specialized skills. When the engineer who built it leaves, the maintenance burden falls on whoever can least afford to take it on.

Rising customer expectations. Analytics features have moved fast. Customers increasingly expect interactive drill-through, self-serve querying, natural language interfaces. The build option has to keep pace with a market moving quickly.

When build is right

Build your own analytics layer when:

• Analytics is your core product. Not a feature — the reason customers buy. Your differentiation is in how you present and analyze data, and that differentiation requires proprietary visualization or query logic.

For everything else — analytics as a feature customers expect, not the reason they buy — embedding a platform is faster, cheaper, and delivers a better experience than most product teams can build and maintain.

Key takeaways