Tutorials Data

Dashboard Design for Startups: Why 3 Dashboards Beat 30 (and How AI Builds Them in Minutes)

What is startup dashboard architecture?

Startup dashboard architecture is a three-tier system that organizes business metrics by audience and decision-making frequency rather than by data availability. The three tiers are: Executive (reviewed weekly by leadership — revenue, runway, CAC/LTV, churn), Product (reviewed daily by the product team — activation, retention curve, funnel, DAU/MAU), and Engineering (real-time by the on-call team — latency percentiles, error rate, DORA metrics). Each dashboard answers one question for one audience and limits itself to 6–8 metrics with targets, trends, and alerts.

TL;DR

  • -The average Series A startup accumulates 15–40 dashboards; only 3–5 get regular views — the rest go stale within 2 weeks of creation
  • -Executive dashboard: maximum 8 metrics, MRR must show new/expansion/churn breakdown — a single MRR number masks high churn behind overall growth
  • -Product dashboard: retention must be a cohort heatmap, not a line chart — a line chart loses the cross-cohort context that reveals onboarding quality changes
  • -Engineering dashboard: always show latency as P50/P95/P99 — the median hides the 5% of users (often highest-paying) experiencing P95 > 2 seconds
  • -Pie charts are banned — humans compare angles poorly; a horizontal bar chart conveys the same information with higher accuracy

The average Series A startup accumulates 15 to 40 dashboards, of which 3 to 5 get regular views. The rest go stale within two weeks of creation. The problem isn’t missing data. It’s missing organization.

Three dashboards cover 90% of a startup’s needs from pre-seed to Series B: Executive, Product, and Engineering. Below are the specific metrics for each, SQL queries, and ready-made prompts for Metabase and Grafana.

Why Dashboards Fail at Startups

The typical scenario: the CTO builds a dashboard for an investor update. The product manager assembles their own set of charts. The data analyst builds a third one for marketing. A month later, nobody remembers which dashboard is current. Two months later, everyone builds new ones.

The root cause is the absence of a dashboard architecture. Each dashboard gets created for a specific request, not as part of a system. The result:

Metric duplication. Revenue appears in three places with three different definitions. One shows gross revenue, another shows net, a third shows MRR. Nobody knows which number is right.

Information noise. 50 charts on one screen. Nothing catches the eye. Anomalies get lost among normal fluctuations.

No actionability. A chart shows declining retention. What do you do? The dashboard doesn’t say. You need a second dashboard to dig in. Then a third. The analysis chain breaks.

The solution: three dashboard levels, each for its own audience, with a clear set of metrics and a defined viewing frequency.

┌──────────────────────────────────────────────────────┐
│              Dashboard Architecture                   │
├──────────────┬──────────────┬────────────────────────┤
│  Executive   │   Product    │     Engineering        │
│  (Weekly)    │   (Daily)    │     (Real-time)        │
├──────────────┼──────────────┼────────────────────────┤
│  Revenue     │  Activation  │  Uptime / SLA          │
│  Burn rate   │  Retention   │  Latency P50/P95/P99   │
│  Runway      │  Engagement  │  Error rate            │
│  CAC / LTV   │  Conversion  │  Deploy frequency      │
│  Growth rate │  NPS / CSAT  │  Incident count        │
└──────────────┴──────────────┴────────────────────────┘

Executive Dashboard: Metrics for Decision-Making

The Executive dashboard gets reviewed by the CEO, CFO, and board once a week. The goal is to answer one question: is the business moving in the right direction?

Maximum 6 to 8 metrics. Each metric has a target, current value, and trend. No raw data tables.

Required Metrics

MRR (Monthly Recurring Revenue). The primary metric for SaaS. Display it with a breakdown: new MRR, expansion MRR, churned MRR, net new MRR. Without the breakdown, the number is useless. MRR growth can mask high churn.

-- Net New MRR breakdown (PostgreSQL)
WITH mrr_changes AS (
  SELECT
    date_trunc('month', event_date) AS month,
    SUM(CASE WHEN type = 'new' THEN amount ELSE 0 END) AS new_mrr,
    SUM(CASE WHEN type = 'expansion' THEN amount ELSE 0 END) AS expansion_mrr,
    SUM(CASE WHEN type = 'contraction' THEN amount ELSE 0 END) AS contraction_mrr,
    SUM(CASE WHEN type = 'churn' THEN amount ELSE 0 END) AS churned_mrr
  FROM subscription_events
  WHERE event_date >= date_trunc('month', NOW()) - INTERVAL '12 months'
  GROUP BY 1
)
SELECT
  month,
  new_mrr,
  expansion_mrr,
  contraction_mrr,
  churned_mrr,
  (new_mrr + expansion_mrr + contraction_mrr + churned_mrr) AS net_new_mrr
