Custom Shopify Subscriptions Beyond the Apps

You have outgrown an off-the-shelf Shopify subscription app when your billing needs a rule the app cannot express, or when the percentage it skims off recurring revenue has grown into a real line on your books. For a plain "ship the same thing every month" program, the leading apps are the right answer and you should keep using them. The build case appears when your offer gets specific: build-a-box with swap rules, prepaid and metered terms, a dunning policy you actually designed rather than accepted, or per-plan logic no template anticipated. Owning the billing does not mean leaving Shopify. It means using Shopify's own subscription primitives directly, so the recurring logic, the contracts, and the retention rules are yours, with no revenue share and no ceiling on what you can offer.

The short version

Two costs push stores off the apps: the fee and the fit. A percentage of recurring revenue compounds on your most valuable income, and templated logic bends only so far before you are shaping the offer around the tool.
Dunning is where subscription revenue quietly leaks. How you retry failed cards, message subscribers, and time cancellations decides retention more than acquisition does, and off-the-shelf dunning gives you knobs, not a policy.
Shopify already provides the foundations. Selling plans and subscription contracts are native, billed through checkout, so a custom build extends Shopify rather than working around it.
Prepaid, metered, and build-a-box are the usual breaking points. Real programs combine terms that single-model tools were never designed to express cleanly.
Migrating billing is a careful move, never a switch. Live payment methods, active contracts, and next-charge dates have to be carried across without a missed or double charge.
You own the contracts and the history. The recurring relationship is the asset; owning its logic and data is what makes it worth building.

Where do off-the-shelf subscription apps stop?

The established subscription apps are genuinely capable, and for a common model they are a fast, sensible yes. The strain shows up as your program gets distinctive, and it tends to show up in the same five places.

A fee that scales with your success. Many apps charge a percentage of subscription revenue on top of their monthly cost. On a single order it feels trivial; across your most predictable, most valuable income, every month, it is a standing tax on the exact revenue you worked hardest to build.
Build-a-box and dynamic bundles. Letting a customer assemble their own recurring box, with minimums, swap windows, and pricing that reacts to what they chose, is where templated subscription flows tend to buckle, because the app models a fixed line item, not a composed one.
Prepaid, metered, and hybrid terms. Prepaid multi-month plans, usage-based charges, gifting, and combinations of all three are ordinary in real businesses and awkward to express in tools built around one simple recurring shape.
A dunning policy you chose. Failed payments, retry timing, pauses, win-backs, and cancellation flows are the machinery of retention, and off-the-shelf tools hand you a few settings where you need your actual policy, expressed the way you would describe it.
The relationship living in someone else's system. When the contracts, payment methods, and history sit inside a vendor's app, your recurring relationships are effectively rented, with the switching cost that implies the day you want to change anything.

Read together, these follow the familiar shape of a rented tool: it does the standard version well, but recurring revenue is where the specifics live, and specifics are where a template quietly costs you margin and flexibility at once. The decision of when that trade tips toward building is the same one we frame in the build versus buy framework.

Why does dunning decide your subscription revenue?

Most owners think of subscription growth as an acquisition problem and are surprised to learn how much of it is really a retention-plumbing problem. A meaningful share of the subscribers you lose never chose to leave. Their card expired, their bank declined a routine charge, or a temporary hold bounced the payment, and the billing system quietly gave up. That is involuntary churn, and it is the least glamorous and most recoverable revenue in the business, because these customers still want the product; the machinery simply stopped charging them.

Dunning is the machinery that recovers them, and its details are where policy lives. When do you retry a soft decline versus a hard one, and on what schedule? Do you attempt a small pre-dunning nudge before the card fails, prompting the customer to update details? How many attempts before a pause rather than a cancellation, and what does each email actually say? Off-the-shelf dunning offers a handful of toggles that approximate these decisions; owning the logic lets you encode the exact sequence you would design, tuned to your customers and your product. This is retention engineering, not messaging garnish, and it pairs naturally with giving subscribers a real place to manage their own plans, the self-service portal Shopify does not give you. The mechanics of retries, proration, and payment-method health are deep enough that we treat them as their own topic in the subscriptions and billing guide.

What does owning subscriptions on Shopify actually involve?

