Where this fits.
Compared by category rather than by naming competitors, because the honest answer depends on what you are optimising for.
vs a platform-native theme
A theme is faster to launch and cheaper to keep. You give up control of rendering, performance and release cadence, and the storefront cannot outlive the platform. Choose a theme when the storefront is not the differentiator.
vs a framework commerce starter
Most starters are scaffolds wired to one backend: real pages still need building, and the integration is spread through the components. Here the shopping path is finished and the backend is one swappable package.
vs a hosted storefront builder
A builder removes the engineering, and with it the ceiling. You are inside someone's component model and pricing. This is the opposite trade: you run it, you own it, MIT.
vs building it yourself
The genuinely hard parts are cart edge cases, checkout state and account flows — not the grid. Those already work here. What you would still write yourself is your own design.
Capability matrix
Every supported backend, what is wired, and how much setup it needs. Coverage counts services connected to a real endpoint out of the storefront service surface.
| Platform | Coverage | Cart | Checkout | Auth | Setup |
|---|---|---|---|---|---|
| Litekart | 39/43 | ✅ | ✅ | ✅ | built in |
| Vendure | 39/43 | ✅ | ✅ | ✅ | built in |
| Medusa | 31/43 | — | ✅ | — | built in |
| Broadleaf | 28/43 | ✅ | ✅ | ✅ | manual |
| Saleor | 28/43 | — | — | — | built in |
| Shopware | 28/43 | ✅ | ✅ | ✅ | manual |
| Virto Commerce | 28/43 | ✅ | ✅ | ✅ | manual |
| WooCommerce | 27/43 | ✅ | ✅ | ⛔ | manual |
| Magento | 26/43 | ✅ | ✅ | ✅ | manual |
| Spree | 26/43 | ✅ | ✅ | ✅ | manual |
| X-Cart | 26/43 | ✅ | ✅ | ✅ | manual |
| EverShop | 25/43 | ✅ | ✅ | ✅ | manual |
| Spryker | 25/43 | ✅ | ✅ | ✅ | manual |
| nopCommerce | 24/43 | ✅ | ✅ | ✅ | manual |
| PrestaShop | 24/43 | ✅ | ✅ | ⛔ | manual |
| Sylius | 24/43 | ✅ | ✅ | ✅ | manual |
| Swell | 23/43 | ✅ | ✅ | ✅ | manual |
| Bagisto | 22/43 | ✅ | ✅ | ✅ | manual |
| commercetools | 21/43 | ✅ | ✅ | ✅ | manual |
| OroCommerce | 21/43 | ✅ | ✅ | ✅ | manual |
| Sharetribe | 21/43 | — | ✅ | ✅ | manual |
| CS-Cart | 20/43 | ✅ | ✅ | ⛔ | manual |
| Shuup | 19/43 | ✅ | ✅ | ✅ | manual |
| Shopify | 16/27 | ✅ | ✅ | ✅ | manual |
| Django Oscar | 15/43 | ✅ | ✅ | ✅ | manual |
| OpenCart | 9/43 | ✅ | ✅ | ⛔ | manual |
✅ wired · ⛔ no real endpoint on the platform · — not yet wired · built in = env wiring ships with the repo
What this is not
Reasons to walk away, stated plainly.
- It is not a backend. There is no admin, no inventory system and no payment processing — those stay with your platform.
- Connectors are written from published API specs and type-check against them, but have not all been run against live production stores.
- Only four backends ship with env wiring. The other 22 need a short branch added in
init.ts. - It is a codebase, not a product. Nobody is on call for your deploy.
The per-platform gaps are published rather than glossed over. Read the capability matrix →
Start with your backend.
Clone it, point it at your API, and describe the store you want.