The platform map

How it works

The product sync runs in two phases. The first upserts everything the free REST API returns. The second opens the licensed backend reader only for the products the first phase flagged as changed. All three services write field-level diffs into one shared changelog, so a question about what changed has a single place to look.

Delta polling on its own would not be enough. The ERP sometimes corrects a record without bumping its modification stamp, and a stamp-based query never sees that edit, so a nightly pass re-scans every record regardless of stamp. Each service also holds its checkpoint until the last record of a batch is committed, so an interrupted run resumes where it actually left off. The local copy is never more than a day out of agreement with the ERP.

How it works

The scheduler is the real work. It discovers open shipments from the ERP and spends a fixed call budget by urgency: a package out for delivery is worth checking constantly, one sitting in transit is not, and a delayed or exception shipment can wait longer still. Calls concentrate in the hours when deliveries actually happen, with one sweep overnight for late scans, which drops overnight usage by about 80%.

Underneath it, a normalizer collapses the carriers into one model the dashboard can render: more than 40 FedEx status codes and 11 USPS categories resolve onto 8 statuses. The pipeline picks its carrier client from the tracking number itself, because the carrier field on the order is not always right, and a later update can never overwrite a known delivery estimate with an empty one.

How it works

The file is checked far more often than it changes, so the sync asks SharePoint whether the document has moved before it asks for the document. Most checks end at the response header without transferring the file; only a real change triggers a download and a parse. The credential it holds is read-only, so the sync can never write back to the workbook; the write direction does not exist in the code.

How it works

People rename campaigns on both sides, so the sync normalizes the names before it compares them; matching on the raw values would drift apart within a week. The sending platform does not always expose preheader text as a field, so the service reads it back out of the campaign HTML, which is what the platform's own preview then shows.

The ticketing platform gave me no API to work with, so the import signs in the way a person does and drives the export from a saved browser session, then parses the file into the database on a schedule.

How it works

The ERP's REST API was the obvious source and turned out to be the wrong one: its deals endpoint returns the metadata but omits the coupon code, the discount amount, the amount type, and the order amount, which are exactly the fields that get corrupted. So the check signs in to the ERP's own backend, opens each deal's edit form, and reads the values a person would see there, then compares them field by field against the previous night's copy.

How it works

A nightly enumeration re-walks the whole source and upserts what it finds, roughly 470 paged requests, and it continues past transient errors, because one flaky call partway through a walk that long would throw away the entire refresh. Re-walking everything rather than tracking changes is the deliberate choice: the copy corrects itself every night, and the worst staleness anything downstream can read is 24 hours by construction.

Customers and contacts are two separate resources in the ERP, and which contact is the billing or shipping default is recorded on the customer rather than on the contact. A refresh that walked only contacts would leave those defaults pointing at contacts that had since been deactivated, so the sweep takes contacts first and customers second, then derives every default flag from the fresh copy in one set-based update. A separate nightly control re-checks that the flags still point at live contacts, instead of assuming the derivation held.

How it works

It runs on Splink probabilistic record linkage, tuned for precision over recall, because a wrong merge puts one customer's orders and history into another customer's view. People known to be distinct carry cannot-link rules that no later stage of the pipeline is allowed to override. The nightly rebuild waits on a human review step before it runs, because the rebuild replaces the live spine.

How it works

Grouping runs entirely in SQL over the mirrored tables and assigns every account a deterministic group id from normalized phone, email, and address keys. I kept it in pure SQL because grouping logic that lives in application code drifts depending on which path last touched a record, and the same data has to produce the same groups every time for anyone downstream to trust the result. Accounts whose keys disagree stay separate and pass to the identity engine.

On the address side I put the bulk classification on FedEx and reserved a second validator for the ambiguous cases only, which took a roughly five-hour run down to about fifteen minutes. Every flag is read back after the write to confirm the value took, so a silently rejected correction gets caught rather than counted as applied.

How it works

Every price change carries three states: queued, applied, and verified. Verified exists as its own state because the service reads each price back after writing it and compares to the penny, and anything that fails that read-back is held for a person rather than counted as done. Every push, verify, and revert is recorded, so a sale can be put back exactly as it was found. Each product carries its own lock, so two people can run different sales at the same time without stepping on each other.

How it works

Both halves of a transaction have to arrive together, so the feed pulls each new tax record and enriches it from the ERP in the same pass. Reconciliation then reads one row instead of joining two systems at query time.

