The dashboard was a transitional technology. Most teams still ship one weekly report nobody reads, three executive views nobody opens, and a Looker subscription nobody questions. The pattern that replaces all of it is the real-time dashboard: a live decision surface, scoped to a role, instrumented for actual use, designed against specific decisions the operator must make right now. This report is the reference for how that surface is built.

The five-layer dashboard stack.

Every production real-time dashboard Morvion has shipped runs the same five layers. The architecture differs at scale; the layers do not.

Layer 01 · Event source.

The system of record that emits structured events as they happen. CRM, ERP, product database, external API, IoT stream, internal service. The contract is: events are typed, timestamped, and emitted close to the time of the underlying business action. A dashboard reading from a once-a-day batch isn't real-time, no matter what the UI says.

Layer 02 · Stream layer.

The events flow through a durable, replayable transport: Postgres logical replication + a CDC tool, Kafka / Redpanda, Inngest events, or platform-native streaming. The stream is the system's memory; if the live store is rebuilt, the stream replays it back into shape. Without this layer, every outage produces a permanent gap in the data.

Layer 03 · Live store.

Aggregated state in a low-latency store the surface can query in single-digit milliseconds. Postgres with materialized views and good indexing handles most workloads. ClickHouse, DuckDB, or Tinybird take over when aggregation volume crosses ~100M events. The choice depends on the query shape, operational read- heavy workloads use Postgres; analytical high-cardinality workloads use a columnar store.

Layer 04 · Push surface.

The browser subscribes to changes via WebSocket or server-sent events, never polling on a timer. The surface updates within hundreds of milliseconds of the underlying event. This is the layer that makes the dashboard feel live; polling-based dashboards feel like they're reading old news, because they are.

Layer 05 · Observability.

Two things measured continuously. Event-to-surface latency (how fresh is the dashboard, actually) and section-level usage (which charts get opened, hovered, acted on). Operators trust the dashboard because they know how fresh it is. The studio prunes sections that never get used. This is the layer that prevents the dashboard from becoming wallpaper.

“Real time is an architecture decision, not a refresh interval.”

The decision-first composition discipline.

The five layers are infrastructure. The composition discipline is the dashboard's actual product design.

  • One operator, one role. A single dashboard serves one role at a time. Operator view, founder view, executive view, different products with different vocabularies. Trying to unify them produces a compromise nobody references.
  • Three sections, three orders. Section one: the metrics that define success today (revenue, retention, throughput). Section two: leading indicators that predict them (pipeline coverage, activation rate, queue depth). Section three: anomalies that demand a decision (something outside its expected range, a deal gone quiet, a customer signal worth chasing). Everything else is a chart, not a dashboard.
  • Decisive density. Each section earns its space by changing a behaviour. If the chart doesn't change a decision in the operator's week, it gets pruned. Decoration is the dashboard's enemy.
  • One-glance state. The operator should know whether the business is okay within two seconds of opening the dashboard. Colour, contrast, and section ordering carry that signal; the chart detail is for when the operator already knows there's a question to ask.

Reference architectures · three scales.

Reference 01 · Solo operator / small team.

One role, one dashboard, one source of truth. The smallest viable stack. Built so the founder runs the whole business off one screen, mobile-readable, no second tab open.

Event source ──── application DB + a handful of external APIs
Stream ────────── Postgres logical replication + CDC tool
Live store ────── Postgres with materialized views
Push surface ──── WebSocket via the existing app server, ~300ms latency
Observability ─── event-to-surface latency tracked + section-level usage
Cost band ─────── €25–60k build, €0.5–1.5k/month run
Build time ────── 6–10 weeks
Live shape ────── founder-dashboard, single-team ops view

Reference 02 · Multi-team operations dashboard.

3–15 person team. Role-scoped views (operator vs. manager vs. executive). The same five-layer stack, with per-role surfaces composed against shared infrastructure.

Event source ──── operational DBs + CRM + ERP + product analytics
Stream ────────── Kafka / Redpanda or platform-managed CDC
Live store ────── Postgres + materialized views (or ClickHouse if vol high)
Push surface ──── role-scoped WebSocket channels + permissions layer
Observability ─── per-section usage + per-role engagement metrics
Cost band ─────── €50–120k build, €2–6k/month run
Build time ────── 8–14 weeks
Pattern note ──── ship one role end-to-end, then onboard additional
                   roles in 1–2 week passes

Reference 03 · Enterprise / multi-tenant dashboard.

Multiple business units, audit obligations, data- residency boundaries. Same five layers with extra boundary work: per-tenant data isolation, signed audit trails on view-level access, residency-aware infrastructure, SSO and RBAC.

