Our dashboard development work takes numbers that currently live in three or four systems and puts them on one screen that someone opens every morning. We build custom dashboards for UK businesses on Laravel and React, connected directly to the CRM, accounting package, job system or database the figures already sit in, so nobody has to assemble a spreadsheet before the Monday meeting.
Why Most Dashboards Get Abandoned
Most commissioned dashboards follow the same arc. They’re delivered, admired, opened daily for a fortnight, weekly for a month, and then left alone.
The charts are rarely the cause. The usual problem is a dashboard built to display data when it should have answered a question. Everything measurable is on it, nicely arranged, and nothing on it makes anyone do something differently. Nobody would notice if a figure went wrong, so after a few months some of them have.
The ones that survive have something in common: somebody has a question they need answered every week, and the dashboard answers it faster than the alternative.
Check the Data Before the Design
Before deciding what a dashboard should show, find out whether the records underneath are good enough to show anything. If they’re incomplete or kept in several places that conflict, a dashboard makes that visible without fixing it. People then blame the dashboard instead of the data, and a project that exposed the real problem gets judged a failure.
Sometimes the right first project is fixing how data gets captured, with the dashboard second. When that’s the case we say so before quoting for the dashboard.
What You Get
- A dashboard built around one or two recurring questions, for a named role
- Connections to your existing systems through their APIs, live where it matters and nightly where it doesn’t
- Exception highlighting, so the screen shows what needs attention and stays quiet otherwise
- Click-through from every figure to the records behind it
- A visible “last updated” time on each number
- Logins and permissions, so each role sees its own view
- Snapshots stored from day one if you’ll want trends later
- Monitoring that tells us when a data source stops feeding it
Custom Dashboards We Build
Most projects take one of three shapes. An operational dashboard is the live view a team works from during the day: jobs at risk, orders waiting, stock running low, tickets past their deadline. A reporting dashboard replaces the weekly or monthly report someone compiles by hand for management and finance. The third kind is client-facing, giving your own customers a logged-in view of their account, project or results.
We run that last kind ourselves. Our client dashboard is the system Digital Royalty uses with its own clients, so most of the problems you’ll meet with a client-facing view are ones we’ve already had to solve.
We’ve built the other kinds for clients too. A lead-generation business works from live views of its visitors and its funnel, built on its own first-party tracking, which links an anonymous visit to the enquiry it later becomes. For a legal-marketing platform we built the client-facing kind: UK law firms log in to see their website performance, search visibility and reviews alongside their competitors’.
Power BI or a Custom Build
If you only need to look at your numbers, Power BI or a well-built spreadsheet will usually get you there faster and for less, and we’ll tell you so. A custom dashboard is worth paying for when people need to act from the screen (approving a request or reassigning a job), when the data sits in systems those tools can’t reach, or when customers will log in to see it. The longer argument is in custom dashboard vs Power BI, and if a scheduled email would answer the question, dashboard vs report compares the two.
What Makes One Get Used
The dashboards that get used answer a question that comes round every week, such as which jobs are at risk or how the month compares with target. One clear question beats twenty metrics.
They also show exceptions. Nobody can scan twenty numbers for anomalies, so a screen that highlights what’s unusual and stays quiet otherwise gets read, while one that shows everything gets ignored.
Each figure should lead somewhere. Knowing three jobs are overdue is useful, and clicking through to those three jobs is what makes the dashboard part of the working day. We also build for one role at a time, because a view meant for management and finance at once rarely suits either.
None of that helps if people doubt the figures. A single wrong number that nobody can explain is usually enough for them to stop checking.
What Moves the Price
The biggest factor is how many systems the data comes from and whether they have usable APIs. On most dashboard projects that connection work is the bulk of the effort and the charts are the easy part, which is why our API integration work usually sits underneath a dashboard build.
How current the figures have to be comes next. Overnight refreshes are straightforward, while live figures change the architecture.
Reconciliation can be expensive. If two sources give different numbers for the same thing, something has to decide which is right, and that logic becomes the real product.
Each extra role needing its own view adds scope, and so does history. Showing today is simpler than showing a trend, which needs snapshots stored from the start.
Where These Projects Go Wrong
The common failures are commissioning everything anyone might want (delivered slowly, opened rarely), figures with no route back to the records so nobody can investigate them, refresh rates nobody agreed so someone acts on yesterday’s number, and no owner after launch, which means a figure can be wrong for weeks before anyone notices.
Questions to Ask Whoever Builds It
- What decision does this support, and who makes it?
- What would make somebody open it on a Tuesday morning?
- How current is each number, and does the screen say so?
- Can I click a figure and see the records behind it?
- What happens when a number looks wrong?
A Brief You Can Send Anyone
Whoever you ask to quote, give them answers to these and the estimate will be much closer to the final bill:
- The question this answers, in one sentence
- Who opens it, and how often
- What they’ll do differently as a result
- Where the data lives, and whether those systems have APIs
- How current it needs to be: live, hourly or overnight
- What counts as an exception worth flagging
- Who owns it after launch
Talk to Us About a Dashboard
We usually start with one question for one role, with a route from each number to the thing it refers to. That makes the first build small, and it can grow once people are using it. Send us the question you keep having to put together by hand and we’ll tell you what answering it would take. Get in touch, or see the rest of what we build on the services overview.
