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
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.
- 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.
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
- 01Selected pack
- 02Subscribe versus one-time
- 03Billing cadence
- 04Visible price equals billed price
- 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 dive03
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 diveDrawer-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 dive05
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 diveSupporting 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 storyResults 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
- 01
Measure real users, not only synthetic scores.
Lab tools are diagnostics, not a verdict on the experience your visitors actually get.
- 02
Scope logic to the actual commerce context.
On a page with multiple forms and sections, a document-wide query is a latent bug.
- 03
Keep the visible offer equal to the billed offer.
Pricing a shopper cannot trust is a conversion problem, not a cosmetic one.
- 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.
- 01Published
Custom subscription buy box on native selling plans
Subscribe UX on Shopify Selling Plans with Recharge as processor, and pack size mapped to billing interval from plan text with no hardcoded IDs.
Selling plansRechargeRead - 02Published
Commerce state without a frontend framework
Three DOM-disjoint components kept consistent by message passing, and three silent cart failures traced to one shared root cause.
Vanilla JSAJAX CartRead - 03Published
Measuring real users, not only PageSpeed
A small RUM pipeline that found a layout-shift spike the lab could not see, and the ordered fixes that removed it.
Core Web VitalsRUMRead - 04Published
Migrating 66 subscriptions from Loop to Recharge
A controlled, right-sized migration when the API route was closed, validated field by field before commit and timed to avoid double charges.
RechargeMigrationRead - 05Published
Shipping safely to a co-edited live Shopify store
A delivery workflow built around branch-to-theme mapping and daily Customizer edits, so releases never overwrite live merchandising.
GitHubDeliveryRead - 06Published
Instrumenting Shopify across the theme and checkout boundary
Separated storefront and checkout pipelines with a vendor-neutral event seam, and the privacy limits stated plainly.
Web PixelAmplitudeRead
Next case
Absolute Support
A custom compression-commerce experience built on Dawn while preserving Shopify's native product and filtering engines.
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
