A client of mine sells on monthly subscriptions through his Shopify store, and he came to me with a problem that was quietly costing him customers every single month. His subscribers couldn't edit their monthly subscriptions the way they needed to. Month after month, they kept receiving products they no longer wanted — and the only control that felt available to them was the cancel button. So they used it.
He asked me to find a solution. The answer wasn't to rip out Recharge — his subscription app, the place where all his subscriptions and customer data already lived. The answer was to keep it, and build the part his customers were missing on top of it, through Recharge's own API. What follows is what we built, and what happened after.
What was happening to his customers?
Put yourself in the subscriber's chair. You signed up happily. A few months in, your needs change — you have enough of one product, you want to try another, your usage drops. You log in to adjust your subscription the way you need to — and you can't. Next month the box arrives again, with the same products you already decided you don't want.
At that point the subscription stops feeling like a convenience and starts feeling like a trap. And a customer who feels trapped doesn't write a long feedback email. They cancel, and they don't come back.
His customers weren't cancelling because they stopped liking the products. They were cancelling because cancel was the only button they had.
That's the part most store owners miss. This wasn't a product problem or a pricing problem. It was a control problem — and control problems are fixable. Stores lose people the same way at checkout: one moment where continuing gets harder than leaving. We broke that pattern down in the 7 checkout killers — his store was running the subscription version of it, every month, on repeat.
What was actually missing?
I went through Recharge myself before we built anything, because I wanted to be precise about the problem. And I'll be precise here too, because it matters: Recharge is not a toy. Its own documentation shows that merchants can let customers add and swap products and update variants through the customer portal — Recharge's guide to adding or swapping a product or variant walks through it, setting by setting. The subscriptions, the billing, the customer data — that engine was doing its job.
On Shopify this is the normal shape of things anyway: subscriptions run through an app, and the app holds the subscriptions and the data — Shopify's subscription documentation lays out the model.
What his store needed was editing that worked a specific way for his customers — and a standard portal, built for the average store, wasn't how they were going to get it. That's a different problem from "the feature doesn't exist," and it has a different solution. Recharge opens its subscription data through an API precisely so a store can build its own customer portal on top — their guide to building a custom customer portal with the Recharge API is written for exactly this. So that's the road we took.
The standard setup vs the portal we built
| Before: the standard setup | After: the custom portal | |
|---|---|---|
| What runs the subscriptions | Recharge | Recharge — unchanged |
| Subscription data and billing | Inside Recharge | Inside Recharge — nothing migrated |
| How customers edit | The standard portal's way | Built the way this store needed |
| Where the customer-facing portal lives | Inside the app | His own hosting, our code, on Recharge's API |
| The result | Cancellations | Orders up — and cancelled customers came back |
Why not just switch subscription apps?
It's the obvious question, and anyone who runs a subscription store will ask it: some subscription apps do advertise product swaps, so why not just move him to one of those?
Switching was genuinely on the table. And three things are true about it no matter which store you run:
- A feature on a pricing page is not the feature working your way. "Swap" means something slightly different in every app — different rules, different limits, a different flow for the customer. A ticked feature box can still leave your customers short of the exact control they were asking for.
- Switching means migrating live subscriptions. Every active subscriber — their subscription, their saved payment method, their next order date — has to move to the new system without a single billing failure. That's surgery on live, recurring revenue, and it carries risk even when it goes well.
- A better app is still someone else's roadmap. Whatever you switch to, the next feature your customers need restarts this exact conversation.
But I'll be straight with you: the deciding factor on this project was simpler than all three. The other subscription apps were costly — and the client already had a lot of data and a lot of live subscriptions sitting inside Recharge. Paying more, every month, to move everything he already had into another app that still wouldn't be his made no sense.
So we didn't switch. We kept Recharge — the subscriptions, the data, the billing, all of it — and built the missing piece on top of it.
What we built on top of Recharge
We purchased hosting and wrote the complete code ourselves for a custom customer portal — a portal that talks to Recharge through its API. Recharge kept doing what it already did: holding the subscriptions, the data, the billing. The portal is the part his customers touch, and it was built to let them edit their subscriptions the way this store needed.
I'll be straight about the trade-off, because it's real: custom took a little while. Enabling a setting takes an afternoon; a proper build doesn't. What he got at the end of it, though, was an asset — a portal on his hosting, in front of the Recharge engine he already had, doing precisely what his business needed.
There's one more thing the build gave him: the part his customers actually touch is his. Apps redesign their portals and change their settings over time — the engine underneath his store stayed exactly where it was, and the experience on top of it sits on his hosting, in code written for his store.
What does the portal let his customers do?
One thing, and it's the thing that mattered: a customer can now edit their own monthly subscription. When their needs change, they change what they receive — before the next order, not after another unwanted box lands on the doorstep.
No support ticket. No "please email us to change your order." No cancellation form as the only exit. The control his customers were asking for, in their hands, self-serve.
What happened after it went live?
His orders went up. And the part I didn't fully expect: customers who had already cancelled started coming back.
That makes sense when you think about why they left. They never left over the products — they liked the products. They left because leaving was the only way to stop receiving the wrong ones. The day editing became possible the way they needed it, the reason for cancelling disappeared. (It's the same principle behind recovering abandoned carts: most "lost" customers aren't lost over your product. They're lost over a moment where buying — or staying — got harder than leaving.)
We didn't win those customers back with a discount code or a win-back campaign. We won them back by removing the reason they left.
FAQ
Why couldn't his customers just contact him to change an order?
Some did, at first. But every change becomes a support conversation — an email, a wait, a reply — and most people won't do that twice for a monthly order. Faced with "write an email every time my needs change" versus "click cancel once," people click cancel. If a change isn't self-serve, for most customers it effectively doesn't exist.
Can't subscription apps normally do this?
Often, yes — and Recharge is one of them. Its documentation shows customers can swap products and update variants through the customer portal when the merchant enables it in the portal settings — that's Recharge's own guide. So the honest question is never "does the feature exist?" It's "does it work the way my store needs it to?" For the baseline customers expect, Shopify's documentation on the subscription customer experience lists what shoppers can do from their accounts — update payment details, change the address, skip an order, pause or cancel. If the standard setup gives your customers what they need, use it. If it doesn't, you have three options, not two: live with it, switch apps and migrate everything, or keep the app and build your own portal on its API. We took the third.
Is a custom portal worth it for a smaller store?
If subscriptions are a small side channel, probably not — live with the standard portal. If subscriptions are the business and the standard setup is costing you customers, the math changes — and building on the API of the app you already run is usually the cheapest of the real fixes: no migration, no second monthly app bill, your data stays exactly where it is. Every customer who stays instead of cancelling is recurring revenue you keep, every month. And if you're already paying for a bigger plan plus a stack of apps, it helps to know what your Shopify plan actually covers before renting one more tool to fix the last one's gaps.
Who owns a custom build like this?
The portal is his — his hosting, code written for his store. The subscriptions and billing stay in Recharge, which is exactly the point: we didn't move his engine, we rebuilt the part his customers touch. If the app changes around him, the portal his customers know is still his code.
If your customers are stuck with a standard setup that almost does what they need — and "almost" is costing you the customers themselves — that's a build conversation, not another app trial. Send us the setup you're running and the one thing it needs to do differently for your customers, and we'll tell you straight whether a custom portal on top of it is worth it: Custom websites and web apps at Lynxwell.