Event source ──── per-tenant DBs + global lookup services
Stream ────────── per-tenant streams + per-region routing
Live store ────── per-tenant aggregates + region-specific instances
Push surface ──── role + tenant + region scoped WebSocket channels
Observability ─── signed view-access logs + per-tenant SLO tracking
Cost band ─────── €100–250k build, €6–18k/month run
Build time ────── 14–22 weeks
Audit assets ──── signed access logs, per-tenant SLO dashboards,
                   residency-aware retrieval contract
From the studio

Reference 01 and Reference 02 are the most common Morvion engagement shapes. Reference 03 is the same stack with the regulatory + audit scaffolding added; the architecture is identical, the boundary work compounds with the tenant count.

Freshness targets per surface type.

“Real-time” isn't one number; it's a target per surface type. Public ranges from Morvion engagements in 2026:

Operational decisions ─── event-to-surface ≤ 2s   (queue depth, alerts)
Sales / pipeline ──────── event-to-surface ≤ 30s  (deal stage changes)
Finance / billing ─────── event-to-surface ≤ 5m   (revenue recognition)
Executive overview ────── event-to-surface ≤ 1h   (rolling KPIs)
Historical / analytics ── event-to-surface ≤ 24h  (last week comparisons)

Tighter targets cost more in infrastructure and add complexity. Choose the loosest target that still supports the decision. Most teams over-engineer the freshness of executive overviews and under-engineer the freshness of the operational sections.

Cost bands · what to expect.

Public ranges from Morvion engagements in 2026, all-in (design + engineering + launch), excluding subscription tools the team continues to pay for (Postgres host, streaming infra, analytics vendor).

Discovery Sprint ────────── €18–25k · 2 weeks · locks 5–7 decisions
Solo / small team ───────── €25–60k · 6–10 weeks
Multi-team operations ───── €50–120k · 8–14 weeks
Enterprise / multi-tenant ─ €100–250k · 14–22 weeks
Retainer (post-launch) ──── €3–14k/month · iteration + section pruning

The 12-question self-audit scorecard.

For an operator to assess their current dashboard. One point per affirmative answer; max 12. Below 6 = the dashboard is wallpaper. Below 4 = the team is still running on Monday-morning reports.

  1. Does the dashboard update within seconds of the underlying event (not on a polled refresh)?
  2. Is there a documented event-to-surface latency target per section type?
  3. Does each section earn its space by changing a real decision in the operator's week?
  4. Can the operator know whether the business is okay within two seconds of opening?
  5. Are the views role-scoped (operator vs. manager vs. executive are different products)?
  6. Is section-level usage instrumented (which charts get opened, hovered, acted on)?
  7. Are unused sections pruned on a cadence, not allowed to accumulate?
  8. Is the live store sized for the actual query shape (operational vs. analytical)?
  9. Does the stream layer replay cleanly if the live store needs rebuilding?
  10. Are anomalies surfaced proactively rather than buried in a table?
  11. Can the dashboard be opened from mobile and remain useful?
  12. Does the dashboard make at least one named decision per week visible to the team?

What not to build.

The mistakes we see most often. Skip these even when the vendor demo is compelling.

  • Polling-as-real-time. A chart that refreshes every 30 or 60 seconds is not real-time; it is polite. Real-time uses WebSocket or server-sent events. The architecture is the difference, not the refresh-interval setting.
  • Embed-a-BI-tool. Dropping a Looker or Tableau embed inside an app and calling it “the dashboard” ships fast and ages badly. The surface is decision-agnostic, the freshness is the BI tool's freshness, the role-scope is the BI tool's role-scope. Use BI tools for analyst queries; build the operator dashboard.
  • One dashboard for every role. An executive view scaled down for the operator is a compromise that serves neither. Build per-role dashboards on shared infrastructure.
  • Chart sprawl. Every team adds their favourite chart until nothing is decisive. Instrument usage, prune ruthlessly. A dashboard that grows monotonically is a dashboard becoming wallpaper.
  • Vanity KPI walls. A wall of green KPIs nobody opens is decoration. A dashboard that changes a decision once a week beats a dashboard that shows thirty KPIs nobody references.

Worked example · founder-dashboard pattern.

