Commerce platform
Building a store is one problem. Building the thing that lets a thousand people build their own stores is a different one, and most of its difficulty is in what you let them change.
The defining decision is the boundary of customisation. Give merchants too little and they leave for a platform that lets them look like themselves; give them too much and every one of them ends up on a bespoke configuration you cannot upgrade, support or reason about. The platforms that survive draw a hard line: presentation is theirs, and the commerce model — orders, stock, tax, payments — is yours. That line is what makes it possible to ship a change to every store on a Tuesday.
Themes are a language you are designing, not a folder of files. Whatever templating you choose becomes a contract you cannot break without breaking every store built on it, and merchants will use it in ways you did not anticipate within a month. It also has to be safe: theme code runs on your infrastructure, so it needs a sandbox, a resource budget and no path to another tenant's data. Deciding this casually is how platforms acquire a security incident and a migration they can never schedule.
Point of sale is where a commerce platform stops being a website. A till has to keep selling when the internet drops, reconcile when it returns, drive card terminals and printers, and produce a cash-up a manager can sign. It shares a catalogue and a stock figure with the online store, which is exactly where the hard part lives: one number, two places to sell from, and no acceptable answer to selling the same last item twice.
How we work
- A hard boundary between what merchants may change and what the platform owns, drawn before the first theme exists.
- Theme code is sandboxed with a resource budget and no route to another tenant's data. It is untrusted code running on your servers.
- Stock is one authoritative number reserved across every channel, so the till and the website cannot sell the same last item.
A storefront a merchant would build on the platform.
What this includes
Pick what you need and send it over.
Questions
- Should merchants get their own domain and code access?
- Custom domains, yes — that is table stakes and mostly a certificate-automation problem. Code access is the harder call: it wins you the merchants who have a developer, and it commits you to supporting whatever they write forever. If you offer it, offer it as an explicitly versioned API rather than as access to your internals.