One of the most reliable bills in any growing Shopify store is the apps line. By year two, most merchants are paying for somewhere between five and fifteen apps. Reviews. Wishlist. Size guides. Upsell. Announcement bars. Quantity breaks. Subscriptions. Each one solves a real problem. Each one ships its own JavaScript bundle, its own stylesheet, its own admin surface. By year three, the storefront is slow, the design language is fighting itself, and the apps line is north of $1,000 a month.
This is the story of replacing five paid Shopify apps with native theme code on a single client storefront. What we cut, what we kept, and what we learned about which apps are worth their bill.
The starting point
The merchant was a growing apparel brand on Shopify Plus, doing roughly $4M annually. Their app stack at the start:
- Reviews — $89/mo. Powering the star rating + UGC reviews on product pages.
- Wishlist — $49/mo. Save-for-later functionality.
- Size guide — $29/mo. Category-specific size charts surfaced in a modal.
- Upsell — $799/mo (yes, really — usage-tier pricing on a high-volume store). In-cart cross-sell suggestions.
- Announcement bar — $29/mo. The strip across the top of the site for promos.
Total: $995/mo, $11,940/yr.
The performance picture, before any changes: 11 third-party scripts loaded on every page. Lighthouse Performance score of 41. Largest Contentful Paint of 4.3 seconds. The reviews app alone was responsible for ~600KB of compressed JavaScript.
The audit
Before touching anything, we spent a week measuring. Specifically:
- Which apps were actually being used by visitors? Wishlist saw 4% engagement. Reviews saw 31%. Upsell was driving 7% of cart adds.
- Which apps were being used by the merchandising team? The announcement bar got changed twice a month. The size guide got updated quarterly. Wishlist had no admin-side activity at all.
- Which apps had features the merchant was actively paying for but not using? Roughly half of the upsell app’s feature surface was unused.
The audit shaped the playbook: we’d replace what we could replace cheaply, keep what was genuinely complex, and re-think the rest.
Reviews — kept the data, replaced the surface
This was the hardest call. Reviews are the kind of feature that looks simple until you start listing requirements: moderation queue, photo uploads, email request flow, schema.org markup, importing reviews from previous apps, syndication to Google Shopping.
We didn’t try to rebuild all of that. We kept the underlying review storage in the existing app, but rebuilt the storefront-facing rendering as native Liquid. The app’s own front-end (heavy JavaScript, slow to render, off-brand styling) was disabled. We pulled the review data via the app’s API and rendered it server-side in Liquid, with a small JavaScript layer for filtering and pagination.
Net result: the review experience kept all its data and merchant features, but lost ~600KB of JS and rendered with the rest of the page instead of after a network round-trip. Performance jumped without losing functionality.
Wishlist — replaced entirely with native code
Wishlist is one of those features where the SaaS solution is dramatically over-built for what most merchants actually need. The merchant we worked with needed: save a product, view your saved list, get a reminder email. That’s it.
We built it as native theme code in about two days:
- Saved products live in
localStoragekeyed by variant ID, with an opt-in sync to a customer account when they’re logged in. - The wishlist page renders server-side from a simple shortcode-style include.
- The reminder email runs as a Shopify Flow workflow firing 7 days after a wishlist add — no app required.
$49/mo gone. Performance impact: zero net JavaScript added; one app removed.
Size guide — replaced with metafield-driven Liquid
This one was almost embarrassingly simple. The size guide app stored size-chart data per category and rendered it in a modal. The same thing as a Shopify metafield + a Liquid section: ~80 lines of code.
We migrated the size-chart data into category metafields, deleted the app, and the modal still worked exactly the same way. The merchant noticed nothing. $29/mo gone.
Announcement bar — replaced with theme settings
The announcement bar app was paying $29/mo for what is, structurally, a single Shopify theme setting. We added two theme settings (text + link), wrote a 30-line Liquid block at the top of the layout, and gave the merchandising team direct edit access via theme customization.
Total time: half a day. $29/mo gone.
Upsell — the hard one
The upsell app was the expensive one and the one carrying real complexity. Its feature surface included:
- Rule-based cross-sell suggestions (“if cart contains X, suggest Y”).
- AI-driven recommendations.
- A/B testing of upsell positioning.
- Per-collection upsell rules.
- Post-purchase upsell page.
The merchant was using rule-based cross-sells and the post-purchase upsell. They were not using the AI recommendations or the A/B testing surface. We rebuilt only what they were actually using — rule-based cross-sells from product metafields, plus a Shopify Plus post-purchase script — and dropped the rest.
This took the longest by far. The upsell rules engine alone was a couple of days. The post-purchase script was another full day. But $799/mo of recurring spend got removed — payback was inside two weeks of dev time.
What we kept
Two apps survived the audit: the email service provider (Klaviyo, because rebuilding email automation natively is genuinely not worth it), and the helpdesk (Gorgias, same reason). Both are doing real work that would take dev-months to replace and never quite reach parity. The rule of thumb: if the SaaS is doing genuinely complex work that lives mostly outside your storefront, keep it. If it’s adding a UI feature, you can probably build it.
The numbers, after
Three months after the project finished:
- $16,800 / year removed from the apps line.
- Lighthouse Performance: 41 → 83.
- LCP: 4.3s → 1.6s.
- Third-party scripts: 11 → 3.
- Conversion rate on mobile: +14% over the next quarter (we can’t attribute all of that to the speed work, but the timing lines up).
The principle
Apps make sense when you start. Every one of them solved a real problem at the moment you installed it. But “we already have an app for that” is not the same as “we still need an app for that.” Every twelve months, audit the stack: what’s being used, what’s not, what’s being paid for that the team isn’t using, what’s slowing the storefront down. Most stores can cut the apps line by 50% without losing a single feature their customers actually use.
The dev cost of replacing an app is usually one to three days per app. The recurring savings compound. The performance wins are immediate. And the design language stops fighting itself.
Want a similar audit on your stack? See the speed-optimisation service.