Every big bundle app is a conversion widget: great product page, then the order says "Bundle" and your 3PL has no idea what to pick. The one app that fixes it does so by editing orders after creation, and that races the 3PL's order import.
I'm building Solid Bundles on Shopify's Cart Transform API instead: components with real SKUs land in the order at checkout time, by construction. The cleanest frame I've found while building this: bundle setups are either analytics-clean (the bundle is its own product, tidy reporting, sync jobs forever) or ops-clean (the order carries real components, warehouses just work). Almost every app picks analytics. I picked ops.
Then the category made my argument for me. Two of the big bundle apps vanished from the App Store within two weeks of each other: one after a security incident that got it deactivated on thousands of stores overnight, the other with no explanation at all. Every migration thread asks the same two questions: what did the app leave behind in my orders and inventory, and how do I make sure the next one fails safe. Nobody asks about the product page widget.
This week a Shopify theme dev who has installed bundle apps across hundreds of client stores gave me his support-side ranking of what actually breaks after install: price display first (discount shows at cart, product page shows list price, merchants file "app is broken" tickets by day two), custom AJAX cart drawers second, discount stacking rules third, bundle-parent inventory confusion fourth. I spent a day checking my codebase against all four. Two were already safe by architecture (the parent product carries the real bundle price; stacking rules are explicit, not accidental), one was half-built and just got promoted to next ship (savings note on the product page), and one became my beta test matrix (Impulse, Prestige and Flex cart drawers).
Flat $29/mo, no revenue caps. The category's usage-based pricing is its most-hated feature: the current top 1-star review on the market leader calls it "a tax based on how much we sell."
Status update while drafting this: the approval email arrived this morning. Solid Bundles is now listed on the App Store, nine days after submission. About 20 build hours and $19 spent, $0 MRR, and the 60-day kill threshold starts ticking when I flip the listing to full visibility this week. This week I also shipped migration guides for stores hit by the delistings, and a feature that adopts an orphaned bundle product in place so a migrating merchant keeps their product URLs and SEO. Looking for beta merchants with 3PL or warehouse setups: free lifetime plan, personal onboarding, your feedback steers the roadmap. Comment or DM if that's your stack.
What stood out to me is that you chose the constraint before you chose the implementation.
Optimizing for the warehouse instead of the product page changes what the product is trying to be. The strongest positioning decisions often come from deciding whose workflow gets protected when trade-offs are unavoidable.
whose workflow gets protected" sums it up better than my whole post did. funny thing is how much that one choice decided for me. pricing followed from it (usage caps punish exactly these merchants in their best months, so flat), and the roadmap too. saying no to features got way easier once the question was just "does the order stay pickable
I appreciate you saying that.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
sure: [email protected]. what's on your mind?
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Thank you for a fascinating article
The delisting angle is the sharpest part of this for me. It's not just "what did the old app leave behind," it's the orders that were mid-checkout the moment it got pulled, some created with real component SKUs, some still carrying a bare "Bundle" line item from a half-finished cutover. Any merchant migrating between bundle apps needs a way to tell those two order shapes apart after the fact, or the warehouse ends up guessing again exactly where you started.
this is the failure mode nobody talks about, the half-finished cutover window creates two order shapes in the same day and the picklist looks identical for both. today the honest answer is manual: export orders from the cutover window and read the SKU column, anything carrying the bundle's own SKU instead of component SKUs needs hand-expanding before it reaches the warehouse queue. i'd like to build exactly what you describe (scan a date range, flag orders that won't pick) but my app currently runs with zero order data access on purpose, faster review and smaller surface, so that tool sits behind a permissions upgrade. filing it, this is genuinely useful.
that zero-order-access default is the right call, most bundle apps ask for way more scope than they use. But the reconciliation scan doesn't need full order access, just read-only SKU plus created_at for a date range. That's a much narrower ask than general order scope, might be worth an opt-in add-on rather than a full permissions upgrade.