Subscription setup: 6 hours → 4 minutes. Closing the gap between merchant language and plugin architecture.
Merchants abandoned subscription setup after hours of failure. The tools had every feature needed; they just spoke a completely different language than the people using them.
Merchants think in pricing tiers first, products second. A two-tier architecture (Plan Library + Product Toggle) matches their mental model.
“I watched a merchant spend 6 hours trying to set up monthly tea deliveries. The plugin had every feature she needed. It just spoke a completely different language than she did.
Sarah wanted to sell monthly tea deliveries. Her recording ran from 2:14 PM to 8:47 PM and ended with the tab closing before she launched a subscription.
In the support cohort reviewed for this project, 45% of merchants filed a ticket before finishing setup. I wanted to understand which decisions were making a simple offer so difficult to configure.
The Problem
Six hours, zero subscriptions launched. The tools had every feature Sarah needed and spoke a language she did not.
I watched Sarah's Hotjar recording on a Saturday afternoon. She was setting up monthly tea deliveries. She started at 2:14 PM. By 8:47 PM, she'd closed the tab.
Six hours. Zero subscriptions launched.
I recruited 11 more merchants who'd attempted and abandoned similar setups. Every session had the same shape: long stretches of confusion, followed by giving up.
“"I just want customers to get tea every month. Why do I need to understand billing synchronization?"
The problem wasn't that the tools lacked features. It was that the tools spoke a different language than the people using them.
Merchants think in customer outcomes: "deliver coffee monthly with 10% off." Plugins demand system fluency: "create a variable product with 30-day billing intervals, configure a subscription coupon with renewal conditions, and set a day-1 synchronization anchor."
That translation gap was where everyone got lost.
From 12 user interviews and 847 support ticket reviews, the failures clustered into three categories.
The three failure categories, in detail
Setup complexity: Average time to first working subscription: 4–6 hours. 47% of that time decoding terminology, 31% trial-and-error, 22% debugging why the subscription wasn't appearing.
Architectural inflexibility: Physical products with "Subscribe & Save" couldn't coexist with digital memberships without custom workarounds.
Customer self-service failures: When subscribers wanted to pause, skip, or swap products, existing portals were confusing enough that most just cancelled instead.
What We Were Building Against
Three competitors, identical setup tasks, 3h52m to 5h18m each. All optimised for technical completeness, none for a first-time merchant.
FunnelKit had 40,000+ WooCommerce merchants using its checkout tools. Our support data kept surfacing the same pattern: merchants trying and failing to add subscriptions. 32% searched for "subscription" in our docs within their first week. Most never got there.
The market leader, WooCommerce Subscriptions at $279/year, was technically capable but built for developers, not store owners. We had a distribution advantage (40K+ merchants), a trust advantage (they already used our checkout), and a clear gap to fill.
I installed every major competitor and ran identical setup tasks in each.
| Plugin | Setup time | Settings | The moment that told me everything |
|---|---|---|---|
| WooCommerce Subscriptions | 4h 37m | 212 | I searched for "monthly subscription." It doesn't exist. Only "billing period" and "synchronization interval." The vocabulary assumed I already knew how billing systems work. |
| YITH Subscriptions | 3h 52m | 187 | Better labels, but settings still organised by system component rather than merchant goal. |
| Subscriptio | 5h 18m | 160+ | The wizard asked me to configure the payment gateway before I'd defined what I was selling. |
Every competitor had optimised for technical completeness, not for the moment a first-time merchant tries to get something working.
Research: From Observation to Diagnosis
71% of setup failures clustered in the first 20 minutes, before pricing. Better copy and an in-app help sidebar both failed to move it.
Twelve interviews and 847 support tickets. Two rounds of affinity mapping revealed that 71% of setup failures clustered in the first 20 minutes, before anyone reached pricing or trial configuration. A foundational problem, not a feature problem.
I stress-tested two explanations with 5 merchants each: better copy (11% reduction in setup time) and an in-app help sidebar (14%). Neither was significant. Only the mental model reframe, restructuring the entire flow around how merchants think, produced the step-change the data indicated was possible.
| Response | Value |
|---|---|
| First 20 minutes, before pricing | 71% |
| Pricing and trial configuration | 29% |
The two surface-level fixes that missed significance
| Response | Value |
|---|---|
| Better copy | 11% |
| In-app help sidebar | 14% |
Three Attempts
A settings panel, a wizard, then better labels. The first two failed on ongoing use; the third proved the structure was wrong, not the words.
Attempt 1: The settings panel
Tabs organising different configuration areas. Five merchants tested it. Same reaction: "Where do I even start?"
I'd organised the complexity. I hadn't removed it.
Attempt 2: The setup wizard
A guided five-step flow: product type, frequency, pricing, trial, review. All 8 participants completed setup. Average time: 8 minutes.
⚠️ Closer. Everyone finished, but 8 minutes for one plan does not scale to a catalogue.
Then I asked them to change one setting.
The wizard forced them back through all five steps.
“"This is great the first time, but now it's in my way."
Wizards optimise for first use at the expense of ongoing use. Since merchants edit subscription plans constantly, this was the wrong trade-off.
Attempt 3: The settings panel with better labels
Before committing to a new architecture, I tested whether better labelling alone could fix the problem. I replaced every technical term with plain-language equivalents. "30-day billing interval" became "Monthly." "Synchronization anchor" became "Billing start date."
It helped. Setup time dropped to 2h 40m on average. Still nearly 40 times longer than our target.
The labels were better. The structure was still wrong.
The Architecture That Worked
Merchants were defining pricing tiers, not products. A Plan Library plus a one-toggle product application: 8 of 8 finished in under five minutes.
During one session, I noticed a merchant wasn't just setting up one subscription. She was defining options (monthly, quarterly, annual), then deciding which products each applied to. Two separate activities. The plugin treated them as one.
I validated with 6 more merchants: 5 of 6 described subscription options as a distinct business decision, "my pricing tiers", separate from the product catalogue.
✅ This was it. I built a prototype in 3 days and tested with 8 merchants. All completed setup in under 5 minutes. Asked to add subscriptions to a second product the next day, every one did it in under 30 seconds without prompting.
The PM pushed back: "Merchants with one product type won't need a library." I stress-tested it, and even single-product merchants created an average of 2.4 tiers. The library was always simpler. That challenge made the architecture stronger.
Six decisions underneath the architecture
Accessibility built in from the start: Before wireframing, I audited the three competitor plugins for keyboard accessibility. All three had failures: radio groups not announced by screen readers, modal dialogs not trapping focus. I used this as a checklist for Sublium, and tested with VoiceOver during the prototype phase, before engineering picked up the work.
Why radio buttons over dropdown for billing frequency: Dropdown users took 4–8 seconds to scan options. Radio users: 1–2 seconds. For a small, fixed option set, radio buttons are always faster, and navigable by arrow key without the two-step "open then select" interaction.
Why trial period is collapsed by default: 18% of WooCommerce subscriptions include trials. Showing trial options open confused the 82% who didn't want them. They'd spend time "turning off" a setting that was never on.
The customer portal, two approaches tested: I tested action-first (pause immediately, confirm after) vs. preview-first (show outcome before commitment). Action-first: 23% "I didn't mean to do that" rate. Preview-first: 2%. The extra step wasn't friction, it was confidence.
The live preview panel: Merchants were tabbing between settings and their live store to verify configuration. I added a real-time preview panel and configuration errors dropped 67%.
Navigating the engineering constraint: Our lead engineer flagged that global plan management would add 12 weeks. I designed the V1 interface to accommodate global plans while shipping product-level plans first, identical UI components, different data source. When global plans shipped, zero merchants needed to relearn anything.
What I'd Do Differently
Smart defaults averaged brands into blandness, I cut a field that became the third most-requested, and I only tested merchants who had already failed.
Read the post-launch lessons
What I underestimated: brand diversity
45% of merchants post-launch wanted to customise copy, colour, or positioning. My "smart defaults" philosophy produced something average that served neither fitness brands nor luxury brands well. I'd add a brand personality preset at setup.
The feature I cut that we needed
I pushed back on a "subscription notes" field for merchant-side notes on individual subscribers. It became the third most-requested feature post-launch. I'd filtered genuine operational needs through a simplicity lens that was too narrow.
What I'd test differently
I tested with merchants who'd failed setup. I didn't test with merchants who had working subscriptions with competitors. Migration friction was higher than expected: merchants with 500+ active subscribers wouldn't recreate plans manually, even for a better product.
What I'd keep
The two-tier architecture held under real-world pressure. One merchant changed pricing across 34 products, edited one plan, 30 seconds. V2 shipped a new data architecture: zero re-onboarding.
Results
4-minute average setup, 94% completed without a support ticket, 500+ installs and a 5.0 rating in the first months.
Evidence note: The portfolio record does not retain the cohort size behind setup time or ticket-free completion, so treat those figures as directional product results. Installs and the early rating come from the product's WordPress.org listing. The repeat-purchase figure below is merchant-reported rather than a controlled attribution claim.
Sublium launched as its own standalone product and crossed 500 active installations within its first months, holding a 5.0-star early rating on WordPress.org. Merchants reported roughly 20% more repeat purchases after switching on subscriptions.
