A dashboard is the easiest software to build and the hardest to make useful. Most get built, shown around for a week, and then quietly abandoned — the browser tab nobody opens, the screen on the wall everyone has stopped seeing. The reason is almost never the technology. It is that the dashboard was designed around the data that was easy to pull, rather than the decisions someone actually has to make.
Start from the decision, not the chart
The first question is never what should we show. It is: who will do something differently because of this screen, and how often? A dashboard that does not change a decision is a screensaver with numbers on it. Before anyone opens a charting library, write down the two or three decisions the dashboard exists to support — reorder stock, chase an overdue account, move a technician, escalate a slipping project — and the person who makes each one.
Once the decision is explicit, the design follows almost mechanically. You know how fresh the data has to be, what good and bad look like at a glance, and what action a red number should trigger. A dashboard built this way is small and opinionated. One built from the data outward is large, neutral, and ignored, because it leaves every act of interpretation to a busy person who does not have time for it.
A useful test is to sketch the dashboard before you have any data — on paper, with the numbers invented. If the fake version does not obviously push someone to act, no amount of real data will save it. Where each number sits, which one is largest, what turns red and at what threshold — those choices are made with a marker, not in the tool. We have seen more dashboards rescued by an hour at a whiteboard than by a month of engineering.
One number, one source of truth
Trust in a dashboard dies the first time two screens disagree. Someone notices that revenue in the sales view does not match revenue in finance, and from that moment every number is suspect. The cause is almost always that the same metric is computed two different ways, in two different systems, by two people who each believe theirs is correct.
So the hard part of a dashboard is rarely the visualisation — it is agreeing what each metric means before you draw it. What counts as an active customer? Does revenue include tax, refunds, intercompany transfers? When does a deal become closed? These definitions belong in one place, applied once, so every chart draws from the same computation. This is what people mean by a single source of truth, and it is unglamorous, upstream work that quietly determines whether the whole thing is believed.
This also means someone has to arbitrate. When sales and finance define revenue differently, the answer is not to average them or show both — it is to decide, once, which definition the dashboard uses and why, and to make that choice visible so nobody relitigates it every quarter. A metric definition that lives in one documented place, owned by one person, is worth more than a cleverer chart. The companies that trust their numbers are the ones that did this boring work up front.
A dashboard is not a report
These two words get used interchangeably and should not be. A report is a document you read — a monthly close, a board pack, a detailed export someone studies and annotates. A dashboard answers a live question: is anything wrong right now, and are we on track? One is for analysis, the other for monitoring, and they want opposite things. A report can be dense, footnoted, and slow. A dashboard has to be readable in the five seconds someone gives it between meetings.
When you blend them, you get the worst of both: a monitoring screen too heavy to scan and a report too shallow to trust. Decide which job the artefact is doing. If people need to explore and slice the data, build a proper reporting layer. If they need to glance and act, build a dashboard — and keep the depth one click away rather than on the front page.
A practical tell is what people do with the artefact. If they screenshot it into a deck once a month, you built a report. If they glance at it between other tasks and occasionally act, you built a dashboard. Build the one they actually need, and do not apologise for making it smaller than the room asked for.
Too many metrics kill it
Every stakeholder wants their number on the screen, and the path of least resistance is to say yes to all of them. The result is a wall of forty tiles that communicates nothing, because a screen that emphasises everything emphasises nothing. Attention is the scarce resource, not display space.
A dashboard that gets used tends to show a handful of things that matter and hide the rest until asked for. The discipline is subtraction: for every metric, ask what decision it changes, and if the honest answer is none, it is just interesting, it belongs in a report, not on the front screen. Interesting is the enemy of useful here. The best operational dashboards we have built could be read from across a room, precisely because someone was willing to leave things off.
Subtraction is also a political act, which is why it is hard. Every removed tile is a conversation with the person who asked for it, and the easy path is to avoid that conversation and keep the tile. A dashboard owner who can say no — kindly, with a reason — is worth more to the finished product than any feature. The screens that stay useful are the ones somebody defended from becoming a dumping ground.
Real-time is rarely the requirement
Real-time gets asked for by default and needed by exception. It is one of the most expensive properties a dashboard can have — streaming pipelines, live connections, caching, and a whole class of failure modes that batch data never has — and for most business decisions it changes nothing. If you review a number every morning and act daily, data that is fresh as of last night is not a compromise, it is the correct answer.
The honest test is to name the decision that genuinely needs sub-minute data. A dispatcher moving crews, a fraud check, a trading position — those exist. Weekly revenue, pipeline health, project margin — those do not. Match the data freshness to the tempo of the decision, and you will often find that good enough, refreshed hourly or nightly, buys you a far simpler and more reliable system for a fraction of the cost.
There is also a subtler cost. A dashboard refreshed every few seconds invites people to watch it, and watching a number twitch is not the same as managing by it. For the rare decisions that genuinely need immediacy, an alert that fires when a threshold is crossed usually beats a live screen someone has to stare at — it respects the fact that nobody can watch a dashboard all day. Reserve real-time for where a human truly acts on the second, and let everything else settle into a calmer rhythm.
Off-the-shelf BI or a custom build
Most companies do not need a bespoke dashboard, and it is fair to say so. Tools like Power BI, Metabase, or Looker connect to your data, let a capable analyst assemble views quickly, and cost a fraction of custom development to start. If your need is reporting and monitoring over data that already lives in a warehouse, that is usually where to begin, and we will tell you so.
Custom earns its place when the dashboard stops being a viewer and becomes part of an operation — when people need to act from it, not just look at it. Writing back to source systems, embedding it inside your own product for customers, wiring in permissions your business defines rather than the ones a BI tool ships with, or blending a live operational feed with historical data. The honest framing is a spectrum: off-the-shelf is faster and cheaper until the workarounds pile up, and the moment you are fighting the tool more than using it is the moment a focused custom build pays for itself.
In practice the answer is often a mix, and that is fine. A BI tool can serve the analysts exploring history while a small custom surface gives operators the two live numbers and the one button they act on. Naming that split early — what belongs in the flexible reporting layer and what belongs in the focused operational view — usually costs less and ages better than forcing either tool to do the other's job.
Someone has to own it
A dashboard is not a project that ships once. Definitions drift, a source system changes a field, a metric that mattered last quarter stops mattering. Without a named owner — one person accountable for what the numbers mean and whether they are still the right numbers — even a good dashboard rots into something people distrust and route around. Ownership is a design decision, not an afterthought.
Ownership also keeps the dashboard honest as the business changes. A source system quietly renames a field, a definition shifts, a target that was ambitious becomes routine — and without someone watching, the numbers keep rendering while slowly ceasing to mean what people think they mean. The most dangerous dashboard is not the one that breaks visibly; it is the one that keeps showing confident numbers that are quietly wrong.
If you are weighing a real reporting or BI build, the cheapest way to avoid the abandoned-dashboard outcome is to start with a short assessment: the decisions it must drive, the state of your data, the metric definitions people can actually agree on, and an honest recommendation on whether an off-the-shelf tool or a custom build fits. A couple of weeks spent there is what turns a screen people admire into a screen people act on.