CASE STUDYTheme modernization · 2026

$1M+/month wellness brand

From a legacy theme buckling under app sprawl to a modern Online Store 2.0 build with Vite, Alpine.js, and zero jQuery — without losing a single SKU page in production.

Engineering led by Sergio Herrera as Lead E-commerce Developer.

01

The situation

The brand had grown from a small wellness operation to a $1M+/month DTC business on Shopify in under five years. The growth had outpaced the theme. What started as a clean Vintage-era theme had accumulated four years of patches: 40+ apps installed and partially uninstalled, jQuery scattered across templates, custom JavaScript bundled with no build system, and a steadily worsening performance curve.

The symptoms were what you'd expect. Page loads on mobile had crept past 5 seconds. The PDP carried 280KB of legacy JavaScript before any product code ran. Every time the brand wanted to install a new conversion app, the dev team braced for which existing flow it would break. The cart drawer had three different code paths from three different past developers, and nobody on the team was certain which one was actually firing in production.

The brand wasn't broken. It was profitable, growing, and operating at scale. But the technical foundation had become a tax on every future decision. A theme rebuild had been on the roadmap for over a year. The question wasn't whether — it was how to do it without breaking a $12M+/year revenue stream during the transition.

02

The approach

The constraint that shaped every decision was zero downtime, zero SKU loss, zero CRO regressions visible to customers during the transition. A clean-slate rebuild dropped behind a feature flag wasn't an option — the brand needed to keep selling at full velocity while the new foundation came online.

The path that worked was a phased migration: Online Store 2.0 as the target architecture, with the new theme built in parallel and rolled out section-by-section behind a soft launch on a duplicate published theme. This let us validate every change against real production traffic before the new theme became the live one.

Three architectural decisions defined the build:

Vite as the build system.

The legacy theme had no build process — all JavaScript was hand-bundled and minified manually. Moving to Vite meant proper module resolution, tree-shaking, code splitting per template, and HMR during development. The ROI on this single decision compounded across every later optimization.

Alpine.js to replace jQuery.

Most of the legacy JS was jQuery doing work that didn't need a 90KB framework. Alpine handled the same interactions in a fraction of the bundle size, with declarative syntax that made the templates easier to maintain. jQuery removal was completed in three passes, prioritized by template traffic.

Custom section architecture for editor flexibility.

Online Store 2.0's section-based system was the native solution to the "every app injects code somewhere different" problem. Sections were rebuilt with strict block schemas, allowing the merch team to compose pages in the editor without touching code — and crucially, allowing future apps to inject through defined extension points instead of monkey-patching templates.

One example of the kind of cleanup this enabled — the cart drawer's three competing code paths consolidated into a single Alpine component, ~50 lines of declarative state replacing ~600 lines of jQuery and untracked event listeners:

cart-drawer.liquid
<!-- After: 50 LOC, declarative, accessible -->
<div x-data="cartDrawer()" x-cloak>
  <button
    @click="open = true"
    :aria-expanded="open">
    Cart ({{ cart.item_count }})
  </button>

  <div
    x-show="open"
    x-transition
    @click.away="open = false">
    <template x-for="item in items" :key="item.key">
      <!-- line item -->
    </template>
  </div>
</div>

The full component shipped with proper accessibility, keyboard handling, and integration with Shopify's section-rendering API for cart updates without page reload — but the principle in the snippet above is what changed: declarative state where there used to be defensive event-listener spaghetti.

03

What shipped

  • A new Online Store 2.0 theme replacing the legacy Vintage architecture, built section-first with strict block schemas
  • A Vite-based build pipeline with per-template code splitting, replacing manual bundling
  • jQuery removed across the entire theme — 280KB of legacy framework code eliminated
  • Cart drawer, PDP variant logic, search, and quick-view rebuilt as Alpine.js components
  • 40+ apps audited; underused or duplicate apps consolidated or removed; remaining apps integrated through the new section extension points
  • Performance budget enforced at build time — failing builds prevented JS regressions from shipping
  • Phased rollout via parallel published themes, allowing section-by-section validation against live traffic
04

Results

Measured against the same Lighthouse mobile profile, same network throttling, same Chrome version, before and after.

LCP improvement
0.0s

Mobile LCP improved across the highest-traffic templates (PDP, collection, home).

JS removed
0KB

PDP first-load JS reduced by ~62%. Bundle now code-split per template.

Apps consolidated
0+

Final stack reduced to apps the business actually runs on. Extension points defined.

PDP first-load JS
0%

Reduction. Non-PDP pages no longer pay for PDP code.

What we don't claim
No revenue-lift claim attached.

A theme modernization is foundational work, not a CRO intervention. The point of the project was to remove the technical tax that had been blocking every CRO test and app integration the team wanted to ship. That foundation is now in place.

05

What this means for your store

If your Shopify store has been growing for more than two years, your theme has accumulated debt — every store does. The question is whether the debt is still affordable. Symptoms that say it's not: mobile LCP past 4 seconds, a cart or PDP that nobody on the team fully understands anymore, every new app launch feeling like a roll of the dice. If any of those sound familiar, a theme modernization is what we'd scope.

Most modernizations are a 6–10 week fixed-fee project, sometimes phased over longer. We start with an audit of the current theme to understand the debt and the business constraints. The audit either becomes the scope for the rebuild, or it becomes a roadmap you can hand to your existing team — either outcome is valid.

Engineering led by Sergio Herrera as Lead E-commerce Developer at the brand. Now an MTB Labs reference build.

Have a similar problem?

Start a project