Building Internal Ops Dashboards Teams Actually Use

Many companies have a graveyard of internal dashboards. Each was built for a launch or a board meeting, demoed once, and quietly abandoned while the team went back to a spreadsheet someone updates by hand. The dashboards weren't ugly or slow, necessarily. They answered questions nobody was asking, showed numbers people didn't trust, or made them hunt for the one thing that needed attention today.

I built internal dashboards for Hafnia (BW Group) in Singapore, covering a fleet of about 200 vessels, on React, Next.js, Node.js and PostgreSQL. This guide covers internal dashboard development for operations teams: how to decide what goes on a screen, how to make the data trustworthy and fast, when to build rather than buy, and how to get people to open the dashboard tomorrow.

Key takeaways

• Start from decisions, not data. Ask what each role decides, how often, and what makes them act.
• Show exceptions first. The most useful screen tells people what needs attention now, not everything that's fine.
• Trust beats polish: agreed metric definitions, visible data freshness and one source of truth.
• Keep it fast with pre-aggregated data, server-side filtering and sensible caching.
• Buy for standard reporting, build for operational workflows with actions, permissions and domain logic.
• Adoption is a feature: ship to one team, watch them use it, measure usage and retire what nobody opens.

Start from decisions, not data

The fastest way to build a useless dashboard is to start from the database and chart whatever's there. Start from the people instead. For each role, ask:

1. What decisions do you make, and how often (every hour, daily, weekly)?
2. What tells you something needs action? A threshold, a delay, a change from yesterday?
3. What do you do next? Call someone, update a system, escalate?
4. What do you check today, and where (spreadsheets, emails, three different systems)?

The answers give you the screens. A duty manager needs "what's late or at risk right now"; a regional head needs weekly trends and comparisons; finance needs reconciled numbers at month end. Those are three dashboards, not one dashboard with forty charts.

Three kinds of dashboard

Mixing them on one screen serves nobody. An operations lead scanning for problems doesn't want to scroll past a twelve-month trend chart.

Design principles that make dashboards useful

• Exceptions first. Lead with what's late, broken, over threshold or changed, sorted by urgency. "All normal" can be one line.
• Status at a glance. Use colour sparingly and consistently (red means the same thing everywhere), and never rely on colour alone.
• Drill down, don't cram. A summary row should open the detail behind it, ideally with the underlying records.
• Show freshness. "Updated 4 minutes ago" on every panel. Nothing kills trust faster than acting on stale data without knowing it.
• Remember filters and views, so people land where they left off.
• Link to action. If the next step happens in another system, deep link to it.

Make the data trustworthy

A dashboard is only as useful as people's belief in its numbers.

• Agree metric definitions in writing ("on-time means arrived within the agreed window") and show them in tooltips.
• Use one source of truth per metric, and make the dashboard compute from it rather than from copies.
• Handle missing data honestly. Show gaps as gaps, not zeros.
• Reconcile with what people already trust. If the dashboard disagrees with the spreadsheet, find out why before launch, because users will.

Keep it fast

Slow internal tools get abandoned too. Keep heavy work off the request path:

CREATE MATERIALIZED VIEW daily_ops_summary AS
SELECT date_trunc('day', created_at) AS day,
       region,
       count(*) FILTER (WHERE status = 'delayed') AS delayed,
       count(*) AS total
FROM shipments
GROUP BY 1, 2;

-- a unique index allows refreshing without blocking readers
CREATE UNIQUE INDEX ON daily_ops_summary (day, region);
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_ops_summary;

Pre-aggregate with materialised views or summary tables refreshed on a schedule, filter and paginate on the server, virtualise long tables in the browser, and point heavy analytical queries at a read replica rather than the production database.

From the field: For Hafnia (BW Group) in Singapore, I built internal dashboards covering a fleet of about 200 vessels, on React, Next.js, Node.js and PostgreSQL. I've also architected 15+ full-stack platforms serving 50K+ daily API requests at sub-200ms p95, and the same rules apply inside a company as outside it: pre-compute what's expensive, and keep every screen fast.

Build or buy?

Buy when the job is charts over existing data. Build when the dashboard is part of how operations run: when people take actions from it, when permissions follow your organisation's structure, when it combines several systems with domain rules, or when licence costs per user outgrow a custom build.

A sensible custom stack

• Front end: React with Next.js, a charting library (Recharts, ECharts or visx) and a table library such as TanStack Table for sorting, filtering and virtualisation.
• API: Node.js with typed endpoints that return aggregated data, not raw tables.
• Database: PostgreSQL, with materialised views or summary tables for heavy queries.
• Live updates: server-sent events or WebSockets for operational panels that must update without a refresh.
• Auth: single sign-on with the company's identity provider, plus role-based access.

Security for internal tools

Internal doesn't mean safe. Use single sign-on, role-based access with row-level filters (a regional team sees its region), audit logs for exports and changes, and limits on bulk exports of sensitive data. Internal dashboards often show commercially sensitive information, so treat them like any other production system.

Getting people to actually use it

1. Ship to one team first and sit with them while they use it. Watch where they hesitate.
2. Replace something. If the old spreadsheet still exists, people will keep using it. Agree a date to retire it.
3. Measure usage: weekly active users per view, return visits and which panels get clicked.
4. Retire unused views. Every panel nobody opens makes the useful ones harder to find.
5. Send people to the dashboard from alerts, emails and chat messages with deep links.

FAQ

What is an internal dashboard?

It's a screen or set of screens that shows a company's own operational data, such as orders, fleet status, support queues or finances, so teams can monitor work, spot problems and make decisions. Good ones are built around specific roles and decisions.

Should we build a custom dashboard or use a BI tool?

Use a BI tool when the job is reporting and analysis over existing data. Build a custom dashboard when people need to take actions from it, when it combines several systems with domain logic, when permissions must follow your organisation closely, or when per-user licences become expensive.

What tech stack works for internal dashboards?

A common, reliable choice is React with Next.js on the front end, a charting and table library, a Node.js API returning aggregated data, PostgreSQL with materialised views for heavy queries, and single sign-on with role-based access.

How do you get teams to use a new dashboard?

Build it around their actual decisions, launch with one team, watch them use it, retire the spreadsheet or tool it replaces, measure usage per view, and link to the dashboard from alerts and messages where work already happens.

Next steps

If your team runs operations from spreadsheets and screenshots, I can help you design and build dashboards around the decisions people actually make. Get in touch, or see my work.

Sources

• Materialized views, PostgreSQL docs
• REFRESH MATERIALIZED VIEW, PostgreSQL docs
• TanStack Table, TanStack
• Metabase documentation, Metabase
• Apache Superset documentation, Apache