localStorage
An illustrated recreation of the editor, not a screenshot. It sits behind a customer login and holds real fit data, so the flow is redrawn rather than captured. The screens follow the real layout so the work is legible, while no client name, logo or customer data is reproduced anywhere.
Read the full write-up
A generic theme can't fit a made-to-measure product.
The brand sells made-to-measure shirts and suits. A customer's fit data (band, cup, height, sleeve, collar, and more) lives in a separate pattern-matching service, not in Shopify. The stock theme had no concept of it: no way to show a customer their saved patterns, edit one, or stop an add-to-cart that had no valid fit data behind it.
The constraint
Every read and write had to go through an external REST API the theme didn't control, inside a pure Liquid + vanilla-JS theme with no build pipeline. No React, no bundler, no shortcuts.
Turn a stock theme into a fitting workstation.
The editor had to live inline on the product page, not in a separate app tab, and had to survive real customer behaviour: renaming a pattern, cloning one instead of overwriting it, bailing out mid-edit, and switching between a saved pattern and a fresh fitting without ever showing a broken state.
An inline pattern editor, wired to an external API.
The flow below is the spine of the feature: a customer gets fitted once, then can reopen, tweak, rename, or clone that pattern straight from the product page.
Cloning a pattern auto-renames it (date-stamped, with an incrementing suffix) instead of silently overwriting the original submission.
Patterns are filtered to the product's gender when a match exists, but fall back to showing everything rather than hiding the editor when the account has none. A stricter version shipped first and was rolled back after it hid the dropdown too aggressively.
The theme bugs were in the small print.
A login redirect bug traced back to three copies of the same broken helper function layered on top of each other in the theme layout, each fighting the others with !important overrides. A "preferred store" menu going blank turned out to be a metafield-only lookup with no fallback, fixed with a local-storage read the profile page was already writing to.
Trust the deployed bytes, not your browser
A font-size change looked stuck at 12px in the browser no matter what shipped. Rather than chase a phantom CSS bug, the fix was verified against a raw pull of the live theme and the CDN asset bytes directly. It was rendering correctly. The browser's local rendering was the outlier, not the deploy.
Ten Klaviyo flows replaced Shopify's defaults.
Order confirmation, shipping, delivery, in-store collection, store pickup ready, password reset, welcome, account activation, and two appointment flows, all rebuilt as dynamic templates mapped to real Shopify order and customer data: line items, addresses, payment method, and per-item variant options like collar and cuff style.
Get fitted from a phone, not just a desk.
Most customers start the fitting flow on mobile. The configurator and collection grid both reflow to a single column, with the same add-to-cart gating logic underneath.
Shipped, live, and still evolving.
The fitting editor and all ten email flows are live in production. Every theme push went out behind a full backup and a git tag, so every round of client feedback could ship the same day without risking the storefront. It's an ongoing engagement: new rounds of fixes and refinements still come in and go out the same way.
Outcome in numbers: 10 Klaviyo flows live, replacing every default transactional email, 3 stacked copies of one broken login helper, untangled.