Ends in a real contract
The selection becomes a subscription through the API, not an approximation assembled at checkout.
BUNDLE BUILDERS THAT ACTUALLY SUBSCRIBE
Subscription logic and bundle builders that hand off cleanly to Recharge. For Tayst Coffee we built a guided builder that captures coffee type, number of drinkers, roast and cup count, then passes the finished bundle straight into a Recharge subscription.
IN SHORT
Build-your-own subscription flows look like a front-end problem. A few questions, a nice preview, an add-to-cart. Most of them are built that way, and most of them break at the same place.
The difficulty is the handoff. The customer has assembled something specific — this roast, that many cups, this frequency — and it has to become a valid subscription contract that renews correctly, can be swapped, survives a price change and does not fall apart when one component goes out of stock.
When the builder and the subscription platform are treated as separate projects, that translation gets approximated at checkout. The customer receives something adjacent to what they chose, and you find out through support tickets in month two.
Six stages. Stage four is the one that separates a working builder from a demo.
What is actually being sold: fixed bundles, build-your-own, tiered frequency, or a mix. This decides the data model, and getting it wrong is expensive to unwind once customers hold contracts.
Each question earns its place by changing what the customer receives. A builder that asks five things people cannot answer will lose more customers than the personalisation gains.
State carried cleanly from first question to cart, with the selection visible and editable at every step, and a URL that can be shared or resumed.
The finished bundle becomes a subscription contract through the API rather than being approximated at checkout — the stage where most builders quietly break.
Swap, skip, pause, change frequency and cancel, designed as part of the build. Retention is decided here far more than in an email campaign.
Out-of-stock components, price changes on an active contract, failed payments and partial fulfilment — the states that appear at month four and are never in the demo.
Tayst Coffee sells coffee subscriptions. The builder asks what kind of coffee you drink, how many drinkers there are in the household, which roast you prefer — light, medium, dark — and how many cups you get through, up to a hundred. It then lets the customer choose their cups.
The finished bundle is passed straight into Recharge as a subscription. Not reconstructed at checkout, not approximated with a note on the order — handed over as the contract the customer actually built.
| Recharge | Shopify Subscriptions | |
|---|---|---|
| Bundle logic | Strong | Basic |
| Swap and skip | Mature, customer-facing | Simpler |
| Retention tooling | Built in | Bring your own |
| Moving parts | Another platform to own | Stays inside Shopify |
| Cost | Platform fee plus transaction share | Lower |
| Best for | Build-your-own, complex cadence, retention focus | One product, one cadence, simplicity |
None of these appear in a demo. All of them appear in production. We design for them during the build rather than discovering them through churn.
The selection becomes a subscription through the API, not an approximation assembled at checkout.
Each step changes what arrives in the box. Anything else is a default, because questions cost completion.
Swap, skip and pause are self-serve. The cheapest retention work is letting people adjust instead of cancel.
Out of stock, price change, failed payment — designed for during the build, not discovered later.
A guided bundle builder for a coffee subscription: the customer answers what they drink, how many drinkers there are, which roast they want and how many cups, picks their cups, and the built bundle is handed straight to Recharge.
Clients from the roster whose work this page describes. Each links to what we actually built.
GANT came to Shopify with internal systems already in place. We migrated the store and connected those systems, including integrations with individual local stores.
A guided bundle builder for a coffee subscription: the customer answers what they drink, how many drinkers there are, which roast they want and how many cups, picks their cups, and the built bundle is handed straight to Recharge.
A cake marketplace connecting customers to vendors across Malaysia. We built the back end that decides what can actually be delivered: each vendor has a daily capacity and each cake a lead time, and together they determine which dates and time slots a customer is offered at checkout.
Trunki moved from Magento to Shopify Plus, with a configurator for the custom, one-off ride-on designs the brand is known for. We have managed the store since.
Moonglow sells jewellery set to the moon phase of a date that matters to you. We built Find Your Moon: the customer enters a date of birth or other significant date, the store renders that moon phase, and it drives the personalised product.
Yes. The bundle is assembled in the storefront and passed to the subscription platform as a single contract, which is how the Tayst coffee builder works.
Recharge when you need bundle logic, swaps and mature retention tooling; native Shopify Subscriptions when the offer is simple and you want fewer moving parts.
Recharge when you need bundle logic, swaps, complex frequency rules or mature retention tooling. Native Shopify Subscriptions when the offer is simple — one product, one cadence — and you would rather have fewer moving parts. The decision is about the offer, not the technology.
Because the builder and the subscription platform were treated as separate projects. The quiz works, the cart works, and then the selection cannot be expressed as a valid subscription contract — so it gets approximated at checkout and the customer receives something they did not choose.
As few as change the outcome. Each question costs completion, so anything that does not alter what arrives in the box should be a default, not a step.
Shopify connected to the systems a business already runs on, down to integrations with individual local stores.
When the logic does not fit an app: vendor capacity, delivery scheduling, made-to-order queues.
Build-your-own product flows, from Trunki custom designs to date-driven personalisation at Moonglow.
Build-your-own flows for non-subscription products are product configurators. Moving from WooCommerce with existing subscriptions? That has its own considerations.
NEXT STEP
Vendor capacity engines, bundle builders and configurators are the work we are asked for most. Tell us the rule set.