FROM mrr_changes
ORDER BY month;

Burn Rate and Runway. How much the company spends per month and how many months of cash remain. Runway below 6 months is a signal for immediate action. Formula: runway = cash_balance / avg_monthly_burn_last_3_months.

CAC and LTV. Customer Acquisition Cost and Lifetime Value. An LTV/CAC ratio below 3 means the business model doesn’t work. Display both numbers side by side with the ratio.

Growth Rate (MoM). Monthly growth as a percentage. For early-stage startups, a healthy figure is 15 to 20% MoM. Display as a line chart over the past 12 months with a target zone.

Churn Rate. Percentage of users/revenue lost in a month. For B2B SaaS, healthy logo churn stays below 2% per month (under 20% annually); revenue churn below 1% per month.

Cash Balance. Current balance across accounts. A simple number with a 6-month trend.

Executive Dashboard Anti-Patterns

Vanity metrics. Total registered users ever, all-time cumulative revenue, total downloads. These numbers only go up and say nothing about business health. Remove them without hesitation.

Too much detail. Revenue broken down into 20 segments, funnels with 12 steps. The Executive dashboard answers “where are we going,” not “why exactly this way.” Details belong in the Product dashboard.

Product Dashboard: Funnel, Retention, Engagement

The product manager opens the Product dashboard every morning. The goal is to understand how users interact with the product, where they drop off, and what’s working.

Required Metrics

Activation Rate. The percentage of new users who reach the “aha moment.” The definition depends on the product. For Slack, that’s sending 2,000 messages as a team. For Dropbox, it’s saving the first file. Define your activation event and track conversion to it.

-- Activation rate by cohort (weekly)
WITH signups AS (
  SELECT
    user_id,
    date_trunc('week', created_at) AS cohort_week
  FROM users
  WHERE created_at >= NOW() - INTERVAL '12 weeks'
),
activated AS (
  SELECT DISTINCT e.user_id
  FROM events e
  JOIN signups s ON e.user_id = s.user_id
  WHERE e.event_name = 'activation_event'
    AND e.created_at <= s.cohort_week + INTERVAL '7 days'
)
SELECT
  s.cohort_week,
  COUNT(DISTINCT s.user_id) AS total_signups,
  COUNT(DISTINCT a.user_id) AS activated_users,
  ROUND(COUNT(DISTINCT a.user_id)::numeric / COUNT(DISTINCT s.user_id) * 100, 1) AS activation_rate
FROM signups s
LEFT JOIN activated a ON s.user_id = a.user_id
GROUP BY s.cohort_week
ORDER BY s.cohort_week;

Retention Curve. Cohort retention tracks the percentage of users returning on day/week N after registration. Display it as a heatmap: cohorts on the vertical axis, time periods on the horizontal. A healthy retention curve flattens to a plateau. If the curve drops to zero, the product isn’t retaining users.

Conversion Funnel. Steps from first visit to payment. Maximum 5 to 6 steps. At each step, show the absolute number and conversion rate. The step with the largest drop-off is the product team’s priority.

DAU/WAU/MAU and DAU/MAU ratio. The DAU/MAU ratio (stickiness) shows how regularly users return. For B2B SaaS, a normal value is 20 to 25%. For consumer apps it depends on category (messengers 50%+, e-commerce 10 to 15%).

Feature Adoption. The percentage of active users who have used a specific feature. Helps identify which features people genuinely need and which add complexity without value.

Product Dashboard Visualization

Retention: heatmap or cohort table only. A line chart of retention for a single cohort loses context.

Funnel: horizontal. Each step with an absolute number and drop-off percentage, not conversion from the previous step. Drop-off focuses attention on problem areas.

DAU/MAU: line chart with a target zone. Not a bar chart. The trend matters more than absolute values.

Engineering Dashboard: Uptime, Latency, Deploys

The Engineering dashboard runs in real time. The on-call engineer, tech lead, and CTO watch it. The goal is to detect degradation instantly and assess development velocity.

Required Metrics

Uptime / SLA. Percentage of time without incidents. Standard SLA for SaaS is 99.9% (allowable downtime: 8.7 hours per year). Display current status (UP/DOWN), uptime for the current month, and rolling 30 days.

