The Tyranny of the Dashboard

Every B2B SaaS product ships with a dashboard. Usage charts, activity feeds, summary cards with arrows pointing up or down. The screenshots look great in pitch decks. Product tours always start here. "This is your dashboard," the onboarding says, as if you've been given the cockpit of a 747.

But here's what most dashboards actually are: decoration.

The Dashboard Industrial Complex

Somewhere in the evolution of software, we decided that the first thing a user should see after logging in is a wall of charts. Not the thing they came to do. Not the action that drove them to open the app. A dashboard.

This happens because dashboards are easy to design, hard to argue against, and satisfying to build. They feel like product. They look like value. They screenshot well for marketing. Nobody in a product review meeting has ever said "do we actually need this dashboard?" because the answer seems self-evident.

But watch what users actually do: they glance at the dashboard for two seconds, then navigate to the thing they came to use. The dashboard is a lobby they walk through, not a room they sit in.

What Dashboards Replace

The problem isn't dashboards themselves — it's what they displace. Every hour spent designing chart layouts is an hour not spent on the core workflow. Every sprint building dashboard widgets is a sprint not improving the tool people actually use.

Stripe doesn't need a dashboard to be valuable. The value is in the payment processing. Linear's most used view isn't a dashboard. It's the issue list. Figma's most used view isn't a dashboard. It's the canvas. GitHub's most used view isn't a dashboard. It's the code.

The best products put the work first, not the metrics about the work.

When Dashboards Earn Their Space

Some dashboards are genuinely useful. They share common traits:

• They surface actionable anomalies. Not "here's your data," but "something changed and you should look at it." Your cron job monitoring dashboard does this well. The dashboard exists to show you when something is wrong, not to remind you that things are working.
• They answer a specific question. "How many invoices did we generate this month?" is a specific question. A dashboard that answers it is useful. "Here are twelve metrics about your account" answers no question — it just fills a page.
• They change behavior. If looking at the dashboard never causes you to do something different, the dashboard is theater.

The Alternative

Start with the action. When someone opens your tool, show them the thing they came to do. A text editor should open to a document. A project manager should open to the task list. An API product should open to the API keys and documentation.

Push, don't pull. Instead of making users check a dashboard for problems, send them a notification when something needs attention. The best monitoring is the kind you don't have to remember to check.

Earn the chart. Before adding any visualization, ask: "What decision will someone make differently after seeing this?" If you can't answer that clearly, the chart is decoration.

Building Without Dashboards

At Anethoth, none of our four products have user-facing dashboards. DocuMint shows your API key and usage count. CronPing shows your monitors and their status. FlagBit shows your flags and their rules. WebhookVault shows your endpoints and captured requests.

No charts. No activity feeds. No "your account at a glance." Just the tools, ready to use.

Maybe we'll add dashboards eventually. But only when we can answer the question: "What will users do differently after seeing this?"

Until then, the best dashboard is no dashboard.