Owning your subscriptions does not mean rebuilding checkout or leaving the platform. Shopify provides the real foundations natively: selling plans that define the recurring terms, and subscription contracts that represent the ongoing agreement with a customer. The important detail is how they fit together at the moment of sale. As Shopify's subscriptions documentation describes, when a product with a selling plan is purchased through checkout, Shopify automatically creates a subscription contract, and that contract, billed through Shopify's own checkout, becomes the thing your logic manages from then on. A custom build uses those primitives directly instead of through a vendor's wrapper, which is what removes the revenue share and the template ceiling in one move.

Built on that foundation, a custom program gives you pricing and plan logic expressed exactly as you sell it, whether that is build-a-box, prepaid, metered, or a hybrid; a subscriber experience that feels like part of your store rather than a bolted-on widget; dunning and retention that follow your policy rather than a default; and clean connections to fulfillment, accounting, and your numbers so recurring orders flow without anyone touching them, in the spirit of connecting your stack instead of copy and paste. The cost and shape of that work is the wider question we walk through in what custom software actually costs, because a subscription build is a system, not a feature.

How do you move a subscription program safely, step by step?

Recurring billing is money on a schedule, and a schedule leaves no room for a sloppy cutover. The way to migrate without frightening anyone is to make it a sequence of proven, reversible steps rather than a single flip:

Map the program you have and the one you want. Document every current plan, price, term, and dunning behavior, then the rules you actually want, and reconcile the two. Most of the real design work is here, before code, where changes are free.
Model the plans in Shopify's primitives. Express each plan as selling plans and the resulting contracts, confirming that the terms you sell can be represented natively rather than faked with workarounds that will haunt you later.
Build and test the billing on a development store. Prove the ordinary path and, more importantly, the awkward ones: a failed charge, a mid-cycle pause, a proration on an upgrade, a swap inside a build-a-box, before any real subscriber is involved.
Rehearse the migration of live contracts. Active subscriptions carry payment methods, next-charge dates, and remaining prepaid terms that must move across exactly, so run the migration against a copy and reconcile every contract before it touches production.
Cut over a small cohort first. Move a limited group of subscribers, watch a full billing cycle complete correctly, and confirm dunning and notifications behave, so going live is a confirmation rather than a leap of faith.
Migrate the rest and retire the app. With the pattern proven on real charges, bring across the remaining subscribers and decommission the old tool, so you are not paying for and reconciling against two billing systems at once.

A checklist before you replace your subscription app

Can you name the specific plan, pricing, or dunning rule your current app cannot express?
Have you added up the revenue-share fee across a year on your actual subscription volume?
Do your terms (prepaid, metered, build-a-box, gifting) map cleanly onto selling plans and contracts?
Have you written down your real dunning policy: retry schedule, pre-dunning nudge, pause-versus-cancel thresholds?
Is there a plan to carry live payment methods and next-charge dates across without a missed or double charge?
Will the new billing connect to fulfillment and accounting so recurring orders flow without manual handling?
Do you have a small pilot cohort to prove a full billing cycle before a full migration?
Are the contracts, payment methods, and history yours to keep, with no lock-in?

Common pitfalls

The mistakes in subscription billing are expensive in a particular way, because an error repeats on every cycle and often stays invisible until the revenue has already leaked.

Treating a failed payment as a lost customer. The default behavior in many setups is one retry, then cancel, which throws away subscribers who never intended to leave and would have stayed with a smarter retry or a prompt to update a card. Involuntary churn dressed up as ordinary churn is the most common and most recoverable leak in the whole model.

Shaping the offer around the tool. When the app cannot do build-a-box cleanly, stores quietly simplify the box to fit the app, trading away the exact flexibility that made the offer appealing. The tool should serve the offer; the moment the offer is being trimmed to suit the tool, the relationship has inverted.

Underestimating the migration. Moving subscriptions is not moving products. Each active contract is a live financial agreement with a stored payment method and a next-charge date, and a careless cutover can miss charges, double-charge, or reset billing dates, which is the fastest way to turn a technical project into a trust problem with your best customers.

