Orbit Dashboard

Why this concept exists

Orbit Dashboard is a fictional analytics product I use to explore one question: how much can a dashboard explain on its own before someone has to ask an analyst? Most dashboards answer what happened. Very few help you understand why, and almost none tell you how much to trust the number on the screen.

The problem with the usual approach

Teams usually start from charts. Someone picks a library, wires a few queries, and ships a wall of widgets. Six months later nobody remembers which chart counts refunds, which one is in UTC and which one silently drops late events. The interface looks finished, but the meaning is gone.

I wanted the opposite: start from definitions. Every metric in Orbit is a small, versioned document with a name, a formula, an owner and a freshness budget. Charts are just one way to render that document.

How it is built

• Metric registry. Definitions live in PostgreSQL next to the data they describe, so a migration that changes a column also has to update the metric that depends on it.
• Query layer. A thin TypeScript service compiles definitions into SQL with explicit time zones and explicit handling of late data. Results are cached in Redis with keys derived from the definition version, so a change to a formula can never serve a stale answer.
• Interface. The frontend is a Next.js app rendered on the server. Each panel shows the value, the comparison period, the freshness of the data and a one-line plain-language definition.

Design decisions worth sharing

Freshness is part of the value

A number without a timestamp is a rumor. Every panel shows when its data was last complete, and panels fade to a warning state when they exceed their freshness budget. This one change removed most of the "is this broken?" messages in the concept's test sessions.

Comparisons are opinionated

Instead of letting every viewer pick any date range, each metric declares its natural comparison: week over week for traffic, month over month for revenue, cohort against cohort for retention. Fewer knobs, fewer wrong conclusions.

Drill-downs never leave the context

Clicking a value opens a side panel with the breakdown and the exact query parameters, instead of navigating away. People can share a link to that precise state, which turns screenshots in chat into reproducible questions.

What I would do next

The next experiment is annotations written by the system itself: when a metric moves beyond its usual band, the dashboard would list the deploys, incidents and campaigns that happened in the same window. The goal is not to replace analysts, but to give them better first questions.

Notes

This is a design and engineering concept with invented data. The numbers, users and test sessions described here are fictional and exist only to show how I approach a problem like this.