System
THE SYSTEM
BEHIND THE WORK.
Capabilities organised by engineering responsibility, not by a percentage bar — and each one tied to the projects where it was actually used.
Diagram: the system core. A central data rail runs from a source terminal to a destination terminal. Five modules dock into it: an interface layer for commerce surfaces (Miva, Shopify, TikTok Shop); a control layer for scheduling and write control; an integration core running on Node.js that holds the sync flows; a data layer for NetSuite records queried with SuiteQL; and a runtime layer of PM2 processes behind Nginx on Linux. The same information is written out in the sections below this diagram.
Select a capability to see where it is used
07 groups · 06 systems
Commerce & ERP
What these systems have in common
Each one tied to a real system
Every write in the Miva↔NetSuite integration is checked against a local ledger first, so a replay of the same order never creates a duplicate. Used in 01
Marketplace write paths default to off and are enforced at runtime; the operations tooling classifies but never enforces automatically. Used in 02, 06
An ambiguous customer or SKU routes to human review rather than a guess, and the ERP automation only ever touches its own board group. Used in 02, 05
The platform migration was verified by re-running it and diffing the result — zero differences, checksummed, or it was not finished. Used in 04
A Finance-approved staged go-live instead of an all-at-once flip; a storefront redesign assigned live one milestone at a time. Used in 02, 03
A status dashboard for every sync run, and liveness/readiness endpoints so monitoring can tell “running” apart from “actually working”. Used in 01, 06