If you're the developer or technical lead at a Shopify subscription brand, you'll eventually get asked some version of: "Should we get off Recharge and build our own?"
It's usually framed as binary. It isn't. In 2026 there are three viable architectures, and the one in the middle — keep Recharge as the billing engine, build a custom layer on top — is the right answer for more brands than the other two combined. It's also the one nobody writes about, because app vendors don't profit from it and comparison posts don't think in architectures.
Here's the decision guide I wish more teams had before they either rebuilt billing infrastructure they didn't need to, or spent two years duct-taping around an app they'd outgrown.
What you're NOT going to rebuild better
Recharge is the most widely deployed of the Shopify subscription apps (alongside Skio, Loop, Stay AI, Appstle, and Shopify's native Subscriptions app), processing billions in transactions annually. That scale means the operationally brutal parts are already engineered:
- Dunning and payment retry — retry cadence, fallback logic, recovery messaging. Years of tuning. The difference between recovering a failed card and losing the subscriber.
- The no-code subscriber portal — skip/swap/pause/cancel/reschedule. Every one of those flows is harder to build than it looks.
- Cancellation interception and winback — configurable offers, surveys, pause options on the Pro plan.
- The connector ecosystem — Klaviyo, Gorgias, Postscript, Shopify Flow. Each would take months to build properly.
- Native Shopify Checkout integration — no redirected or split checkout on the current architecture.
For fixed-price, single-product, one-subscription-per-customer models, this covers you well past 5,000 subscribers. The architecture question only becomes real when your model stops being that simple.
The seven signals you've outgrown the app
Ordered roughly from earliest to latest:
Pricing depends on attributes Recharge can't read. Recharge knows fixed price or percentage discount. It doesn't know the customer's dog weighs 90 lbs, the household has five people, or the dosage scales with body weight. That logic has to live in a custom function reading customer metafields and updating the Subscription Contract before renewal fires — or in your ops team's manual updates, leaking margin every cycle.
Your data model is one-to-many. The app assumes one customer ↔ one subscription. Multi-pet households, corporate accounts with twenty employees, family meal plans with individual dietary restrictions — the structure underneath the portal simply doesn't exist in Recharge. You end up modeling it in metafields and rendering your own portal via the Storefront API.
State is scattered across systems Recharge doesn't own. ERP has inventory truth, 3PL has delivery cutoffs, CRM has loyalty tiers — Recharge has none of it. Symptom set: ~30 Zapier zaps, three Google Sheets nobody trusts, an ops engineer reconciling every Monday. A webhook-driven integration layer between Recharge and the operational stack is usually the highest-leverage build at this stage. It doesn't replace Recharge; it makes the systems stop disagreeing.
Portal requirements go brand-specific. Weight updates that re-price, diet swaps that affect the next renewal but not this one, add-ons bundled into the next shipment, tier upgrades. The no-code customizer can't surface any of it; past surface theming, it's API work.
Regulated category constraints. FDA/GMP rules, state-by-state sale restrictions, cold-chain delivery windows, age attestations. The validation has to run before the contract is created — in Checkout UI Extensions or Shopify Functions on Plus — not after.
The fee math flips. Pro plan: $499/mo + 1% + 19¢ per transaction. At 10K subscribers averaging $40/renewal that's ~$77K/year; at 25K, ~$183K/year. A fully custom build runs $100K–$200K plus $25K–$50K/year maintenance — below 5K subscribers it rarely pays off on cost; above ~15K it often pays back inside 24 months.
Workarounds outnumber configuration. The strongest signal isn't a missing feature, it's the pattern: zap → compensating Klaviyo flow → hand-updated sheet → Shopify Flow papering over a 3PL sync issue. At that point you're already running a custom subscription system — just unintentionally, with no architecture and no owner.
The three architectures
| Factor | Stay on Recharge | Recharge + custom layer | Fully custom (native APIs) |
|---|---|---|---|
| Subscriber count | < 1,000 ideal | 1,000–10,000 | 10,000+ usually |
| Build cost | None | $20K–$60K | $100K–$200K |
| Annual cost | Recharge fees | Fees + ~$10K–$20K maint. | $25K–$50K maint. |
| Time to live | Hours | 8–16 weeks | 16–32 weeks |
| Pricing flexibility | Fixed/percentage only | Fully custom | Fully custom |
| One-to-many data model | No | Yes (custom portal) | Yes |
| Regulated checkout logic | Limited | Yes (extensions) | Yes |
| Data ownership | Shared with Recharge | Shared with Recharge | Full |
| Per-renewal fees | 1–1.25% + 19¢ | 1–1.25% + 19¢ | Processor only |
| Engineering ownership | None | Light | Heavy |
Path 1: Stay
If your model is genuinely simple — fixed pricing, 1:1 data, standard connectors, no regulated logic — the right architecture is the one you have. The hard 80% is already built and battle-tested. Don't rebuild billing infrastructure because a blog post made custom sound exciting. This describes more brands than will admit it.
Path 2: Hybrid (the underrated one)
Recharge keeps billing, retries, dunning, and lifecycle. You build only the 20% it can't do. The five layers, in the order brands typically need them:
- Custom subscriber portal — Storefront API frontend, Recharge API backend. Brand-specific actions on top; contracts managed underneath.
- Integration layer — webhook listeners syncing subscription state into ERP/3PL/CRM. Ends the Monday reconciliation tax.
- Custom pricing function — reads metafields (pet weight, household size, tier), updates the Subscription Contract pre-renewal.
- Checkout extensions — compliance validation, delivery windows, age verification at the point of purchase.
- Headless storefront on Hydrogen with Recharge as backend — rarest of the five, only when subscription-page conversion is the bottleneck and Liquid can't go further.
Typical cost: $20K–$60K one-time plus light maintenance, on top of normal Recharge fees. Roughly half of all subscription brands between 1K and 10K subscribers fit here.
Path 3: Fully custom on native primitives
Shopify's native stack — Selling Plan API, Subscription Contracts, Customer Payment Methods — is mature enough that building directly on it is a real option. These are the same primitives Recharge itself builds on; you're just using them without the intermediary: Shopify Functions for in-checkout pricing/validation, a custom embedded admin app for merchant tooling, a custom storefront for subscriber flows.
The case is almost never cost at first — it's control. Your data model, your integration surface, no per-renewal fee, no vendor roadmap between you and your subscribers. Brands that fit usually check three boxes: past 10K subscribers, subscription is the product, and the hybrid path is already exhausted.
What the build actually consists of
Three layers, all on primitives that didn't fully exist three years ago:
Data layer. Canonical subscription state lives in the Subscription Contract object (price, next-charge date, frequency, line items, payment method). Everything Shopify doesn't model — pet profiles, household members, attestations, usage history — lives in customer metafields, or a custom app's own DB beyond key-value complexity. The sync between the two stores is part of the architecture, not a detail; it's where projects either stay clean or accumulate data drift.
Billing layer. The bulk of the engineering. A pricing function reads the driving attributes and writes the contract price before renewal fires; payment methods go through the Customer Payment Methods API; the renewal rides Shopify's normal billing flow. On Plus, Shopify Functions run the logic inside Shopify's infrastructure — so calculated prices appear live in checkout, not just at renewal. On standard Shopify the same logic runs as a webhook listener: works, but no in-checkout calculation. Dunning becomes a sequence you fully control — retry schedule, Klaviyo triggers, winback offers, terminal cancellation.
Experience layer. Custom portal (Storefront API or embedded app), onboarding that captures the data the pricing function needs (you can't price on pet weight you never collected), Checkout UI Extensions for validation, and email/SMS driven by the same webhook events as billing — so a subscriber who skips a renewal never gets "your shipment is on its way" two days later.
The point isn't reinventing subscription billing. It's building the entities your business runs on — the pet, the household, the compliance check, the integration — on top of the billing that already works.
The cost table, honestly
$40 AOV, Pro plan, 12 renewals/subscriber/year. Illustrative, not quotes:
| Scale | Recharge Pro/yr | Custom build | Custom maint./yr | Verdict |
|---|---|---|---|---|
| 1,000 subs | ~$13K | $100K | $25K | No. Stay. |
| 5,000 subs | ~$40K | $120K | $30K | Borderline — capability decides |
| 10,000 subs | ~$77K | $150K | $35K | Not on cost alone |
| 25,000 subs | ~$183K | $180K | $40K | Clear. ~18-month payback |
Breakeven on fees alone sits around 12K–15K subscribers for most models. Below that, custom has to justify itself on capability. And the table omits the usually-bigger number: opportunity cost — conversion lift from a portal that fits, retention lift from logic that doesn't fail, and the strategic value of owning rather than leasing the stack.
Migration is harder than the build
If you do leave Recharge, the dangerous part isn't writing the new system:
- Payment tokens are the killer. Cards saved under Shopify Payments can't be exported to a third-party processor. Stripe-held tokens sometimes transfer if the merchant-of-record relationship was scoped for it at signup — most weren't. If tokens can't move, every subscriber re-authenticates, and 60–70% re-auth rates are typical: you lose 30–40% of the base. Answer this question before scoping, not during.
- Contract state must move intact. Next-charge dates, frequencies, prepaid balances, pending swaps/pauses. A subscriber due on the 17th can't get charged on the 1st — and can't be skipped to hide the discrepancy.
- Cohorts, never big-bang. 50–100 subscribers first; validate renewals, charges, emails, portal access end-to-end; then scale. Weeks, not hours — because active subscribers have zero tolerance for a duplicate charge or missed shipment, and the trust cost of one always exceeds the engineering cost of prevention.
The framework, compressed
Stay if: <1K subscribers, simple 1:1 model, workarounds aren't multiplying, fees are a small share of revenue.
Hybrid if: 1K–10K subscribers, one or two specific gaps are real bottlenecks, you want Recharge's billing reliability, budget is $20K–$60K.
Fully custom if: 10K+ and complexity is growing, fees + workaround maintenance exceed ownership cost, subscription is the product, compliance or multi-entity data is non-negotiable — or you're already in subscription hell (three systems disagreeing, a Zapier graveyard, manual Monday reconciliation).
The two classic failure modes: a 3K-subscriber brand architecting like it's at 25K, and a 25K-subscriber brand still operating like it's at 3K while fees cross six figures.
The meta-point: this isn't a permanent identity, it's a stage-of-business decision. The brand that should stay on Recharge today may need the hybrid in 18 months and full custom 18 months later. Teams rarely fail at picking the right answer — they fail at noticing when the right answer changed.
*Originally published on the Codingkart blog
Top comments (0)