Task-led, not table-led
A screen per database table is the default that makes tools tedious. Screens follow the jobs people actually finish.
All services
A dashboard that finishes the job in one screen, not four.
Most internal tools are organised around the database rather than the work, so a single task spans four screens and the person doing it holds the workflow in their head. This starts from the task the team repeats daily and builds the screen that completes it.
Dashboards and internal tools: what is included
- Workflow mapping based on what the team does, not only what they ask for
- Screens organised around completing a task rather than mirroring database tables
- Every state designed: loading, empty, partial failure, error, no permission, and large datasets
- Documented component set for tables, filters, forms, and dialogs so later screens cost less
- Role-based visibility designed with the screens, and enforced at the endpoint as well as the UI
- Testing against production-scale data, then repo, deployment, and written patterns at handover
Dashboards and internal tools: what gets decided first
States are the product
Loading, empty, and error states are where most internal tools fall apart, because they were discovered in production rather than designed.
Permissions enforced at the endpoint
Hiding a button is a UI convenience, not access control. Role rules live where the data is served, and the interface reflects them.
Dashboards and internal tools in 5 steps
Watch the current workflow
Whatever the team uses now (a spreadsheet, a legacy admin, or a mix), and specifically the task they repeat most. What people ask for and what they do differ, and only one of those is worth building.
Map tasks to screens
One screen should finish one job. If a task spans four views, that is the thing being fixed, not a layout to be reproduced faster.
Design the error and empty states, as well as the happy path
Loading, empty, partial failure, error, no permission, and far too much data. Deciding these up front is what separates a tool that survives real use from a demo.
Build the component set once
Tables, filters, forms, and dialogs as documented, reusable components. The tenth screen should cost a fraction of the first, and it only does if the patterns are set deliberately.
Test against real data volume
Against production-scale data, not twenty seed rows. Most dashboards that feel fast in review fall over the first time someone filters a year of records.
In use at a two‑branch gym.
Fazal Fitness, a gym in Karachi, manages members, fees, attendance, and coaching for its Quaidabad and Shah Faisal Colony branches in software I built alongside its website. People sign in with an email or mobile number, and a branch manager resets passwords.
Six states most dashboards discover in production.
Every dashboard demo shows the happy path with clean seed data. Real use is mostly the other six states, and whether they were designed or improvised is what decides how the tool feels after a month.
Loading
Skeletons matching the shape of the content that will arrive, not a centred spinner that makes the whole layout jump when data lands.
Empty
The screen a user sees on their first day, before any records exist. Usually the most neglected state in the product, and the one that decides whether they understand what to do next.
Partial
One widget failed while the rest loaded. That section says so and offers a retry, rather than the whole page collapsing into an error.
Error
What went wrong, whether retrying will help, and who to tell if it will not. Not a stack trace, and not a shrug.
Permission
A user without access sees that the thing exists and who to ask, rather than a 404 that makes them think it is broken and file a ticket.
Too much data
The table with 40,000 rows. Virtualised rendering, server-side filtering, and pagination that keeps working when the dataset outgrows what anyone tested against.
Dashboards and internal tools: questions
What makes a dashboard bad?
Almost always the same thing: it was designed around the data model rather than the job. One screen per database table means a user finishing a single task has to visit four of them, remember values in between, and hold the workflow in their head. The fix is not more charts. It is deciding which task the team does forty times a day and building the screen that finishes it.
How do you decide what goes on the main screen?
By watching what people actually do, not by asking what they want to see. Those give different answers. Requested dashboards fill up with vanity totals nobody acts on; observed workflows show you the three things someone checks before deciding anything. The main screen should answer 'what needs me right now', and everything else earns its place behind that.
Should we build this or buy something off the shelf?
Buy, if a product covers the workflow and you can adapt to how it works. Building is worth it when the workflow is the business: the sequence, the rules, or the terminology are specific enough that adapting to generic software would cost more than the licence saves. I will say so if what you are describing is a Notion database or an Airtable view, because a bespoke build for that is a bad use of your money.
What about authentication and permissions?
Handled by a dedicated provider, such as Clerk, Auth0, or whatever your stack already uses, rather than hand-rolled. Role-based visibility is designed alongside the screens rather than bolted on, because a permission model added late tends to hide buttons in the UI while leaving the underlying endpoint open to anyone who knows the URL.
Do you connect to our existing database or API?
Usually yes, and it is normally the right call. A dashboard that reads your existing system means one source of truth and no sync to keep correct. Where the existing API is slow or awkward, a thin layer in front of it is cheaper than changing the system of record. What I avoid is copying your data into a second database that immediately starts drifting.
How long does an internal tool take?
Four to ten weeks for a first useful release, depending on how many workflows it covers and how accessible the data is. The variable is rarely the interface. It is how long it takes to get credentials, understand the existing schema, and get a straight answer about the business rules that only live in one person's head.
What happens to it after launch?
You get the repo, the deployment, and documented component patterns, so a different developer can extend it without reverse-engineering your conventions. Internal tools live for years and get handed between people; one that only its original author can safely change is a liability.
Tell me what you need built.
A couple of sentences is enough to start. I reply within one business day.