Internal operations dashboard

Overview

A technical architecture guide detailing an engineering pattern for situations where managers and operational staff spend more time assembling manual status reports than acting on them.

Operational challenge

Daily stand-up numbers were copied from a ticketing tool, a payment export, and a warehouse email. By the time the sheet was formatted, the exceptions had moved. Nobody trusted yesterday’s red cells.

Technical complexity

Source systems already existed; the gap was a coherent read model. Different roles needed different columns. Refresh had to be frequent enough to be useful and gentle enough not to exhaust vendor rate limits. Write-back (assigning an owner, leaving a note) had to be explicit so the dashboard did not become a shadow ERP.

Requirements

• Read models for orders, exceptions, and SLA-aged items
• Role-based views (floor vs finance vs leadership)
• Notes and assignment without duplicating the source system of record for money or stock
• Export for the weekly meeting without re-keying
• Audit of who changed an assignment

Architectural solution

A Next.js authenticated application with a thin API that federates vendor APIs on a schedule, stores a local read model, and offers a narrow write path for assignments and notes. Source systems remain authoritative for payments and inventory.

Component breakdown

Technology stack

• Next.js
• TypeScript
• PostgreSQL
• REST integrations
• Docker

Implementation phases

1. Agree the three questions the dashboard must answer every morning
2. Build ingest for one source end-to-end, including auth refresh
3. Add the exception list UI before adding charts
4. Introduce roles once the happy path is used by a real team
5. Document the refresh SLO and what ‘stale’ looks like on screen

Expected production outcome

The engineering objective replaces error-prone spreadsheets with an automated single pane of glass, accelerating issue triage and decision making across business functions.