It usually arrives as a support reply. Polite, prompt, and final: that isn't something the app supports. Maybe you wanted a swap rule the settings page has no field for. Maybe your cancellation flow needs to make an offer the built-in one can't make. Maybe "you'd need a developer for that" is the exact sentence you got back.
This article is for that moment. I build past Seal's limits for a living, so I'll be specific about where the ceiling actually is, what Seal's own APIs allow beyond it, and what your real options are — including the ones that don't involve hiring anyone.
Merchants hitting the ceiling describe it better than I can:
[TK: 5–10 verbatim limitation complaints from Seal's public reviews — Saif harvests; use their phrasing here.]
Different stores, same shape: the program needs a rule, and the settings page doesn't have a field for it.
First, be fair to the settings page
Seal's configuration genuinely covers a lot, and I say that as the person merchants call when it doesn't. The native portal offers theming and per-feature toggles — colors, labels, which actions subscribers can take — and a built-in cancellation flow. For many stores, that's honestly enough. The standard machinery of subscriptions — billing, scheduling — is the part I hand to Seal on The Cumin Club's program, after years of running billing fully custom on Stripe. The app does that part well. The native portal, we never used — custom from the start.
So spend an honest hour in the settings before concluding you've outgrown them. Read the documentation page for the feature you want, not the marketing page. Ask support a precisely worded question — "can a subscriber swap to a product in a different collection from the portal?" gets a more useful answer than "can I customize swaps?" Some ceilings evaporate under a well-phrased question.
If it's still a no, you have three real options. Only three.
Option one: reshape the program to fit the app
Unpopular, sometimes right. If the rule you can't build is marginal — a nice-to-have cadence variant, a fourth swap path — the cheapest fix is not building it. The best stack is the least custom one that fits, and sometimes the program can fit with one fewer rule.
The test: would dropping the rule cost you subscribers, or just win an internal debate? Be honest about which. If the rule is load-bearing — it's why subscribers stay, or its absence is why they leave — keep reading.
Option two: extend Seal through its APIs
This is the door most merchants don't know exists. Seal isn't only a settings page; it exposes APIs a developer can build against, and its documentation includes a JavaScript API for overriding the cancellation flow entirely. "The app can't do X" usually turns out to mean "the app's UI can't do X" — which is a different sentence, with a different price tag.
What lives past the UI, from work I've shipped on it for The Cumin Club: custom account management for subscribers, admin infrastructure the team runs the program from, retention logic the app doesn't ship. The app keeps doing what it's good at — billing, scheduling, the standard machinery — and code you own handles the parts that make your program yours.
Here's the worked example I walk merchants through most often.
Worked example: owning the cancellation flow
Stage one — the default. Seal's native portal includes a built-in cancellation flow, configurable within its options. Every store starts here, and plenty should stay here.
Stage two — the override. Seal documents a JavaScript API for overriding that cancellation flow entirely: your own popups, your own survey, your own logic about what happens when a subscriber clicks cancel. This is a documented door, not a hack — the app expects developers to walk through it.
Stage three — the owned flow. Through that door, cancellation stops being a settings page and becomes a revenue surface you design. The flow I'd build there: find out why this subscriber is leaving, then answer the actual reason. Too much product — offer a longer cadence or a pause. Too expensive — offer a smaller box. Moving house — offer a date change. Genuinely done — let them go cleanly, quickly, and record why. Save offers matched to the stated reason, not one blanket discount popup for everyone. All of it on your brand, all of it yours.
The same ladder — default, override, owned — applies past cancellation. Two more, briefer:
Account management past the portal
The portal covers subscriber self-service basics. When the program needs more — one branded place where the subscription, order history, and preferences live together — that's buildable against the APIs rather than a reason to leave the app. The Cumin Club's portal was custom from day one — account management built on Seal's APIs rather than the native portal, still running on Seal today.
Admin and ops tooling
Settings pages are built for the average store's operations. If your team runs a playbook the admin UI doesn't have buttons for — bulk changes with your rules attached, internal dashboards, the reports finance actually asked for — that's admin infrastructure a developer builds beside the app. The Cumin Club's team runs its program from infrastructure like this.
Option three: go fully custom
The nuclear option, and occasionally the right one. I've built fully custom subscription billing — The Cumin Club's platform began that way in 2019–20, Next.js and Stripe, every rule exactly as specified. I've since moved that same program onto Shopify and Seal — the ecosystem and its first-party integrations were worth more than the custom stack. Owning billing machinery an app runs perfectly well is a cost, not an asset. I've lived both directions, and that's exactly why my default advice is: don't.
Fully custom is right when the subscription mechanics themselves are the product — when the program's core rules genuinely can't be expressed on any app, even through its APIs. It's wrong when it's chosen out of frustration on the day the settings page said no. The difference between those two is a boundary question, and it deserves an hour of clear thought, not a mood.
How to decide, in one sitting
Write down the thing the app can't do as one sentence, in program terms — not "Seal is limited" but "a subscriber who pauses twice in a row should get a different offer the second time." Then walk the ladder:
- Can the settings express it? Configure it and stop.
- Is it marginal? Drop it and stop.
- Can it be built against the APIs? That's a scoped development project, not a replatform.
- Is the whole program inexpressible on the app? Then you're in custom territory — walk in with open eyes.
Most merchants who write to me are standing on rung three and don't know it. The app didn't run out; the settings page did.
If you'd rather have that judgment call made on your actual store than in the abstract, I do a free teardown — a short recorded review of your live subscription flow, naming 2–3 revenue leaks and, where it's relevant, which rung of the ladder each fix lives on. No pitch attached. Get a free teardown →
And if the limit you've hit has you eyeing a different app entirely, read Seal Subscriptions vs Recharge: a practitioner's comparison before committing to a migration — moving apps relocates ceilings more often than it removes them.