Latency P50/P95/P99. The median doesn’t surface problems. 5% of users experiencing P95 > 2 seconds might be your highest-paying customers. Always display three percentiles. P99 sharply above P95 signals problems with specific endpoints or users.

# Grafana / Prometheus: latency percentiles
histogram_quantile(0.50, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Error Rate. Percentage of requests returning HTTP 5xx. Normal: below 0.1%. Alert threshold: 1%. Display as a time series with deploy annotations. The correlation between a deploy and a spike in errors becomes immediately visible.

Deploy Frequency. Number of deploys per day/week. One of the four DORA metrics. High deploy frequency correlates with high team performance. Display as a bar chart by day.

MTTR (Mean Time To Recovery). Average time to recover from an incident. The second key DORA metric. For high-performing teams: under 1 hour. Display as a line chart with a 3-month trend.

Incident Count. Number of incidents by severity: critical, major, minor. 3-month trend. A rising trend alongside a growing system is normal. A rising trend in a stable system signals technical debt.

DORA Metrics in the Engineering Dashboard

The four DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR) deserve their own section. They show engineering process efficiency, not system health.

┌────────────────────────────────────────────────────────────┐
│                    DORA Metrics                             │
├───────────────┬───────────────┬──────────────┬─────────────┤
│  Deploy Freq  │  Lead Time    │ Change Fail  │    MTTR     │
│  12/week      │  2.3 days     │    4.2%      │   47 min    │
│  ▲ vs target  │  ▼ vs target  │ ✓ vs target  │ ✓ vs target │
│  (10/week)    │  (1 day)      │   (<15%)     │   (<1 hr)   │
└───────────────┴───────────────┴──────────────┴─────────────┘

Prompts for Metabase and Grafana

Building a dashboard by hand takes hours. Below are prompts for GPT-5.4 and Claude that generate configs and SQL queries.

Executive Dashboard in Metabase

You are a data analyst at a B2B SaaS startup. Generate SQL queries for Metabase
(PostgreSQL) for an Executive Dashboard.

Database schema:
- users (id, created_at, plan, status)
- subscriptions (id, user_id, mrr, started_at, cancelled_at, plan)
- payments (id, user_id, amount, created_at, type)
- expenses (id, amount, category, date)

Metrics:
1. MRR with breakdown (new, expansion, contraction, churn) for 12 months
2. Burn rate (3-month average) and runway
3. CAC (marketing spend / new customers) for 6 months
4. LTV (average revenue per user * average lifetime)
5. MoM growth rate
6. Logo churn rate by month

For each metric:
- SQL query compatible with Metabase
- Recommended visualization type
- Suggested alert threshold

Product Dashboard in Metabase

You are a product analyst. Generate SQL queries for a Product Dashboard in Metabase.

Schema:
- users (id, created_at, last_active_at)
- events (id, user_id, event_name, properties, created_at)
- sessions (id, user_id, started_at, duration_seconds, pages_viewed)

Activation event: "completed_onboarding"

Metrics:
1. Activation rate by weekly cohorts (conversion to activation event
   within the first 7 days)
2. Retention heatmap: cohorts by week, retention on Day 1, 7, 14, 30
3. Conversion funnel: visit → signup → onboarding_start →
   completed_onboarding → first_payment
4. DAU/WAU/MAU and stickiness (DAU/MAU)
5. Feature adoption rate for top-5 events

Format: SQL + visualization type + description of what the metric shows.

Engineering Dashboard in Grafana

You are an SRE engineer. Generate a Grafana dashboard configuration (JSON model)
for an Engineering Dashboard.

Datasources:
- Prometheus (application and infrastructure metrics)
- Loki (logs)

Metrics:
1. Uptime: probe_success from blackbox exporter, SLA over rolling 30 days
2. Latency: http_request_duration_seconds_bucket — P50, P95, P99
3. Error rate: rate(http_requests_total{status=~"5.."}[5m]) /
   rate(http_requests_total[5m])
4. Deploy frequency: annotations from CI/CD (deploy events)
5. MTTR: average duration of alerts in "firing" state
6. Incident count by severity: count from alertmanager

For each panel:
- PromQL query
- Panel type (stat, timeseries, gauge, table)
- Thresholds for color coding (green/yellow/red)
- Recommended alert rule

How to Adapt the Prompts

The prompts above are templates. For a specific startup, substitute:

  1. The database schema. Real table and column names. AI generates more accurate SQL against a concrete schema than when rewriting abstract queries.

  2. The activation event definition. Each product has its own. Plug in the specific event from your analytics.

  3. Business context. B2B vs B2C, average contract value, sales cycle. All of these affect metric selection and thresholds.

  4. Datasource specifics. PostgreSQL vs ClickHouse vs BigQuery. Different SQL syntax for window functions and date manipulation.

