Operations Command Center
National customs authority · West Africa
A live executive command center for a national port, joining five production databases into a single operational picture.
Thirteen operational sections — scanning, weighing, vessel tracking, manifests, duty waivers, appointments, agencies, flagged consignments, issues, payments, revenue, officer activity and system health — rendered as one dark executive dashboard. Built for decision-makers who need the state of the port on a single screen, with live database health and alerting underneath.
Outcomes
- Five production databases federated into one view
- Thirteen operational sections, updating live
- Revenue target against collected, tracked daily
Stack
- React 19
- TypeScript
- Vite
- Tailwind
- Recharts
- Express
- MySQL
- JWT
Engagement
Client named under NDA. Several engagements are active public-sector contracts, so we describe the mechanism rather than the customer.
Source, references and a walkthrough can be arranged for serious evaluation.
The authority already had the data. Scanning, weighing, manifests, waivers, payments and officer activity were each recorded faithfully — in five separate systems that had been procured years apart and had never been asked to speak to one another. Answering a question as simple as “what did we collect yesterday, and against what target” meant a person exporting spreadsheets from each and reconciling them by hand. By the time the answer existed, it described a port that no longer did.
We could not replace those systems. They were live, they were relied upon by hundreds of officers, and several were under separate vendor contracts. Whatever we built had to read from all five without owning any of them, and had to stay correct when one of them was down for maintenance.
- 01
Read-only federation, not migration
The command center connects to each production database as a read-only consumer. It never writes upstream. That decision made the project politically possible — no vendor had to give up ownership, and no existing workflow changed — and it removed an entire category of risk: a bug in our code cannot corrupt a customs record.
- 02
Degrade per-section, never per-page
Five upstream systems mean five independent failure modes. Each of the thirteen sections resolves on its own and reports its own health, so a stalled connection greys out one panel rather than blanking the dashboard. A health section makes the state of every connection explicit, because a number with an unknown provenance is worse than no number.
- 03
Built for the person who signs
The primary user is a director, not an operator — someone with two minutes between meetings. That drove a dark, high-contrast layout with one KPI bar above everything, revenue tracked against target rather than in isolation, and drill-down that is available but never required.
The technical dossier for this engagement
This page describes the shape of the work. The dossier describes how it was actually built — and goes to a named person at a named institution rather than onto a public URL.
- System architecture, including the integration boundaries and why they were drawn there
- The data model for the records the system is accountable for
- Security posture: authentication, authorisation, audit trail and key handling
- Deployment topology, failover behaviour and what happens during an outage
- The measured before-and-after, where the client has cleared it for release
- Named CVs for the engineers who did the work
Sent under a mutual NDA. Client names and locations are redacted unless that client has given written consent, which some have and some have not. Prepared individually — expect it within two working days, not instantly.
Next project
Port Clearance Platform
Start here
Bring us the problem
nobody has solved.
A 30-minute technical briefing. We will tell you what we would build, roughly what it costs, and honestly whether we are the right people for it.