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.
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.