# Building a customer-facing analytics dashboard in 2026

*By Roberto Lazar, founder of Dock30 · Published 2026-07-30 · Updated 2026-07-30 · 8 min read*

How embedded, multi-tenant analytics you ship to your own customers differs from an internal dashboard, and how to handle isolation, embedding, speed, and cost.

A customer-facing analytics dashboard is the reporting screen your own customers log into inside your product, where each account sees only its own numbers. It is a harder build than an internal operations dashboard for one reason: **every query has to be scoped to the right tenant**, and getting that wrong once shows one customer another customer's data. In 2026 you have two honest routes, embed a purpose-built tool such as Luzmo or Embeddable, or build the thing yourself on the database your data already lives in, and the choice turns almost entirely on how central the analytics are to what you sell.

We build both kinds at Dock30, and the difference between them is bigger than it looks from a screenshot. So before anything about tools or pricing, it is worth being clear about which job you are actually doing.

## Internal analytics and customer-facing analytics are not the same job

An internal dashboard is used by people you employ. If a number is wrong, a colleague raises it in Slack and you fix it. The [operations dashboard we built for a McDonald's franchisee](/work/mcdonalds-dashboard) is that shape: one owner running three restaurants, pulling from 8+ back-office systems into a single screen that a small group of trusted managers reads. There is exactly one tenant, the franchisee, and the hard part is reconciling messy sources, not walling users off from each other.

A customer-facing dashboard is used by strangers who pay you. [Kvants](/work/kvants), an AI trading-agent platform we built, is the other shape: every user logs into the product and sees their own portfolio and returns, drawn from the same tables that hold everyone else's. Now the requirements change. Each account must see its data and nothing else. The dashboard carries your brand, not a vendor's. It has to stay up on a real schedule because customers judge your product by it, and it has to hold its speed when hundreds or thousands of accounts open it at once rather than a handful of staff. None of that is optional, and all of it is work an internal tool never has to do.

## Multi-tenant data isolation is the part you cannot get wrong

This is where customer-facing analytics earns its reputation. If the McDonald's dashboard has a query bug, a manager sees a wrong total. If a multi-tenant SaaS dashboard has the same bug, customer A sees customer B's revenue, and now you have a breach to disclose. There are three patterns for keeping tenants apart, and they trade isolation against operational cost.

| Isolation pattern | How it works | Trade-off |
|---|---|---|
| Shared database, row-level security | One database, a tenant ID column, queries filtered to the logged-in tenant | Cheapest and scales to thousands of tenants, but one config mistake affects everyone |
| Schema-per-tenant | Shared database, a separate schema per customer | More separation, more migrations to run and keep in sync |
| Database-per-tenant | A full database per customer | Strongest isolation, highest cost to run and migrate |

For most products the right default is a **shared database with row-level security**. It is the dominant pattern in SaaS because it is operationally simple, one database to back up and one schema to migrate, and it carries thousands of tenants comfortably, per [DataTako's guide to multi-tenant analytics](https://datatako.com/blog/multi-tenant-analytics). Database-per-tenant is worth its overhead only when you have regulated data or a small number of very large customers who contractually demand physical separation.

The detail that matters more than the pattern is where tenant identity comes from. It has to be decided on your server, never in the browser. The reliable approach in 2026 is that your application authenticates the user and issues a signed token carrying the tenant ID, which the analytics layer resolves server-side before any query runs, so no amount of tinkering in the client can reach another tenant's rows, as [Toucan describes for token-based embedding](https://www.toucantoco.com/en/blog/embedded-analytics-multi-tenancy-row-level-security-pricing). The failure modes are well catalogued and dull: a default-allow rule that shows everything unless told otherwise, a new table shipped without an RLS policy, a cached chart served to the wrong tenant, an export API that skips the checks the UI enforces. DataTako lists eight of these, and notes every one has caused a real breach at a real company. The multi-tenant testing that catches these bugs is real work, so budget time for it instead of treating it as a rounding error.

## Build it yourself or embed a tool

Once isolation is settled, the real fork is whether you write the dashboard or buy one that drops into your app. The buy side has become genuinely good. Purpose-built platforms like Luzmo, Explo, Qrvey, and Embeddable ship ready-made components with multi-tenancy handled by construction, and semantic-layer platforms like Cube sit under them for governance, per [Cube's 2026 roundup](https://cube.dev/articles/best-embedded-analytics-platforms-2026). Metabase's embedding is the fastest path to a first chart, though it hits scale and isolation limits in serious multi-tenant use and needs more permissions engineering than the purpose-built tools.

The cost gap is the honest reason to take the buy route seriously. Building customer-facing analytics in-house runs roughly 181,000 to 310,000 dollars in the first year with two senior engineers on it for eight to twelve months, and lands near **371,000 to 630,000 dollars across three years** once maintenance and feature parity are counted, against 150,000 to 360,000 dollars to buy and integrate over the same period, per [Toucan's build-versus-buy analysis](https://www.toucantoco.com/en/blog/embedded-analytics-build-vs-buy). Buying also puts charts in front of customers in weeks rather than the better part of a year. This is the same reasoning we apply to internal software in our [build versus buy guide for internal tools](/blog/internal-tools-build-vs-buy), and the answer rhymes: rent the commodity, own the thing that is actually yours.

So when does building win? When the analytics are the product. Kvants is exactly that case. The portfolio view is not a feature bolted onto something else, it is what customers open the app to see, so we built it on the same Postgres that stores the normalized trading history rather than paying a per-tenant fee forever to show numbers we already own. That is [custom backend and dashboard work](/services/custom-development), and it is the right call when the data experience is your differentiator, when you have data-sovereignty constraints, or when the numbers already live in a database you run.

## Keeping it fast when every customer hits it at once

Speed is where customer-facing dashboards quietly fail, because the scale is different from an internal tool. Ten staff refreshing a screen is nothing. Two thousand customers each loading their own view on a Monday morning is a load test you did not schedule. The trap is running a live query against your warehouse for every chart on every page load. Do that and, in Cube's phrasing, one heavy tenant can slow the experience for everyone.

The fix is the same one that keeps any dashboard fast: precompute. Roll each tenant's numbers up into per-tenant summary tables or materialized views on a schedule, so a chart reads a few hundred precomputed rows instead of scanning millions of raw ones, then cache the aggregated response so fifty viewers of the same screen do not trigger fifty identical queries. On Kvants, a normalizer runs a set of scheduled snapshot jobs that write history, NAV, and returns into Postgres, and the dashboard reads only those tables, so no customer's page load waits on a live exchange API. We wrote the full set of patterns up separately in our guide to [real-time dashboard data aggregation](/blog/realtime-dashboard-data-aggregation); for a customer-facing build the one addition is that every rollup and every cache key has to include the tenant, or you will precompute a fast way to leak data.

## What embedded analytics actually costs in 2026

Pricing splits by model, and the sticker rarely survives contact with a real multi-tenant deployment. Here is where the common tools sit, from [Toucan's 2026 pricing breakdown](https://www.toucantoco.com/en/blog/embedded-analytics-multi-tenancy-row-level-security-pricing).

| Tool | Pricing model | Rough 2026 cost |
|---|---|---|
| Metabase (embedding) | Platform fee plus per external user | ~575 USD/month plus ~12.50 USD/external user |
| Tableau Embedded | Per viewer, yearly | ~420 USD/viewer/year |
| Power BI Embedded | Azure capacity | Entry tier ~750 USD/month |
| Purpose-built (Luzmo, Explo, Qrvey) | Flat or per-tenant | ~1,500 to 5,000 USD/month typical |

The number to watch is not the entry price, it is the all-in one. White-label branding is often a paid upgrade that adds 20 to 40 percent, enterprise support and proper multi-tenant security cost more on top, and a 750 dollar entry plan can realistically settle at 3,000 to 4,000 dollars a month once those are in. That recurring bill is exactly what tilts the math toward building when analytics is core, and it is worth reading alongside what an [internal dashboard costs to build](/blog/internal-dashboard-cost), since the engineering underneath is similar and the pricing logic is not.

We sit on the build side of this, from Romania, which changes the arithmetic again. We scope customer-facing dashboards as [fixed-scope projects](/services/dashboards-tools) starting at **EUR 350**, with the exact price and the delivery date written down before any work begins, plus 30 days of free support after launch. The scope is pinned on purpose, because multi-tenant analytics is the kind of project where one more chart and one more permission rule quietly double an open-ended estimate. Fixing the number and the date up front is how we have hit every agreed delivery date since 2021.

If you are weighing a customer-facing dashboard and are not sure whether to embed a tool or build it, tell us how many customers will use it and where the data lives, and we can give you a straight answer in a short call, including the times the honest answer is to just start with Metabase. Book a [free 15-minute call](https://calendly.com/dock30/15min) or reach us through [contact](/contact). You will come away with a real number and a straight build-or-embed recommendation, even when that recommendation is to embed.

## Frequently asked questions

**What is the difference between internal and customer-facing analytics?**

An internal dashboard is used by a handful of trusted people inside your own company, so a mistake shows one colleague the wrong number. A customer-facing dashboard lives inside your product and is used by strangers who each pay you, so the same mistake can show one customer another customer's data. That single change in audience raises the bar on data isolation, uptime, and design far above what an internal tool needs.

**Should I build or buy customer-facing analytics?**

Buy or embed a tool when analytics is a feature of your product rather than the reason people buy it, and you want charts in front of customers within a few months. Build it yourself when the data experience is what you sell, when you have regulatory reasons to keep processing in-house, or when you already run the database the numbers live in. Most SaaS teams are better served embedding first and building later if the tool starts to limit them.

**How do you isolate data between tenants in a customer-facing dashboard?**

The common default is a shared database with a tenant ID column and row-level security, so every query is filtered to the logged-in customer's rows automatically. Your server, not the browser, decides which tenant the request belongs to, usually by resolving a signed token before any query runs. Database-per-tenant gives stronger isolation but costs far more to operate, so it is reserved for regulated data or a small number of large customers.

**How much does embedded analytics cost in 2026?**

Per-seat tools like Metabase embedding run around 575 dollars a month plus roughly 12.50 dollars per external user, while Tableau Embedded is near 420 dollars per viewer a year and Power BI Embedded starts around 750 dollars a month for its entry capacity. Purpose-built embedded platforms typically land between 1,500 and 5,000 dollars a month once white-labeling and multi-tenant security are included. Building the same thing in-house is usually a six-figure project across three years.

**How do you keep a customer-facing dashboard fast at scale?**

Precompute the numbers each customer sees into per-tenant rollup tables or materialized views, so a chart reads a few hundred summarized rows instead of scanning millions of raw ones on every load. Cache the aggregated results so many viewers of the same screen do not each trigger a fresh query. Without pre-aggregation, every chart is a live warehouse query and one heavy customer can slow the dashboard for everyone.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact