Sample architecture study — not a named client
Multi-location operations
Overview
Sample architecture study — not a named client story. It describes a pattern we use when managers spend more time assembling status than acting on it.
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.
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.
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.
01
Scheduled pulls plus webhooks where vendors provide them. Each record stores source id, hash, and fetched-at.
02
PostgreSQL tables shaped for the screens, not a 1:1 clone of every vendor object.
03
Server-rendered lists with filters, saved views, and CSV export. Mutations are limited to operational metadata.
A successful project is one where the morning meeting opens the dashboard instead of a file. We will not invent time-saved statistics for a sample.
Next step
If this pattern matches a system you run, bring the current tools and the failure mode. We will say whether a sample should stay a sample — or become a build.