Breadth is easy to claim. This is the ledger.
Shopify is live. Magento 2 and Magento 1 are built and sitting behind switches that are off. WooCommerce and BigCommerce are not built. Here is what each of those words means, and the engineering underneath that makes the next one cheaper than the last.
Where we
actually are.
Of the 5 platforms below, 1 is live. The rest are listed with the state they are genuinely in, which for two of them is built and deliberately switched off.
Platform ledger
Scope · status
- ShopifyLive
Catalog · orders · in-widget cart
The only platform a merchant can connect today, and the one every live store runs on. Shopify pushes webhooks, so the adapter declares realtime freshness and the catalog moves when the store moves.
- Magento 2 · Open SourceBuilt · switched off
Catalog · orders · in-widget cart
Verified on 17 June 2026 against a live Magento 2.4.8 instance with the Luma sample catalog: the signed authentication round trip, every data shape the adapter reads, and a real storefront add-to-cart. Three separate switches gate connecting a store, syncing it, and adding to its cart. All three default to off, and off means the Magento code is never loaded at all.
- Magento 1 · OpenMageBuilt · switched off
Catalog only
Catalog only, deliberately: orders and attribution are deferred rather than half-built. It has not been run against a live store yet, and the questions a live run would settle are still marked in the code where they sit, rather than assumed away.
- WooCommerceNext
Not built
Named as the next platform in the adapter contract itself. No code has been written for it.
- BigCommerceNot built
Not built
After WooCommerce. No code has been written for it.
Flag states read from the product’s own configuration on 10 August 2026
Adding a platform is not a rewrite, because of four decisions.
Most assistants are written against one platform and then bent toward the next. These four things are what let a Magento store and a Shopify store share the same recommendation engine without either one quietly poisoning the other.
One adapter contract
Every platform implements the same interface, and that interface is not allowed to speak Shopify. No method may hand back a Shopify global id, a Shopify store host, or a Shopify access token. A platform that cannot do something declares it, in a capability field the product reads, instead of the core quietly assuming it can.
An id space that cannot cross
A Shopify product id is a long global id string. A Magento product id is a bare number. One file in the server knows the difference, and it is the only place that prefix is written into code that answers a request. It appears once more in a one-time database backfill that rewrote old rows into the new shape, and everywhere else only in comments pointing back at that one file. One test pins its output character for character, and a second reads the source to keep the prefix confined there. Without this seam, a Shopify-shaped id matches nothing on a Magento catalog and the failure looks like an empty report rather than an error.
A boundary the core cannot cross
The recommendation engine, the customer records, and the security layer read normalized database tables and never import a platform adapter. Adapters never import each other either: Magento 1 signs its requests with HMAC-SHA1 and Magento 2 with SHA256, so code shared between them would be a defect rather than a saving. Both rules are written down as machine-checkable configuration, not as folklore.
The honest limit: we run that check by hand before touching adapter code. It is not part of our continuous-integration pipeline and it does not run on every push. It is a discipline we hold ourselves to, not a gate that would stop us.
Paired fixtures on shared queries
When we change a query that more than one platform reads, the change ships with a test fixture for every platform in the tree, in the same commit. The bug this exists to catch is a specific one: a database join written against Shopify-shaped ids that returns nothing for a platform using plain numeric ids, so a merchant sees a confident zero instead of a failure. We keep finding that shape in our own audits. That is exactly why the fixtures are the rule and not the aspiration.
Each platform declares its own freshness.
Magento Open Source has no native outbound webhook, so there is nothing for us to subscribe to. Rather than describe every platform as realtime and hope, each adapter declares what it can actually do, and the dashboard tells a merchant where their own platform falls short rather than quietly showing them an empty number.
- ShopifyrealtimeWebhooks, pushed by the store
- Magento 2poll:900A fifteen-minute poll
- Magento 1poll:900A fifteen-minute poll
Values as each adapter declares them
What the code does when it does not recognise a store.
An unknown platform
The dispatcher stops with an error instead of falling back to Shopify. A silent fallback would run one merchant’s store through another platform’s code, which is the kind of bug you find months later in someone else’s data.
An unrecognised storefront
Product cards show View Product instead of Add to cart. The widget will not fire an add it has no way to complete, because a button that looks like it worked and did not is worse than a link.
If it is not marked Live, you cannot buy it today. We list it so you can see where we are going and hold us to it later.
Running WooCommerce or BigCommerce? Tell us which one. Merchant demand is what decides the order we build them in, and we would rather hear it from you than guess.
Ready to put a real associate on your storefront?
Book a 30-minute demo with the founder over Google Meet and watch Sarah work your own catalog. We onboard you personally, usually live within 24 hours. Not ready for a call? Request an invite.
Private rollout · one-click uninstall if it doesn’t earn its keep