A dashboard nobody trusts is worse than no dashboard
Operational reporting is the easiest thing to generate and the hardest to get right, because the failure is silent.
- Two people quote different numbers for the same metric in the same meeting.
- The dashboard takes more than a few seconds to load, so nobody opens it.
- Reporting queries run against the same database that serves your users.
- Numbers change depending on who is looking or what timezone they are in.
- Somebody still exports to a spreadsheet before presenting anything.
Where a generated prototype stops being enough
Not general advice. These are the failures specific to this kind of product, and none of them are visible on screen.
- 01
Nobody wrote down what the metric means
Does an active user mean signed in this month, or performed an action?
- 02
Reporting queries and user traffic share a database
An aggregate over every row of a large table is a heavy query.
- 03
Timezones and currency are where the numbers quietly go wrong
Rows stored in UTC and grouped by local day produce a daily total that is right for nobody.
- 04
Nothing is checked, so errors persist
A pipeline that silently drops rows, a join that duplicates them, a filter that excludes a status nobody remembers.
The sentences we hear most, and what we do about each one
"Two of my managers have different numbers"
The immediate assumption is that one query is broken. Usually both are correct and they are answering slightly different questions, because the metric was never defined - only implemented, twice.
How we helpA written metric definition per number: the exact filter, the time basis, the grain, and who owns it.
"Loading the dashboard slows down the app"
It is the same database. A full-table aggregate acquires enough resources that customer requests queue behind it, and the correlation is hard to spot because nobody connects the slow app to somebody opening a chart.
How we helpReporting moves off the primary - a read replica, or pre-aggregated tables refreshed on a schedule.
"It takes 40 seconds to load so nobody uses it"
A dashboard that is slow is a dashboard that does not exist.
How we helpPre-aggregation, indexes chosen from real query plans, and caching with an explicit freshness contract shown in the interface. "As of 09:00" is a better product than a spinner, and most operational decisions do not need the last four minutes.
"I do not know if these numbers are right"
The corrosive one. Once trust is gone, every number gets independently re-derived in a spreadsheet and the dashboard becomes decoration.
How we helpReconciliation checks that run on a schedule and alert when a metric moves more than it should, when row counts diverge from source, or when a pipeline drops records.
The parts that make it hold
A metric layer
Each metric defined once, in one place, with its filters, grain and owner.
Reporting off the hot path
Read replica or scheduled pre-aggregation, so opening a dashboard cannot slow the product down.
Correct time and money
Explicit timezone handling per report, currency converted at transaction time, and fiscal periods that match how the business actually counts.
Freshness stated, not implied
Every panel says what it is as of. Cached where cheap, live where it matters, and never ambiguous about which.
Drill-through to the rows
Every number opens into the records behind it. This is what makes a dashboard trustworthy rather than merely correct.
Scheduled delivery and alerts
The weekly report arrives by email or Slack, and a threshold breach notifies a person instead of waiting to be found.
Usually connected to
- Warehouse: BigQuery, Snowflake, Postgres read replica
- Transformation: dbt or scheduled SQL, version-controlled
- Sources: Stripe, HubSpot, Salesforce, your product database
- Delivery: Slack, email, scheduled exports
- Existing BI: Metabase, Looker Studio, where it is genuinely enough
In the order it actually happens
Growth does not break everything at once. For this kind of product it breaks these four things, in this sequence, and each one is cheap to fix before it happens.
| At | What breaks | becomes | The fix |
|---|---|---|---|
| Second person building a chart | Two definitions of the same metric | A written metric layer with one implementation | |
| ~1M rows | Aggregates lock tables and slow the product | Read replica or scheduled pre-aggregation | |
| First multi-region or multi-currency data | Daily totals and revenue silently wrong | Explicit timezone per report, rate captured at transaction time | |
| Any pipeline | Rows dropped or duplicated with no signal | Scheduled reconciliation with alerting on divergence |
Four phases, each ending in something you keep
The first one is free. Scope is fixed after it, and you keep the findings whatever you decide next.
- 013–5 days
Metric review
Free. We reconcile the numbers on your dashboard against the source data and find where they disagree - with each other, and with reality.
You receive
- Reconciliation report per metric
- Written definitions for the metrics that had none
- Query performance profile against real volumes
- Ranked plan with effort estimates
- 021–2 weeks
Definitions and the metric layer
Metrics are defined once, implemented once and version-controlled, so a change is reviewed rather than discovered.
You receive
- Metric layer with definitions, grain and owners
- One implementation consumed by every chart and export
- Timezone and currency handling made explicit
- 031–2 weeks
Get it off the hot path and make it fast
Reporting moves to a replica or pre-aggregated tables, with caching and a stated freshness contract.
You receive
- Read replica or scheduled aggregation pipeline
- Indexes from real query plans
- Caching with freshness shown in the interface
- Drill-through from every number to its rows
- 041 week, plus 30 days support
Trust and delivery
Reconciliation checks, alerting, scheduled delivery, and documentation of what each number means.
You receive
- Scheduled reconciliation with alerts on divergence
- Report delivery to email or Slack
- Metric documentation the business can read
- 30 days of post-launch support
Before you book the call
Often yes, and we will say so. A commercial BI tool over a well-modelled read replica beats a custom dashboard for most businesses.
Below roughly ten million rows, usually not - a read replica and some scheduled aggregation is simpler, cheaper and faster.
They generate charts very well and definitions not at all, which is exactly the wrong way round.
Related solutions
Business internal tools
The admin panel, ops console or back office that the business now depends on.
See what breaksCustomer portals
Where your customers log in to see their own data - and only their own.
See what breaksField service management
Dispatch, job tracking and a technician app that has to work in a basement.
See what breaks
Building operations dashboards?
The first review is free, and it ends with a straight answer - including when the answer is to buy something off the shelf instead.