A concrete shape, drawn from an aggregated engagement pattern. The founder runs a 12-person services business and operated for a year on weekly screenshots. Pre- dashboard: 90 minutes every Monday compiling, 3 hours of meeting time discussing, decisions made on Wednesday at the earliest. Post-dashboard:

  • Layout. Three sections, Today (event-to- surface ≤ 2s), This Week (≤ 30s), Trends (≤ 1h). Mobile-readable. Two-second one-glance state via colour and section ordering.
  • Freshness. Operational metrics live within 2 seconds of the event. Pipeline within 30 seconds. Executive trend within an hour. Latency surfaced next to each section so the founder trusts it.
  • Usage. Section-level instrumentation shows the Today and This Week sections used daily; the Trends section opened weekly. The fourth section originally added got opened twice in three months and was pruned.
  • Cost. €42k build + €1.2k/month run. Payback at ~4 months on the recovered Monday compilation time alone.
  • Behaviour shift. Decisions move to Tuesday from Wednesday. Anomalies caught the day they happen, not the week. The founder stops opening three spreadsheets to check the same number.

The numbers above are aggregated and de-identified across comparable engagements. The pattern is the asset; specific numbers vary by data volume and source complexity.

Regional notes · CH, DACH, EU.

The architecture applies broadly. A few region-specific considerations from CH and DACH engagements:

  • Data residency: Swiss FADP (revised 2023) and EU GDPR/DSGVO both apply to dashboard data. For regulated clients, the live store runs on CH/EU- resident infrastructure and the stream layer respects the same boundary.
  • Multilingual labels: Dashboards aimed at Switzerland often need DE + FR + EN labels at minimum. The label layer is data-driven (translations live in the data model, not in the component) so a single dashboard component renders correctly per user locale.
  • Audit + access logs: Regulated sectors require signed access logs per view, who saw which data, at what time. The observability layer emits a signed record per view, retained per the relevant retention policy (typically 3–7 years).
  • AI Act readiness: Dashboards that surface AI-driven decisions (next-best-action, predictive signals) fall under the same eval discipline as the AI itself. The dashboard cites the model version and the policy version that produced any AI-driven surface.
Field rule

A dashboard is not finished when the data flows. It is finished when the operator stops opening spreadsheets to check the same number.

Real-time dashboards are built inside Digital Products & Platforms, often alongside Intelligent Systems & AI Infrastructure when AI-driven surfaces are part of the dashboard. Engagements start with a two-week Discovery Sprint that identifies the 5–7 decisions the dashboard must change, locks the freshness budgets per section, and picks the source-of-truth layer before any production build.

For the one-paragraph definitions of the underlying terms, see the glossary entries on real-time dashboard and business intelligence dashboard. When the dashboard surfaces AI-driven decisions, the same observability discipline as AI observability applies, the dashboard cites the model and policy versions per surface.

Versioning of this report.

This document is versioned. Substantial revisions (new reference architecture, new cost band, new freshness tier) bump the major version. Minor refinements are silent. Current version: 1.0.0, published 2026-05-19.

Common questions.

What is a real-time dashboard?
A real-time dashboard is a live data surface that updates within seconds of the underlying event. It is designed for operators who need continuous awareness of what is changing in the business, not a weekly snapshot. The point isn't freshness for its own sake; it is putting the operator inside the system instead of two hours behind it.
What does a working real-time dashboard stack include?
Five layers: an event source (the system of record that emits structured events), a stream layer (durable and replayable), a live store (low-latency aggregation), a push surface (WebSocket or server-sent events to the browser, never polling), and an observability layer that exposes event-to-surface latency. Plus a decision-first composition discipline, every chart must change a behaviour or it doesn't belong.
How much does a real-time dashboard cost to build?
Morvion engagement bands: solo operator / small team dashboard lands €25–60k. Multi-team operations dashboard with role-scoped views lands €50–120k. Enterprise / multi-tenant dashboard with audit and residency boundaries lands €100–250k. A two-week Discovery Sprint at €18–25k typically precedes the build and identifies the 5–7 decisions the dashboard should change.
How long does a real-time dashboard build take?
Solo / small team: 6–10 weeks from kickoff to launch with a live preview on real data inside the first three weeks. Multi-team: 8–14 weeks. Enterprise / multi-tenant: 14–22 weeks. The architecture is chosen against the actual decisions the dashboard must enable, not against a default stack.
What's the difference between a real-time dashboard and a BI tool?
A BI tool (Looker, Tableau, Metabase) is a generic visualization layer over a warehouse, typically batched, decision-agnostic, designed for the analyst. A real-time dashboard is decision-first, live, role-scoped, and instrumented for the operator. BI tools answer 'what happened last week?'; real-time dashboards answer 'what needs a decision right now?'.
What's the failure mode of bad real-time dashboards?
Three patterns: wallpaper (a dashboard nobody references because it doesn't change behaviour), polling-as-real-time (a chart that refreshes every minute and pretends it's live), and chart sprawl (every team adds their favourite chart until nothing is decisive). All three are caught by instrumenting dashboard usage, section-level analytics, and pruning what doesn't get used.