One Backend, Many Storefronts
Multi-tenant to the core. Each brand is an organization with its own keys, catalog, customers and domain, and every one of them runs on the backend you are already paying for.
What A Second Brand Costs You
Six rows, and not one of them is a quantity. The first is the whole argument of this page in a single word.
- New infrastructure
- None
- New tenant
- One organization
- New credentials
- pk_ and sk_
- New domain
- Per storefront, pointed at your frontend
- New design
- Optional, reuse the one you have
- New isolation work
- None, it is already enforced
Add A Brand, Not A Data Centre
For agencies, multi-brand operators and distributors with regional sites.
If you run more than one store, the usual cost is a whole backend per store: separate databases, separate deploys, separate upgrades, and a bug you now have to fix in several places.
This collapses that. Standing up another brand means creating an organization and taking a fresh pair of keys. It has its own products, customers, orders and branding from the first request, and it is isolated from every other tenant without anyone configuring the isolation.
A Key Pair Is A Whole Store
Each organization has its own pk_ and sk_ keys. Point a frontend at a different key and it is a different store: different catalog, different customers, different orders, with no route by which one tenant reads another’s data.
That is the same boundary your customer data sits behind, not a second mechanism layered on for multi-brand accounts.
How the boundary is enforcedimport { DashClient } from "dash4devs"// Same SDK, same backend, isolated data.const brandA = new DashClient({ apiKey: process.env.BRAND_A_KEY })const brandB = new DashClient({ apiKey: process.env.BRAND_B_KEY })const a = await brandA.products.list() // only Brand A's catalogconst b = await brandB.products.list() // only Brand B's catalogThe Frontends Can Be Anything
One shared codebase parameterised by key, a separate design per brand, or a mix while you migrate. The backend serves whichever organization the key on the request belongs to, which is also why a white-label build and a bespoke one cost the same to operate.
Every New Store Is Cheaper Than The Last
The first store carries the setup cost. The next one inherits it. That is the economics of a real multi-tenant platform, and it suits a portfolio as naturally as a single shop.
One Shared Backend
Multi-tenant behind every storefront you run, upgraded once.
Keys Per Organization
Its own pk_ and sk_, catalog, customers and orders from the first request.
No Cross-Tenant Read Path
Isolation enforced underneath you rather than configured per endpoint.
A Brand Is A Record
Not new infrastructure, not a provisioning ticket, not a second deploy.
Its Own Domain
A custom domain and its own branding per storefront.
Reuse Or Redesign
One frontend across brands, or design each independently. The backend does not care.
Add The Next Brand.
Create an organization, take the keys, point a frontend at them. That is the whole setup.