HERMES

Hermes stopped reading the ledger.
It started keeping it.

A retention command centre for Shopify wellness brands. Five services, 157,536 customers, one screen — and a loyalty ledger it keeps itself, now checked against the whole book and found correct.

Every channel. One person.

The old workflow scattered every customer across five logins. HERMES made them one person again — and put the whole company's surface behind one signed-in door. The app's own line for it, set in v2.34.1: “Every Channel. One Brain.”

Five services, one bloodstream

Data flows in live — webhooks in seconds, full syncs on the cron. Every action flows back out on the platforms' own rails. Nothing is a copy; everything is the real thing.

v2.52.0 rebuilt what makes a tile red. It is now recency-gated — more than three failures and the last one inside two hours — because the old flat 24-hour count pinned red for 14 hours after a burst had ended and could never go green on a service handling 12,000 hooks a day. “Never synced” became its own amber state instead of reading as healthy forever, and the board is built from the service registry, so a connector whose settings row is missing shows as missing rather than as nothing wrong.

The queue is the product

Every morning starts on one list. A card only leaves it one way — the customer pays again. That turn is the whole app, and it is the only thing the design celebrates.

Two engines nobody else computes

Both are ours, both run on our own orders and our own conversations — lib/ring.js and lib/risk.js. Neither is available off a shelf.

Every customer's delivery story

Open any profile and see the shipping life they've lived with us — charted as bars or a line, split by carrier, split by warehouse era, incidents called out with one-click jumps into the order.

Every order view carries its own delivery analysis: this box vs the company average.

And the report tells you when to distrust it. v2.48.0 found that an unknown delivery date had been quietly recorded as the ship date, which made the affected rows average 1.9 days with zero late deliveries against the Flexport era's 5.88. An unknown delivery time now stays empty, and the page warns in amber when carrier data is missing and in red when a segment's transit looks impossibly fast — it declares its own worst figure untrustworthy rather than publishing a halved transit time as fact.

“I don't know why everything got broken.”

Tyler flagged the delivery report as “not reporting correctly at all”. It was not the report. Three faults were stacked underneath it, and finding them took measuring rather than reading.

The lesson has a name here now: a rename must audit every consumer of the old name. Webhook registrations live at the vendor, not in the repository, so they are consumers nobody sees — and they fail silently, for weeks, while every dashboard reads green.

The package that came back

Flexport sometimes re-ships a lost package under the SAME order — no new Shopify order, no portal order, just the prose “A replacement was sent”. The structured twin was hiding in the 2025-03 order payload.

Hermes got eyes — then the field tested them

Claude reads the store's images and drafts real alt text from what is actually IN the picture. The guardrails shipped first; the three fixes that hardened them came from real Shopify data.

One blip in 1,216

The IT health strip surfaced a D1_ERROR: internal error on Gorgias. The fix was to prove it didn't matter — and then fix it anyway.

The interesting number here isn't the failure rate. It's that a one-in-a-thousand line in a status strip was worth proving out in full before a single line changed.

The sequel, and it is the honest half. A year later it stopped being one in a thousand: v2.52.0 found 424 Shopify and 19 Recharge deliveries failing in 24 hours, every one of them D1 DB is overloaded, climbing 0.5% → 2.4% → 4.5% over three days. The daily checks had watched feed freshness, which stayed green throughout because vendors retry. Nothing watched the failure rate. Something does now — and v2.53.0 went and found what was actually loading the database.

Your activity feed was showing strangers

Caught by comparing one customer's Hermes activity to his own Rivo screenshot. The numbers didn't match, and the reason changed the architecture.

The loyalty panel

Balance, tier, adjustments, redemption, coupons and the full account activity — one panel on every profile view: full profile, at-risk card, and the ticket side rail.

The redeem button became real

The old “Offer $25.00 in points — zero-margin save” button redeemed nothing. It wrote a toast and a note, and the code behind it would have 405'd anyway.

Recreated as it shipped in v1.0.0. What changed since: the code is no longer Rivo's. Since v2.29.0 the reward discount is minted by Hermes in Shopify, and since v2.39.0 each one is its own discount, locked to the customer who paid for it and usable exactly once. Only the points deduction still goes through the vendor.

Shopify is the truth on a spent coupon

Rivo reports used_at: null even for codes that were spent, so the store has to be asked. It took two goes to ask the right question — the usage counter answers only half of them.

The silent failure

Both loyalty mirrors had stopped storing entirely — without a single visible error — for two independent reasons.

A test suite that passes on a different database engine than production is a test suite that can pass while the product is dead. This is the slide that earns the rest of them.

Six phases to owning the ledger

Each phase shipped with its own tests, its own live reading, and its own way of being wrong out loud. Twice the reading itself turned out to be the thing that was wrong, and that got shipped too.

The un-redeem the vendor never had

