One core, many brands
Each merchant is an isolated tenant with its own theme, its own domain, and its own data, provisioned from a template rather than rebuilt and redeployed per store.
A storefront is only as good as what it is connected to: the catalog, the stock, the pricing, the payments and the measurement that make it a shop rather than a page someone has to keep updating.
This is a platform for shipping storefronts, not a site builder. The interesting connections are the ones that make the hundredth store cost the same to launch as the first.
Each merchant is an isolated tenant with its own theme, its own domain, and its own data, provisioned from a template rather than rebuilt and redeployed per store.
Cart, checkout, accounts, and order tracking are part of the platform, so a storefront is transacting on day one rather than after a plugin project.
Reads the same grossDule catalog, pricing, and stock over a clean API. Not a nightly export into a second product database that drifts by Friday.
Traffic, conversion, and revenue measured per storefront, so an operator running twelve of them can compare their own sites rather than guess which theme is working.
One engine behind the till and every storefront, so a member price or a bundle behaves identically wherever the basket is built.
Web, counter, and account orders converge into one order record with one status, which is what lets a merchant fulfil from the shop floor instead of a separate console.
Card and UPI settle into the same books as the counter and the storeDule app. Choosing a different processor does not cost you a percentage penalty here.
A customer earning at the counter and spending on the website is one customer with one balance, not two accounts that a report has to join.
Map any domain or subdomain per storefront, provisioned as part of creating the store rather than a support ticket afterwards. Each store is its own site, not a sub-path on somebody else's.
Crawlers and link previews see real HTML rather than an empty shell waiting for JavaScript, which is the difference between being indexed and being invisible.
Canonical URLs, sitemaps, robots rules, and product structured data are part of the platform rather than a plugin each merchant has to buy and configure.
Every storefront gets its own link preview and favicon, generated on publish, so a shared link looks like the merchant rather than like the platform.
Colour, type, and layout per store from a shared design system, so a theme is configuration that stays upgrade-safe rather than a fork that freezes a merchant on an old version.
Catalog, cart, orders, customers, and store provisioning are all reachable over a documented HTTP API, which is what makes an agency workflow possible at all.
Order placed, stock changed, store provisioned. Subscribe to the event rather than polling an endpoint on a timer and hoping the interval is short enough.
The app-style shopper surface and the operations core, on the same catalog. Run one, two, or all three without maintaining a second product list.
On the roadmap: company accounts, custom price lists, payment terms, and quotes. Named as a gap because a merchant selling to businesses needs all of it, not part of it.
On the roadmap: abandoned basket recovery and reviews. Both are expected on a hosted platform and neither is shipped here yet.
Content, catalog, customers, and orders export in open formats. A storefront platform that holds a merchant hostage is not a platform, it is a trap with a theme.
Tell us how many storefronts you expect to run and what your stack looks like, and we will shape the partner terms and the theming engine around it.
Free during early access. One catalog with grossDule and storeDule. Your data stays yours.
The full picture, one page at a time.
Your own branded storefront, on the same catalog as grossDule. Your first storefront is included.