Skip to content

Featured case study

Engineering a Conversion-Focused Shopify Storefront

Designing and operating the subscription buy box, cart state, performance measurement, checkout analytics, and production delivery for a US wellness DTC brand on a heavily customized Shopify theme.

  • Shopify OS 2.0
  • Recharge
  • Vanilla JS
  • Core Web Vitals
  • Web Pixel
  • Puppeteer
Open the live product page

Most acquisition traffic entered directly on product pages, so this case focuses on PDP systems and storefront performance, not a homepage. The live page is long and continues well below the first viewport: the pack and subscription buy box, benefits, ingredients, a week-by-week timeline, reviews, and FAQs. Not every product claim, review, or asset on that page is my authored work.

Lumway product page
Business
US wellness supplements, direct to consumer
Platform
Shopify Online Store 2.0, custom theme on an Elixir base
Role
Sole engineer on the storefront's commercial surfaces
Ownership
Architecture, implementation, production debugging, measurement, and release
Core build
Liquid and vanilla JavaScript, Selling Plans with Recharge, real-user monitoring, a checkout Web Pixel

One system, not six features

Lumway was not a list of features. It was one commerce system a shopper moves through in a single motion.

The purchase decision happens on two surfaces: the product page and a set of advertorial landing pages that carry the same buy box. Traffic is mostly paid and mostly mobile, so a visitor arrives from an ad on a mid-range phone and decides in seconds.

Those surfaces are connected because the shopper experiences them as one path: see the offer, choose a pack, add to cart, check out, and ideally subscribe. The business depends on that same path to know whether any of it worked. A mismatch at any point loses the sale quietly, with no line in a log: a price that lags the selected pack, a cart drawer that blinks away, a layout that jumps on first paint, a funnel that goes dark at checkout.

Recurring customers carry more long-term value than a single purchase, so the subscription control had disproportionate commercial importance. And all of it runs on a live store a content team edits every day through the Shopify Customizer, so every change has to reach production without overwriting their work. That single constraint shaped the architecture as much as any feature did.

The shopper experiences the offer, pack, subscription, cart, checkout, and confirmation as one continuous system.

The purchase path

Six surfaces, one path, each depending on the layers beneath it.

Paid mobile traffic
PDP or landing
Shared buy box
Pack and purchase type
Cart
Shopify checkout
Subscription or one-time order

Supporting layers

  • Visible pricing
  • Commerce state
  • Performance
  • Analytics
  • Production delivery

Before and after

Subscription

Before

A vendor widget held its own pricing state, so the visible subscription offer could drift from the selected pack.

After

A custom interface on Shopify Selling Plans kept pack, billing cadence, visible price, and billed price aligned.

Evidence: Correct selling plan and price across every tested pack and purchase type.

Cart

Before

Document-wide DOM queries caused wrong quantities, disappearing drawer state, and dead add-to-cart behavior.

After

State and DOM access were scoped to the real buy-box context, resolving three silent failures at their shared root cause.

Evidence: Verified in clean headless Chrome across the full buy-box matrix.

Performance

Before

The theme was judged on lab scores that missed a layout shift real visitors were hitting.

After

Real-user monitoring found the shift, and each cause was isolated and removed.

Evidence: Field-derived spike, with before and after confirmed in lab and sandbox.

Analytics

Before

The funnel went dark at checkout, and the event map risked sending customer names.

After

Checkout was instrumented through a Web Pixel, with no customer names in the payloads.

Evidence: Event map fires across storefront and checkout after a remediation pass.

Delivery

Before

A routine push could overwrite merchandising the content team had just set live.

After

Shared files are pulled before they are pushed, and each change ships as one revertable pull request.

Evidence: No further known Customizer content loss after the workflow was introduced.

Verified outcomes

Each labeled by how it was measured.

  • 66 / 66

    Migrated subscriptions confirmed active

    Operational verification

  • 3

    Silent cart failures traced to one shared root cause

    Repository and Puppeteer

  • ~0.9 CLS

    Field spike identified through real-user monitoring

    Field observation

  • < 0.001 CLS

    Drawer-path result after the fix

    Lab and sandbox verification

  • No hardcoded IDs

    Selling-plan mapping derived from plan data rather than fixed IDs

    Implementation

  • Isolated rollback

    One independently revertable pull request per production change

    Operational workflow

Core engineering stories

Featured story · 01

A custom subscription buy box on native selling plans

The off-the-shelf subscription widget introduced a separate pricing state and could not fully match the storefront. I replaced its presentation layer with a custom buy box on Shopify Selling Plans while keeping Recharge as the subscription processor. Pack selection determines billing cadence, and the mapping is derived from plan text rather than hardcoded IDs, so it survives the plan edits that break a hardcoded integration. Because recurring customers carry more long-term value than a single purchase, the goal was simple: the offer a shopper sees is the offer they are billed on.

VerifiedThe correct selling plan and price were submitted across every pack and purchase type.

Read the deep dive
Lumway subscription buy box: pack selection, 2-Month-Delivery selected with per-pack price, and add to cart
  1. 01Selected pack
  2. 02Subscribe versus one-time
  3. 03Billing cadence
  4. 04Visible price equals billed price
  5. 05Add to cart
Custom presentation
Authored
Native Shopify
Platform
Recharge processing
Vendor

02

Commerce state and cart stability