Hermes mints its own Shopify coupons, keeps its own book, and can take one back. The whole ghost-coupon class exists because a vendor mints codes we can't see and can never un-redeem — this is the piece that ends it.

A gate that costs the vendor nothing

GET /api/loyalty/readiness — admin, zero vendor calls, so asking never costs Rivo anything. It shipped saying NO, and it meant it. Six days later it said yes, and it meant that too.

Green is not the same as thrown. The flip is still one deliberate action — admin, typed confirm: "FLIP", refused twice — and it has not been taken. What it does on the day changed as recently as v2.53.1: the make-good rows recording where the vendor under-paid subscribers, 106 of them worth 28,871 points, are now waived rather than credited, on Tyler's call — “nobody needs to get awarded points that they do not know about.” The rows survive as the only record of the shortfall, because that settlement is being handled with the vendor directly. Without that change, flip day would have paid all 106 out in one unattended pass that refuses to run twice.

Two hundreds. Only one of them was real.

The loyalty tile read a perfect score for weeks. It was lying, and the way it was lying is the most useful thing in this deck.

A number that was earlier reported as 99.99% was itself an artefact of the same thing: comparing a ledger that updates continuously against a vendor column that refreshes on its own cadence. The honest answer was better than the reported one, which is why it was worth proving rather than accepting.

The storefront comes home

Tyler: “couldn't Hermes just handle that stuff internally?” It can, and now it does — every reward surface a customer can touch is served by the same brain the agents use.

It shipped in shadow first: fetching, rendering nothing, and reporting what it would have replaced. That side-by-side is what decided the swap. And it fails open by construction — the vendor's own block is hidden only after ours has actually mounted, so a failed request means our decoration doesn't apply, never an empty rewards page.

Every code in the store, and whose it is

Shopify's discount list is a flat pile that cannot answer “whose is this?”. The first attempt at an answer was another list, and Tyler said so: “you made me exactly what I did not want.” Four layout options later, this is the shape he picked.

The deck exists because of a decision made two releases earlier: used codes stay in Shopify rather than being deleted. Deleting them keeps the admin tidy and destroys the only way to ask the store “was this spent?” — the check that exists because a private list of dead codes once caused a real double refund. So the store's list grows on purpose, and this is where anyone actually looks.

Give a thousand people points without giving anyone them twice

“Everyone who spent $X in the last N days gets Y points.” It moves real money in the balance customers can see, so it was built adversarially from the first line.

“It said sent.” It was never sent.

Tyler replied to a real customer from his phone. The app said success. Nothing arrived. It had nothing to do with the phone.

The uncomfortable footnote, kept rather than buried: return-label emails rode the same broken sender, so some labels sent before this may never have arrived.

Marketing should come
from customer service

Who knows what customers want better than the people they're already talking to? In HERMES the two systems are one — so the voice of the customer IS the marketing brief.

These four numbers used to sit at the top of the Support Hub, above the work. v2.24.0 took them out: they are figures you read at a desk, not the thing an agent needs first thing in the morning. They live in the Insights report builder now, where they run over the whole book rather than one rotating slice — and taking them out also killed a cron job that had been scanning 400 ticket bodies a tick to warm a cache nothing read.

Remember this

One team. One screen. One ledger. 1,252 tests green · 0 genuine ledger mismatches across 59,916 members.

Rivo's job kept getting smaller.

Tyler: “Hermes is essentially going to be the system of record for everything eventually anyways.” Nobody ripped the vendor out. One hundred eight releases just kept taking pieces of the job and proving each one worked before taking the next.

What is still the vendor's: the points balance, the earning rules and the tier ladder. The engine that replaces them is built, certified and switched off — waiting on one typed confirmation.

Four full table scans, found and cut

Every one of these looked like something else first — a slow app, a vendor outage, a database problem. Every one was a query reading the entire customer table to answer a question about one person. All four were measured against production before a line changed.

Baseline underneath all of it: the precomputed queue_cache serves every at-risk category and the VIP list in ~200ms at 150k+ customers. Since v2.54.0 the cron owns the rebuild — a miss serves the last good slice stamped with its age, and a genuinely empty cache says “building” rather than dressing an empty list up as “nobody at risk”.

The standing lesson, now written on the routes themselves: never OR two indexed columns in one condition. The per-row scan is invisible locally, because seed data is tiny, and lethal at production scale. Timing the exact query against the real database is a two-minute check that catches all four of these.

126 releases since v2.54.0, when
this deck last looked.

Source of truth: APP_BREAKDOWN.md §13 — this deck syncs with it (docs-sync rule).

One team. One screen. One ledger.

Five services and 157,536 customers behind a single at-risk queue — plus every reward code in the store, the rewards page the customer sees, and a loyalty ledger checked against the whole book and found correct. The switch to flip is built and the gate is green. Throwing it is still one deliberate action, and it is Tyler's.