The fragile part of the manual process was the column names. Vendors rename fields without warning, and one renamed header breaks the match before a single number is compared. Every expected field resolves through four tiers: an exact match on the normalized header, a curated alias table, a fuzzy match, and a last tier that reads the cell values themselves to break a tie. Anything that clears no tier is left unmapped and sent to review; the service does not guess. The tax engine has renamed fields twice since launch and the resolver absorbed both. It also never writes a correction back, because a write-back decides which system was right, and that is a person's call to make.

How it works

Card payments join on the exact transaction reference the gateway issues. PayPal does not, because the ERP stores a third identifier that appears on neither side, so those reconcile on amount, brand, and a three-day window. An order the rails cannot settle either way gets its own verdict and is never assumed paid.

Nothing reverses on its own. A flagged order is put in front of a person with both sides shown, and if the payment is voided the order is deliberately left unlocked, because a locked order cannot accept a payment and the money still needs collecting.

How it works

The desk is one page with the customer pinned to the left and three tabs across it: shoppers on the site right now, the order being built, and quotes saved earlier. A rep searches for a person. The ERP records the same customer as several separate accounts, and the identity work underneath is what collapses those into one result, so a rep can move between that person's accounts without losing the order in progress.

Everything the desk writes goes into the ERP through the same interface the ERP's own order screen uses, so a desk order and a hand-keyed order are the same kind of record and nothing downstream has to know which was which. Lines carry their own stock rollup, the ship-to and live carrier rates resolve in the same screen, freight can be overridden when the rate table does not cover what is shipping, and a part-built order can be saved, shared with another rep, or duplicated.

How it works

A tester connects to the unit over BLE, runs the sequence, and taps pass or fail. Each unit is registered by serial number and tested against a definition specific to its SKU, and every result lands in the module registry as it happens. A pass is built to feed a tested-inventory ledger the warehouse reads per SKU without running a report, and a fail to open a triage entry owned by a named person with a disposition of retest, repair, or scrap; the warehouse's daily path today is the tester itself, and that fuller lifecycle is seeded and waiting on adoption.

How it works

The mapping from ERP shipping method to carrier service is the part that matters, so I made it explicit, including which methods are hazmat, and nothing about a label depends on a guess at the moment of printing. Labels are minted through the provider the platform already uses for address validation and tracking, which leaves one integration to maintain instead of one per carrier.

The station is built to hand fulfillment state back to the ERP through the sync that already exists. That return path is not connected yet, so a label printed here is not written onto the order in the ERP today.

How it works

Five services read the product model out of PostgreSQL and emit what the storefront expects, with raw option names mapped into categories a customer can actually read. A product page composes from nine independent fragments in roughly 300ms, and each fragment is isolated, so one slow section degrades itself and not the page.

The graph does not store which products go together. Each product declares the interfaces it exposes and the ones it accepts, on three axes: the connector it plugs into, the termination its firing cues need, and the chassis it physically fits. Compatibility is derived from those declarations every night. Eighteen antennas are eighteen small declarations rather than the 306 pairs they imply, and adding a nineteenth connects it to all of them without anyone editing a pair.

An option a customer picks resolves into the component SKUs that choice actually adds, so the graph describes a configured product and not just a catalog entry. Specification values are harvested from support articles and every value keeps a pointer back to the article it came from, so a reviewer can check a number against its source.

How it works

An operator scans the order and the declaration comes back filled. The shipper block, the UN number, the class, the packing group and the packing instruction are fixed in the system rather than entered per shipment, and the signatory comes from a list of the people authorized to sign.

The regulator dictates the layout, so the official IATA form is the base document and the order's data is drawn onto it. Redrawing that form myself would have put the company's compliance on my rendering of a legal document.

How it works

Each SKU is classified on how often it sells and how erratic that demand is, then routed to a model that suits it: seasonal series to AutoETS, intermittent ones to Croston's SBA, and the rest to a recent-mean estimator. A single model fitted across all SKUs over-smooths the intermittent ones and under-fits the seasonal ones, which is the failure I set out to avoid. Periods when a SKU was out of stock come out of a 37-month transaction ledger and enter the model as censored demand, because a stockout looks like zero sales and is really unmet demand.

How it works

The report opens as a category matrix carrying a signed year-over-year delta and drills into individual SKUs, with the operator setting the range and the granularity. Some SKUs contain components that were never costed, and the profitability view leaves those out of margin entirely. Leadership acts on this report, so a margin built from partial costs would be acted on as though it were complete.