Visualization Principles

One metric, one question. Each chart answers one question. “Is MRR growing?” gets a line chart. “Which funnel step loses the most users?” gets a funnel with drop-off. “Is latency normal right now?” gets a gauge with color zones.

Context is always nearby. A number without context is meaningless. MRR $50K: good or bad? Add a target ($60K), previous period ($45K), trend (11% MoM growth). Now it’s clear: MRR is growing, but below target.

Color = signal. Green means normal. Yellow means needs attention. Red means action required. Don’t use color for decoration. Don’t use more than three colors on a single chart. Color blindness affects roughly 8% of men. Back up color with a text label.

Pie charts are banned. Humans are poor at comparing angles. A horizontal bar chart conveys the same information more accurately. The only exception is two categories (a 50/50 split), and even then a stacked bar chart works better.

Mobile-first layout. The CEO checks the dashboard on a phone in a taxi. Key metrics go at the top, large font. Detailed charts sit below, scrollable. Both Metabase and Grafana support responsive layouts.

Automation: Alerts and Scheduled Reports

A dashboard nobody opens is useless. Two mechanisms solve this.

Anomaly alerts. Set threshold alerts for critical metrics:

  • MRR drop > 10% MoM → Slack #revenue
  • Error rate > 1% for 5 minutes → PagerDuty
  • Runway < 6 months → email CEO + CFO
  • Activation rate drop > 20% WoW → Slack #product

In Metabase, alerts are created through the UI: open a question → Alert → set the condition and channel. In Grafana, use alert rules with contact points.

Scheduled reports. Weekly delivery of the Executive Dashboard to Slack or email. In Metabase: Dashboard → Sharing → Schedule. In Grafana: Reporting (Enterprise) or export via API + cron.

The combination of push (alerts) and pull (dashboard) covers both scenarios: urgent problems arrive instantly, regular reviews happen on schedule.

Final Checklist

Before launching all three dashboards, work through these items:

Executive Dashboard:

  • 6 to 8 metrics, each with a target and trend
  • No vanity metrics (total users, total downloads)
  • MRR with breakdown, not just a single number
  • Runway and burn rate displayed together
  • Weekly delivery configured

Product Dashboard:

  • Activation event defined and documented
  • Retention as a cohort heatmap
  • Funnel showing drop-off, not just conversion
  • DAU/MAU ratio with a target zone
  • Alert on activation rate drops

Engineering Dashboard:

  • Latency with three percentiles (P50/P95/P99)
  • Error rate with deploy annotations
  • DORA metrics in a separate section
  • Error rate and uptime alerts wired to PagerDuty
  • MTTR tracked automatically

Three dashboards. Concrete metrics. Prompts for generation. This is enough for decision-making from pre-seed to Series B. Start with executive: it shows how healthy the business is. Add product: it shows how to grow the product. Connect engineering: it shows how not to break what’s been built.

If you’re running LLMs in production and need observability for AI components, the Langfuse guide covers tracing, cost tracking, and prompt management.

Need help building startup dashboards? I help startups build AI products and automate processes — belov.works.

FAQ

Should the Executive dashboard show real-time or delayed data?

Delayed — and intentionally so. Executive dashboards refreshing in real time create noise and anxiety around normal intraday fluctuations. Weekly-cadence data with day-over-day and week-over-week comparisons is appropriate for decisions made on a weekly cycle. Real-time data belongs on the Engineering dashboard, where the on-call engineer needs to see a latency spike within seconds of it occurring.

What’s the right threshold for an activation rate alert in Metabase?

Alert at a 20% week-over-week drop relative to the 4-week rolling average — not against a fixed number. Absolute activation rate varies with traffic source mix: a week with heavy paid traffic will show lower activation than a week dominated by referral traffic. Percentage-drop alerts on a rolling baseline automatically normalize for traffic composition changes and fire only when something genuinely breaks in the onboarding flow.

How do DORA metrics help a startup that doesn’t yet have SLAs or formal incident processes?

They establish a baseline before you need one. A startup tracking deploy frequency and MTTR from day one builds the historical data that lets it detect when technical debt starts slowing down velocity — typically around 20–30 engineers when informal coordination breaks down. The DORA data also becomes a credible signal during Series B due diligence, where engineering process maturity is increasingly scrutinized alongside product metrics.