Dashboard Development in 2026: Custom vs Power BI

Build a custom dashboard when the dashboard is a product feature, needs real-time push, or must serve hundreds of external users without per-seat fees. Buy a BI tool (Power BI, Looker, Metabase, Grafana) when the audience is internal, the questions change weekly, and analysts need to explore data without a deploy. Most companies need both: a BI tool for internal analysis and a custom layer only where embedding, latency or licensing make the BI tool a poor fit.

Custom dashboard vs Power BI, Looker, Metabase and Grafana

The right question is not "which tool is best" but "who looks at this, how often, how fresh must it be, and who pays per viewer".

Criterion	Power BI	Looker	Metabase	Grafana	Custom dashboard
Cost model	Per user (Pro/Premium per user) or per capacity; embedded needs capacity SKUs	Per user plus platform fee; enterprise pricing	Open source self-hosted (free) or per-user cloud	Open source self-hosted or usage-based cloud	Build cost + hosting + maintenance; no per-viewer fee
Embedding in your product	Yes, via Embedded; requires capacity licensing and iframe or SDK	Yes, embed SDK and signed URLs; strong for SaaS	Yes, signed iframe embedding; limited theming	Yes, iframe panels; branding limited on OSS	Native; full control of UX, theme and interactions
Real-time	Streaming datasets and DirectQuery; refresh intervals apply	Query on demand; no push	Query on demand; auto-refresh polling	Best in class for time-series and metrics; live panels	Any latency you engineer: SSE, WebSockets, polling
Customization	High inside the Power BI model; custom visuals possible	High via LookML; UI constrained	Moderate; SQL questions, limited visuals	High for time-series; weak for business charts and tables	Unlimited, but everything is your responsibility
Data governance	Datasets, certified data, sensitivity labels, Purview integration	LookML is the semantic layer; version-controlled in git	Basic; models and permissions per collection	Minimal; governance lives in the data source	Only what you build; usually a semantic layer plus tests
User management	Entra ID (Azure AD) native; RLS by role	SSO, groups, user attributes drive row filters	Groups, sandboxing per group; SSO on paid tiers	Teams, folders, SSO; RLS is limited	Your identity provider; RLS enforced in the data layer
Best fit	Microsoft shops, internal reporting, finance	Data teams with a modeled warehouse, SaaS embedding	Small teams, quick internal questions, low budget	Infrastructure and product telemetry	Customer-facing analytics, operations consoles, regulated multi-tenant views

Three patterns come up repeatedly:

• Internal reporting only. Buy. Power BI if you are on Microsoft 365, Looker if you already model data in a warehouse, Metabase if budget is tight. A custom build here is a maintenance liability.
• Analytics inside a SaaS product. Usually custom, or Looker embedded if you already pay for Looker. Power BI Embedded works but the capacity pricing and the visual identity rarely match a product.
• Operations console with live data. Grafana for infrastructure, custom for business operations (dispatch boards, fraud queues, warehouse floors). The BI tools were not designed for sub-minute updates and user actions on the same screen.

The line that separates the two camps: if users need to act from the screen (approve, assign, escalate), it is an application, not a report. Build it. If users need to ask new questions, it is analysis. Buy it.

Data architecture behind a business dashboard

The front end is the visible ten percent. Every reliable dashboard, custom or bought, sits on the same five layers.

1. Source systems

ERP, CRM, billing, product database, event streams, spreadsheets. Inventory them with owner, refresh cadence, and access method (API, replica, CDC, file export). Never query production OLTP databases directly from a dashboard: a single unindexed report query can lock a checkout table.

2. Ingestion: ETL or ELT

In 2026 the default is ELT: land raw data in a warehouse or lakehouse (BigQuery, Snowflake, Redshift, Databricks, or Postgres/ClickHouse for smaller volumes), then transform with SQL under version control (dbt or SQLMesh). Use ETL only when data must be masked before it lands, which is common under GDPR when the warehouse is in a different jurisdiction from the source.

3. Modeled layer

Facts and dimensions, or a wide table per domain. The goal is a schema a dashboard query can hit with one or two joins, not the source system's fifty tables. Keep raw data immutable and rebuildable so a bug in a transformation is a rerun, not an incident.