How it works

Attribution was the hard part. The pipeline is anonymous by design, with no cross-site identity and no personal data in the event stream, so a session cannot simply be joined to an order. The bridge I built matches sessions to orders on timing at checkout, and the matches land inside 15-second windows; sessions recorded before the bridge existed were matched retroactively. A session that does not match stays unattributed, and the console reports how many did not match. Money figures come off the authoritative order record and join through the bridge, so the console never invents its own revenue number.

How it works

A behavioral taxonomy feeds an ingestion API, a heartbeat writes visitor presence, and a watchdog closes a session when the heartbeat stops. A signed-in visitor resolves to a customer record, and that customer's order history resolves through the product graph, so the view carries what equipment the shopper already owns and not only what is in the cart in front of them. It is built to be automated against, so a triggered email or an offer can key off a live cart; that automation is not built yet.

The editing half is built around consent, because a rep silently changing someone's cart is not something I was willing to ship. The rep stages the whole change as one action, the shopper's own browser renders a preview of it, and it executes through the storefront's native cart only after the shopper approves.

How it works

Two kinds of record back it: what a service did and how many records it touched, and the field-level before and after of every change it made. The grading rules live in the reporting layer and not in the jobs themselves, so changing what counts as notable is one edit and never a re-run of anything.

Bug reports work the same way. Every page keeps a short rolling buffer of what happened in the browser, and none of it leaves the machine until someone clicks the feedback button and describes the problem, so a report arrives with the evidence already attached.

How it works

The default environment is a daily snapshot replica, so an unexpected write lands on a copy of the data. Live SQL is held read-only at two independent layers: the tool refuses mutating statements and bounds the query before it ever leaves the process, and the database session itself is opened read-only, so getting past the first layer still yields nothing.

A write takes two calls. The first returns a preview of exactly what would change, plus a token; the second carries that token and executes. Reads carry no such risk and run unguarded. I maintain this platform alone, so every release also goes through a review gate I built to stand in for the second engineer I do not have.

How it works

A write that changes anything is a two-call tool. The first call previews the change and returns a token; nothing moves until a second call comes back carrying that token, so the confirmation is a separate deliberate act.

Whether a write worked is decided by reading the record back out of the system of record and comparing it against what was intended. The HTTP response is a hint. A write gets exactly one attempt and no automatic retry, because a lost response and a rejected write look identical from the caller's side, so re-sending on that ambiguity can execute the same money change twice.

The read-back asserts the invariant the change was meant to produce. Asserting the exact value written would be wrong here: an order status is a field the ERP advances on its own within minutes, so checking that it still equals the number just written would report a good write as drift. The assertion is that the order is out of the shipping states.

Unknown is a real outcome here, separate from worked and from failed. When the read-back cannot settle the question the tool says so and stops, and a person checks by hand.

How it works

The dashboard verifies the portal's signed token against the portal's public key, and a first sign-in creates the account with nothing attached to it. I kept a locally authenticated admin path as the fallback for a portal outage, with those credentials stored hashed. Sessions live in the database, so losing the cache does not sign the entire team out. Permissions are granted by pattern, so one grant can cover a whole family of pages, and the check runs on both the page and the route behind it.

How it works

Each service counts its own consecutive failures, backs off early, and disables itself outright if the upstream stays broken, writing that state where every worker can see it and where it survives a restart. Clearing it is deliberately manual, because only a person can tell whether the other end is actually fixed.

On boot, a recovery pass re-triggers whatever stopped mid-run, in dependency order, and skips anything that had disabled itself. Schema lives with the service that owns it: each one applies its own definitions at startup, written so they can run repeatedly without effect, and guarded so that only one worker does the work while the rest keep serving traffic. That is more than 300 tables that come up on their own, with no migration step for anyone to forget.

How it works

The application runs as two processes. The modern half owns the interface and everything the customer touches. The legacy half does nothing but drive the radio, and the two talk over a channel that never leaves the machine. The modern side supervises the legacy one and restarts it when it dies, and the radio process keeps its own store of module state, so the dashboard can still show the last known state while it is down.

Distribution was its own problem. An unsigned installer draws the maximum-severity warning on Windows, and on machines with Smart App Control it is blocked outright with no way for the customer to override it, which turns every install into a support call. Signing is part of the build now, so every release a customer downloads is trusted on arrival.