The buy box is three components, a pack selector, a purchase-type toggle, and add-to-cart, that share no DOM on a page with no frontend framework, a hidden second product form, and a third-party app that can remove the cart drawer. Three production failures, a wrong quantity, a vanishing drawer, and a dead button, all traced to one root cause: document-wide DOM queries on a page that carries more than one form. I scoped every read to the real buy-box context and coordinated the components through message passing.

VerifiedEach fix shipped as a revertable pull request and was re-verified in clean headless Chrome.

Read the deep dive
Multiple forms
Document-wide query
Wrong context

03

Performance measured on real users

Traffic was predominantly paid and mobile, where a page that jumps or paints zoomed reads as cheap at the moment of decision. Lab tools reported the theme as healthy, but a layout-shift spike near 0.9 was hitting about a third of mobile pageviews and stayed invisible on fast test loads. I built a small real-user monitoring pipeline that pointed attribution at each cause, then isolated and removed them one at a time.

VerifiedField-derived spike confirmed, with before and after measured in lab and sandbox.

Read the deep dive
00.10.50.91.0~0.9CLS · share of mobile pageviews
Good ≤ 0.1Spike ~0.9 (≈ a third of mobile)
Real-user monitoring, mobile. The spike near 0.9 never reproduced in lab or sandbox — it only showed in the field.

Drawer-path verification

< 0.001 CLS

Lab and sandbox

04

Analytics through the checkout boundary

Every decision here was judged on data, but Shopify's checkout is a closed surface that theme code cannot reach, so the funnel could not be one script. I instrumented the storefront from the theme and the checkout through a Shopify Web Pixel, kept the two separated, and added a vendor-neutral event seam so the analytics vendor stays swappable. The checkout payload records that a field was filled rather than who filled it. I diagnosed a Purchase-duplication issue for the marketing team without owning GA4 or the pixels.

VerifiedStep-level checkout events with no customer names in the payloads.

Read the deep dive
Theme storefront
Checkout boundary
Web Pixel

05

Production-safe delivery

Branches map to themes and a merge auto-publishes, and the content team co-edits the same JSON files through the Customizer, so a normal push can silently overwrite live merchandising. I moved development onto personal unpublished themes, pulled shared files before editing them, and shipped every change as one isolated, revertable pull request. The discipline is the design, because the platform does not enforce it.

VerifiedNo further known Customizer content loss after the workflow was introduced.

Read the deep dive
Dev theme
Pull shared JSON
Isolated PR
Published theme

Supporting operation

66 Live Subscriptions, a Right-Sized Migration

The store needed to move 66 active subscriptions from Loop to Recharge. The clean API route was unavailable: Loop's export was gated and Shopify no longer allows admin-created custom apps. So I built a controlled import workflow rather than a broad migration platform: normalize the export, validate every billing-critical field, prepare the Recharge import, check the upcoming-charge window, and verify each record after ingestion. The cutover was timed around the earliest upcoming charge so no subscriber could be billed twice. The process was purpose-built for one bounded migration, not generalized into infrastructure the business did not need.

66

Expected

66

Imported

66

Active

Operational verification

Verified66 of 66 migrated subscriptions were confirmed active in Recharge after import.

Read the migration story

Results and scope

The commercial metrics improved over the engagement. Those figures belong to the brand and sit under NDA, so here I show the verified engineering and walk a serious prospect through the results privately.

Verified engineering

  • Implementation behavior, confirmed in code and clean-room tests
  • Lab and sandbox measurements under throttling
  • A field-derived observation from real-user monitoring
  • Operational verification of the migration and the delivery workflow
  • Checkout event payloads excluded customer names

Held under NDA

  • Conversion and revenue figures
  • Average order value and retention
  • The brand's analytics dashboards

Engineering principles

  1. 01

    Measure real users, not only synthetic scores.

    Lab tools are diagnostics, not a verdict on the experience your visitors actually get.

  2. 02

    Scope logic to the actual commerce context.

    On a page with multiple forms and sections, a document-wide query is a latent bug.

  3. 03

    Keep the visible offer equal to the billed offer.

    Pricing a shopper cannot trust is a conversion problem, not a cosmetic one.

  4. 04

    Design delivery around the platform's editing model.

    On a store a team edits daily, safe release is a design problem, not a Git tutorial.

Selected stack

Storefront

  • Shopify Liquid
  • OS 2.0 sections and blocks
  • Vanilla JavaScript

Commerce

  • Shopify Selling Plans
  • Recharge
  • AJAX Cart API
  • Sections Rendering API

Measurement

  • web-vitals
  • Google Apps Script
  • Amplitude
  • Shopify Web Pixel

Quality and delivery

  • Puppeteer
  • Shopify CLI
  • GitHub integration

Ownership boundaries

Not claimed as my work

  • Storefront API and Metaobjects that appear only in third-party page-builder code
  • Theme App Extensions supplied by vendors
  • GA4, Meta Pixel, and TikTok Pixel setup, owned by the marketing team

I diagnosed, reviewed, or integrated around these where relevant, but did not author or configure them.

Engineering stories

Six self-contained stories from this project. Each opens the full implementation.

Next case

Absolute Support

A custom compression-commerce experience built on Dawn while preserving Shopify's native product and filtering engines.

View case

Need a Shopify engineer who can work across the full commerce path?

I work where storefront UX, product logic, platform constraints, measurement, and production delivery meet.

Start a conversation