4. Semantic layer

The layer that says "revenue = sum(invoice_total) where status = 'paid'" exactly once. Options: LookML (Looker), Power BI datasets, dbt metrics via MetricFlow, Cube, or a hand-written metrics module in your API. A custom dashboard without a semantic layer produces three revenue numbers on three screens within six months.

5. Aggregation and freshness

Decide per metric: how old may it be? Write it down.

Metric type	Typical freshness	Mechanism
Finance close, P&L	Daily	Nightly batch, pre-aggregated table
Sales pipeline	Hourly	Incremental model every hour
Product usage	5–15 minutes	Streaming ingestion, micro-batch aggregation
Operations queue, fraud	Seconds	Event stream, push to client

Show the freshness on screen ("Data as of 07:00 CET"); users who cannot see a timestamp assume the data is live.

Chart selection rules that survive review

Most dashboard failures are twenty charts on one screen with nobody able to say which one matters. Rules that hold up:

1. One question per chart. If the title cannot be written as a question ("Is churn rising in DACH?"), the chart is decoration.
2. Trend: line. Time on the x-axis, one to four series. More than four becomes a small-multiples grid.
3. Comparison between categories: horizontal bar, sorted by value, not alphabetically. Labels stay readable on mobile.
4. Part of whole: stacked bar or a 100% bar. Pie charts fail as soon as there are more than three slices or values are close. Donut charts with one big number in the center are acceptable for a single ratio.
5. Distribution: histogram or box plot. Averages hide the shape.
6. Relationship: scatter, with a trend line only when it is statistically meaningful.
7. Single KPI: number, delta versus previous period, sparkline. This is the tile that executives actually read.
8. Tables are charts too. For reconciliation and operations, a sortable table with conditional formatting beats any visualization.
9. Color encodes meaning, not decoration. One accent color for "this series", one for "alert", grays for everything else. Use a colorblind-safe palette and meet WCAG contrast.
10. Never truncate the y-axis on a bar chart. On a line chart, truncation is allowed if labeled.
11. Above the fold: at most five to seven tiles. Everything else is a drill-down.

Layout hierarchy: KPIs top, trends middle, detail tables bottom. Filters in one bar at the top, applied globally, always visible.

Performance: pre-aggregation, caching and real-time

A dashboard that takes eight seconds to load is not used, however correct it is.

Pre-aggregate on write, not on read

Do not scan a hundred million events every time someone opens the sales page. Materialize daily and hourly rollups per dimension combination that appears on screen. A rollup table of a few million rows answers most business dashboards in tens of milliseconds. Warehouses offer materialized views; in Postgres, a scheduled REFRESH MATERIALIZED VIEW CONCURRENTLY or an incremental rollup table does the job.

Cache at the right layer

Three caches, three lifetimes:

