← All case studies

CartRush (my own multi-store app)

A Post-Purchase App Built Once, Deployed Across Stores

Post-purchase upsell funnels move AOV, but building one bespoke, per store, every time a new store wants the same capability is exactly how engineering becomes the bottleneck.

  • Shopify Plus
  • Post-purchase API
  • Node.js
  • Admin-configurable app
15%AOV increase across every store running the app

Context

CartRush is a post-purchase funnel app I built to run across multiple Shopify stores rather than as a one-off build for a single client. Among the stores running it was a US sports supplement brand doing serious monthly volume.

The problem

Post-purchase upsell funnels move AOV, and the underlying accept-and-decline branching logic is well understood. But building one bespoke, per store, every time a new store wants the same capability, is exactly the kind of work that turns engineering into a bottleneck for something that should just be configuration.

The constraint

Every store’s product catalog, pricing, and offer logic is different, so the app couldn’t hardcode any of that. But it also couldn’t need a developer involved every time a new store wanted to launch a funnel or adjust an offer. That would just recreate the original problem with extra steps.

The approach

I built the three-level accept-and-decline flow as an admin-configurable app: each level’s product, add-on, or discount is set from the admin panel, not the codebase, while the flow logic itself is a fixed frame that adapts to whatever offers a given store’s admin configures.

The alternative I rejected was a client-specific implementation per store. Faster for the first store, and a near-total rebuild for every store after it, with no leverage gained from having done it before.

The result

Deployed across multiple stores, with AOV increasing 15% across the stores running it, and no per-store engineering work required to launch or adjust a funnel.

What I’d do differently

I’d build the analytics layer, which levels convert and where declines happen, into the first version instead of adding it after multiple stores were already live. It’s the data that tells each store’s team how to adjust their own offers, and it’s more valuable the earlier it exists.