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