Built to be changed
Why adding a store, or a feature, does not mean rebuilding anything.
Every store on this platform runs the same software. A setting decides whether a store takes cards, requires a sign-in, holds orders for approval, shows stock, or asks an extra question at checkout.
So a second store costs a configuration, not a project. And a feature we build for one customer is available to every customer the day it ships, whether or not they asked for it.
What that means for a rollout
| You want | What it takes |
|---|---|
| Another store for a different division | Configuration. Its own address, catalogue and rules. |
| A different look | Configuration. Colours, logo, fonts and page layout. |
| An extra question at checkout | Configuration. Including whether it is asked once per person. |
| Approvals, or different approvals | Yours to change, on your own screens, whenever you like. |
| Something the platform does not do | A conversation. It then exists for everybody. |
Your data stays yours, and stays legible
An order records what was true when it was placed. If somebody moves department, last year's orders keep the department they were placed under — so a figure you read in January still reads the same in June. Reports that quietly restate history are how people stop trusting them.
Answers to your store's own questions are stored with their labels attached, so they stay readable even if the question is later renamed or retired.