A concrete case. A consumables brand ran a healthy subscription program on a standard app and could not understand why its active subscriber count kept sliding despite steady new signups. The leak was entirely in dunning. The app retried a declined card once, the next day, then cancelled, and a large share of its declines were expired cards and temporary bank holds that a second attempt a few days later would have cleared. There was no pre-dunning email, so customers never learned their card was about to fail, and no card-updater step, so a reissued card meant a dead contract. We rebuilt the billing on Shopify's native contracts with a real retry schedule spaced across several days, a heads-up message before the charge, and a pause path instead of an instant cancel. The subscribers being lost to the billing plumbing, rather than to any decision of their own, largely stopped leaving, and the recovered recurring revenue dwarfed the cost of the build within a couple of cycles. The lesson was not that the app was bad; it was that a default dunning policy is nobody's actual policy, and on recurring revenue the default is the leak.

How we build it without risking your recurring revenue

The part of your business where a billing mistake is least forgivable is also the part we test most before trusting, and the build is arranged around that fact. We begin with discovery, mapping how your plans, billing, and retention truly work and should work, and you get a plan and a fixed price for a first phase with nothing else committed. That phase is usually the core billing logic for one plan type, built and validated against the awkward cases on a development store before a single live subscriber depends on it, then piloted with a small cohort through a full cycle. You own the logic, the contracts, and the data outright, with no lock-in, and launching a new plan or changing a dunning rule becomes a direct conversation with the person who built it rather than a feature request to a vendor. The care in that order is the product: your recurring revenue is protected at every step because nothing goes live until it has proven it charges correctly.

If your subscription model has outgrown the app running it, or the revenue share has started to sting, you have options that keep you on Shopify and put the logic back in your hands. Tell me how your subscriptions actually work and I will give you a straight read on what a safe first phase to own them would look like.

FAQ

When should I move off a Shopify subscription app to a custom build?

When you can name a specific thing the app cannot do, or when its cut of your recurring revenue has become material. If your model is a simple recurring shipment and the fee is small against your volume, stay on the app. The build case is concrete: a plan type it cannot express, a dunning policy it cannot follow, a build-a-box it cannot handle cleanly, or a revenue share that now costs more each year than owning the logic would. Vague dissatisfaction is not a reason to build; a rule you cannot implement is.

Do custom subscriptions still run through Shopify checkout?

Yes, and that is the point of building on Shopify's own primitives rather than around them. Selling plans and subscription contracts are native, and a subscription contract is created automatically when a product with a selling plan is bought through checkout, so billing continues to run on Shopify's rails. A custom build controls that logic directly instead of through a third-party app's wrapper, which is what removes the revenue share and lifts the limits on what your plans can do, without moving your customers off the checkout they already trust.

What is dunning and why does it matter so much?

Dunning is how your billing responds when a recurring charge fails: the retries, the timing, the messages to the customer, and the decision to pause or cancel. It matters because a large portion of subscriber loss is involuntary, driven by expired or temporarily declined cards rather than a customer choosing to leave, and a well-designed dunning sequence recovers many of those payments. Off-the-shelf tools give you a few settings; owning the logic lets you encode the exact retry schedule, pre-failure nudge, and pause path you would design, which is often the single highest-return change to a subscription program.

Can I offer prepaid, metered, or build-a-box plans with a custom build?

Yes, and these are usually the reason a custom build is worth it. Prepaid terms, usage-based charges, gifting, and customer-composed boxes with swap and minimum rules are exactly the shapes that single-model apps struggle to express, so stores end up simplifying the offer to fit the tool. Building directly on selling plans and contracts lets each of these be modeled as you actually sell it, including hybrids that combine several terms, so the plan the customer sees matches the plan you designed rather than the nearest thing the app allowed.

How do you migrate existing subscribers without breaking billing?

Carefully, and never in one step. Every active subscription is a live financial agreement carrying a stored payment method, a next-charge date, and any remaining prepaid term, all of which must move across exactly. We rehearse the migration against a copy and reconcile every contract, cut over a small cohort first and watch a full billing cycle complete correctly, then migrate the rest once the pattern is proven on real charges. Only then is the old app retired, so you are never blindly trusting an untested cutover with money that charges on a schedule.

Will I own my subscription data and logic?

Yes, and owning it is the durable reason to build. The plan logic, the subscription contracts, the stored relationships, and the billing history are yours, held on Shopify's native primitives with no third-party lock-in, so you are not renting access to your own recurring revenue. That ownership is also what keeps you flexible: changing a price, adding a plan, or revising a retry rule is a change you request from the developer who built it, not a limitation you have to design around while waiting on a vendor's roadmap.

Subscriptions Your Way: When Off-the-Shelf Shopify Billing Doesn't Fit