Case 06 / 06 · Operations engineering · 2025–2026

Commerce Operations & Infrastructure

Sinister Diesel · private production systems

A handful of recurring operational problems — is a listed price violating MAP policy, is a form submission reaching the right team, is a server actually healthy — had no owner and no tooling. I identified each gap from the operational side and built what closed it.

Runtime
Node.js · Express
Process
PM2
Proxy
Nginx
Health
/health + /status
Simplified system view · the runtime the other systems stand on

Context / problem

Three gaps with no owner

MAP price monitoring, storefront form routing, and the health layer behind the integrations in the other case studies. None of them were anybody’s job, and none of them had tooling.

The design constraint across all three was the same: fail safely and visibly — no silent data loss, no automatic action a human didn’t approve — rather than optimising for full automation on day one.

MAP monitoring

One deterministic rule, then a human

A monitoring engine classifies public listings against confirmed prices with one deterministic rule — never an AI guess promoted automatically — and routes ambiguous cases to human review.

Matching only escalates to “possible violation” on an exact SKU/MPN match against a confirmed price. Everything else — unconfirmed price, uncertain match, an active exception — gets its own explicit non-violation status, so a reviewer always sees why.

Tests
90 / 90 passing
Enforcement
None — classify only

Forms bridge

Deliberately isolated

A small Express service bridges storefront forms into monday.com behind strict CORS and per-IP rate limiting. It runs as its own process on purpose: a fault there cannot take down the NetSuite sync, and a fault in the sync cannot take down form submissions.

Health layer

“Running” is not “working”

A health and status layer gives PM2 and a human on-call a real answer to “is this actually working”, without tailing logs. Each tool runs as its own small process behind Nginx with a liveness and readiness endpoint, so monitoring can tell a running process apart from a working one.

Result

Observable Operable, not just built

A small, deliberately boring set of internal tools that make the systems in the other case studies observable and operable. No automatic enforcement anywhere — these tools observe and classify, and a human decides what happens next.

Node.js Express PM2 Nginx Linux Docker

Back to the start · 01 / 06

Ecommerce ↔ ERP Integration

The system that runs on everything described above.