Most teams we meet have a weekly report and a BI subscription, and still run the week from spreadsheets. The dashboard that earns a place on someone's screen works differently. It updates when the business changes, it is built for one role, and every section on it is there because it changes a decision someone makes this week. This report covers how that dashboard is built and how it is composed.
The five-layer model
Four layers move an event from the system that records it to the screen of the person who acts on it. The fifth measures whether that worked: how fresh the numbers are, and whether anyone looks at them.
- Layer 01Event sourceTyped, timestamped events from the systems of record.
Broken whenThe data arrives in a nightly batch, whatever the dashboard claims.
- Layer 02StreamA durable, replayable transport.
Broken whenAn outage leaves a permanent gap in the numbers.
- Layer 03Live storeAggregates the surface can query in milliseconds.
Broken whenQueries slow down as history grows, or every chart needs its own cache.
- Layer 04Push surfaceWebSocket or server-sent events, never a timer.
Broken whenCharts refresh on a timer and someone presses reload to be sure.
- Layer 05ObservabilityFreshness and section usage, measured.
Broken whenNobody knows how old a number is, or which sections anyone opens.
Layer 01Event source
The CRM, ERP, product database or external API that records what happened. Events are typed, timestamped and emitted close to the business action. A dashboard that reads a nightly batch is not real time, whatever the interface says.
Layer 02Stream
Events travel through a transport you can replay: Postgres logical replication with a change-data-capture tool, a managed event service, or Kafka when the volume needs it. If the live store is rebuilt, the stream puts it back.
Layer 03Live store
Aggregated state the screen can query in milliseconds. Postgres with materialized views handles most operational workloads. A columnar store such as ClickHouse takes over when analytical queries outgrow it.
Layer 04Push surface
The browser subscribes to changes over WebSocket or server-sent events, so the screen moves when the business does instead of on a refresh timer.
Layer 05Observability
Two measurements, all the time: event-to-screen latency, shown next to each section, and which sections people open and act on. The second one is how unused sections get found and removed.
Decision first
The layers are plumbing. How the screen is composed decides whether anyone uses it.
- One role per dashboard. Operator, founder and executive views are different products. A view built for all three gets opened by none of them.
- Three sections in a fixed order. What defines success today, the leading indicators that predict it, and the anomalies that need a decision.
- Every section changes a decision. If a chart has not changed anything in a month, it goes.
- Two-second state. Colour, contrast and order tell you whether the business is fine before you read a single chart.
Freshness is set per section, and looser is cheaper. Our starting targets: within two seconds for operational alerts and queues, thirty seconds for pipeline changes, five minutes for billing, an hour for executive trends, a day for history. Most teams over-build the executive view and under-build the operational one.
Three scales, one table
The layers hold from a founder's single screen to a multi-tenant estate. What grows is the number of roles, and the access rules around them.
| Layer | Founder or small teamScale 01 | Operations team of 3 to 15Scale 02 | Enterprise or multi-tenantScale 03 |
|---|---|---|---|
| Event source | The application database and a few external APIs | Operational databases, CRM, ERP, product analytics | Databases per tenant plus shared lookups |
| Stream | Postgres logical replication with CDC | Managed CDC, or Kafka at volume | A stream per tenant, routed per region |
| Live store | Postgres with materialized views | Postgres, or a columnar store at volume | Aggregates per tenant, instances per region |
| Push surface | WebSocket through the existing app server | Channels per role with a permission layer | Channels per role, tenant and region |
| Observability | Latency and section usage | Usage per section and per role | Signed access logs, service levels per tenant |
| Cost band | CHF 15,000 to 25,000 | Up to CHF 45,000 | Scoped per case |
| Build time | A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements. | A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements. | Scoped per case |
| Live example | No named engagement yet | No named engagement yet | Not built yet |
Dashboard stack at three scales
Scale 01Founder or small team
- Event source
- The application database and a few external APIs
- Stream
- Postgres logical replication with CDC
- Live store
- Postgres with materialized views
- Push surface
- WebSocket through the existing app server
- Observability
- Latency and section usage
- Cost band
- CHF 15,000 to 25,000
- Build time
- A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements.
- Live example
- No named engagement yet
Scale 02Operations team of 3 to 15
- Event source
- Operational databases, CRM, ERP, product analytics
- Stream
- Managed CDC, or Kafka at volume
- Live store
- Postgres, or a columnar store at volume
- Push surface
- Channels per role with a permission layer
- Observability
- Usage per section and per role
- Cost band
- Up to CHF 45,000
- Build time
- A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements.
- Live example
- No named engagement yet
Scale 03Enterprise or multi-tenant
- Event source
- Databases per tenant plus shared lookups
- Stream
- A stream per tenant, routed per region
- Live store
- Aggregates per tenant, instances per region
- Push surface
- Channels per role, tenant and region
- Observability
- Signed access logs, service levels per tenant
- Cost band
- Scoped per case
- Build time
- Scoped per case
- Live example
- Not built yet
What not to build
Each of these ships quickly and leaves the team back in spreadsheets by the end of the quarter.
- Polling dressed as real time. A chart that refreshes every minute is polite, not live. The architecture makes the difference, not the interval.
- An embedded BI tool called the dashboard. It inherits the BI tool's freshness and roles, and it was built for analysts.
- One dashboard for every role. An executive view shrunk for the operator serves neither.
- Chart sprawl. Every team adds a favourite chart until nothing stands out. A dashboard that only ever grows is turning into wallpaper.
- A wall of green numbers. Thirty KPIs nobody acts on lose to one section that changes a decision each week.
Where we stand
We have no named, live dashboard engagement to show on this page. The five layers are the shape we build to.
Picture a services business that runs on weekly screenshots: Monday morning goes on compiling them, and decisions wait until midweek. A dashboard with three sections (today, this week, trends) moves the decision to the day the number changes. A fourth section that nobody opened is the first thing removed.
The place to start is a two-week Discovery Sprint: we name the five to seven decisions the dashboard has to change, set the freshness target for each, and pick the source of truth before anything is built.
Self-audit
Twelve questions for the dashboard you have today. The score updates as you tick; what the bands mean is explained once on the stacks index.
Method and pricing
The layer model, how to read the cost bands, the notes on data residency and access logs, and how these reports are versioned are shared across all five stack reports: how we write the stack reports. When a dashboard shows AI-driven signals, the same test discipline applies as for the AI itself; see the Eval Spec.