• Query cache (Redis or the warehouse's own result cache) keyed by query text plus the user's security context. TTL equals the metric's freshness policy, so a daily metric is cached for hours and an hourly metric for minutes.
• API response cache with ETag or Cache-Control: private, max-age so a reload does not re-run anything.
• Client cache (TanStack Query, SWR) so switching tabs and returning is instant, with background revalidation.

Never cache across users when row-level security is in play; a cache key without the tenant ID is a data leak. The caching strategies guide goes deeper on invalidation and keying.

// Cache key must include everything that changes the result set
const key = `dash:v3:${metricId}:${tenantId}:${roleHash}:${dateRange}:${filtersHash}`;

Real-time only where it pays

Polling every thirty seconds is fine for most "live" screens and costs nothing to build. When updates must arrive within seconds, push them: Server-Sent Events for one-way server-to-client streams (most dashboards), WebSockets when the client also sends frequent messages or you need binary frames. The trade-offs are covered in WebSockets vs Server-Sent Events. Either way, send deltas, not the whole dataset, and throttle re-renders on the client so a burst of a thousand events does not repaint a chart a thousand times.

Front-end budget

Lazy-load charts below the fold, virtualize long tables, and render large series with canvas (ECharts, uPlot) rather than SVG. Ten thousand SVG nodes will freeze a mid-range laptop.

Access control and row-level security

Three layers:

Authentication. SSO through your identity provider with OIDC or SAML; short-lived tokens; no shared "dashboard viewer" accounts. See modern authentication with OAuth 2.0 and JWT.

Authorization at the screen level. Roles decide which dashboards and which tiles are visible. Keep this coarse: "finance", "sales-manager", "customer".

Row-level security in the data layer. This is the one teams get wrong by filtering in the UI or in the query string. Enforce it where queries run:

-- Postgres: the policy applies to every query, including ones you forgot about
ALTER TABLE sales_daily ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON sales_daily
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

The API sets app.tenant_id from the verified token before running any query. Warehouses offer equivalents (Snowflake row access policies, BigQuery row-level access, Power BI RLS roles, Looker user attributes). For column-level rules (salary visible to HR only), mask in the semantic layer, not in the chart.

Log every query with user, tenant, filters and row count: it is your GDPR audit trail.

Mobile dashboards

Most executives open dashboards on a phone between meetings. Design for it explicitly:

• Mobile is a different layout, not a shrunk one. Stack KPI tiles one per row; keep one chart per screen height; move tables behind a tap.
• Touch targets at least 44 px, no hover-only tooltips; tap to show values.
• Horizontal bars, not vertical, so category labels have room.
• Fewer series. Two lines on a phone, not six.
• Offline read. A PWA that shows the last fetched state with its timestamp beats a spinner on a train.
• Push notifications for alerts that deep-link to the filtered view; this is where custom beats every BI tool.

Dashboard project checklist

Every "no" is a risk to price in.

• Each dashboard has a named owner and a written decision it supports.
• Every metric has one definition in a semantic layer, with a test.
• Freshness per metric is documented and shown on screen.
• Source systems are read through replicas, CDC or exports, never production OLTP.
• Heavy queries hit pre-aggregated tables; p95 page load target is set (two seconds is a common bar).
• Cache keys include tenant and role; TTLs match freshness policy.
• Row-level security is enforced in the database or semantic layer and covered by an automated test that tries to read another tenant's rows.
• SSO is in place; no shared accounts.
• Chart types follow the selection rules; nothing above the fold beyond seven tiles.
• Mobile layout is designed, not derived.
• Query audit log exists and is retained per your GDPR policy.

Requirements template

A request that cannot answer these is not ready for estimation.

1. Audience. Who, how many, internal or external, on which devices.
2. Decisions. The three decisions this dashboard should change, in one sentence each.
3. Metrics. Name, formula, source, owner, freshness requirement, acceptable tolerance.
4. Dimensions and filters. Which breakdowns (time, region, product, customer) and which filters must be global.
5. Actions. Can users do anything from the screen (approve, assign, comment)? If yes, it is an application; scope it as one.
6. Security. Roles, row-level rules (tenant, region, team), column-level masks, audit needs.
7. Latency. Page load target and update latency per screen (daily, hourly, minutes, seconds).
8. Volume. Rows per fact table today and in two years; concurrent users at peak.
9. Embedding and branding. Standalone, inside a product, white-labeled, theme constraints.
10. Export and delivery. CSV, PDF, scheduled email, API access for downstream systems.
11. Alerts. Thresholds, channels (email, push, Slack, Teams), who configures them.
12. Existing tools. BI licenses already paid for, identity provider, warehouse, event platform.
13. Non-goals. What is explicitly out of scope for version one.
14. Success measure. How you will know in 90 days whether it worked (adoption, decision latency, reports retired).

Recommendation

Default to a BI tool for internal analysis: Power BI in a Microsoft environment, Looker on top of a modeled warehouse, Metabase when budget and scope are small, Grafana for telemetry. Build a custom dashboard when it is customer-facing, embedded in your product, needs push updates in seconds, or requires actions on the same screen. In both cases invest first in the invisible parts: the semantic layer, pre-aggregation, freshness policy and row-level security. Those decide whether the numbers are trusted; the charts only decide whether they are read. At Arvucore we usually recommend keeping the BI tool for exploration and building custom only the two or three screens where the tool visibly fails, then expanding from there.