LocationsStock Per Site
Shops With A Counter
One catalog behind the till and the storefront, so stock cannot drift between what you sold in person and what the site still thinks it has.
Ecommerce Software. One Backend, Many Storefronts.
A full shop, a wholesale portal, or something nobody has built before. Inventory, orders, shipping, customers, payments and content sit behind one typed API with a dashboard on the same data, so whatever you are putting in front of it, the back of it is already running.
One Order, Five Systems, No Glue Code.
Five parts of one platform, not five products you wire together. Follow the order the console is holding from the line resolving to the event that leaves the building.
- 01
Catalog
The line resolves first: which variant, at which tier's price, held at which location, against one stock ledger.
- 02
Payments
One layer over cards, wallets and bank transfer, so a single processor refusing is not the end of the conversation.
- 03
Orders
A risky one stops here for a person to work. The rest go on to rates, labels and tracking, in the same screen.
- 04
Flows
The order's own state is the trigger. Receipts and dispatch notices run on your templates, with no second vendor.
- 05
Events
Signals and webhooks out to whatever you run next, and the same event recorded in analytics inside your backend.
Connect What You Already Run.
Stripe, Authorize.net, PayPal, FedEx, UPS, ShipStation, Klaviyo, PostHog, Google Analytics, Search Console, Business Profile, Ahrefs, ThoughtMetric and QuickBooks each connect from the dashboard with a key, rather than with an integration project. VoxCore is already in there. Everything else is reachable over REST, webhooks and the typed SDK.
Tell us which one you need
Stripe
Authorize.net
PayPalREST API
FedEx
UPS
ShipStation
KlaviyoWebhooks
PostHog
Google Analytics
Search Console
Business ProfileTyped SDK
Ahrefs
ThoughtMetric
QuickBooks
VoxCoreStripeUPSGoogle AnalyticsThoughtMetricPayPalKlaviyoBusiness ProfileVoxCoreFedExPostHogAhrefsAuthorize.netShipStationSearch ConsoleQuickBooksREST API
Webhooks
Typed SDK
One Product, Three Shapes.
The mode is a real value the console reshapes itself around. You are not handed an e-commerce dashboard and told to ignore two thirds of it.
The People It Runs For
One backend, four very different shops. Nothing here is a testimonial: it is what each kind of business actually runs.
OrderScheduled Pickup
Restaurants And Food Service
Menus that change, orders scheduled for a time rather than a queue, and pickup as its own lane instead of a shipping method with the address taken out.
VariantsSize And Colour
Apparel And Small Batch
Sizes and colourways as real variants with their own stock, price and images, not one product with a dropdown bolted onto it.
FulfilmentLabel Printed
Makers And Studios
Short runs, made to order, honest counts. When four are left the storefront says four, and the label prints from that same order record.
And Whatever It Is You Sell.
None of the four above run a different product. Same catalog, same orders, same console, turned to what the business is.
1 of 5
Everything Here Is In The Product Today.
Not a roadmap, and not an add-on marketplace you assemble yourself. One backend, one console, one bill.
Sell
- Catalog
- Variants, bundles, multi-location stock
- Orders
- Fulfil, track, refund, archive
- Shipping
- Rates, labels and tracking, per carrier
- Payments
- Cards, wallets, bank transfer, one layer
Grow
- Analytics
- First-party, captured into your backend
- Customers
- Segments, affiliates, reviews
- Campaigns, transactional, automated flows
- Content
- Blog, page groups, SEO, sitemaps
Operate
- Fraud Review
- Holds worked inside the order flow
- Webhooks
- Events out, as they happen
- Storefronts
- Many sites, one backend, custom domains
- White-Label
- Your branding on the console itself
Build
- Permissions
- Roles and departments, read, write, delete
- Automations
- Triggers and flows, without a second vendor
- Typed SDK
- One client, server or browser
- REST API
- Everything the dashboard does, you can do
The Business Behind The Storefront.
A backend earns its keep on the day an order has to be packed, a refund has to clear and somebody has to know what is left on the shelf. The console reads the same records the storefront does, so the person running the shop and the person building the site are never reconciling two systems.
- In The Product Today
- 16systemsCatalog through to permissions, all on one backend and one bill.
- Shapes Of Business
- 3modesRetail, wholesale and service, as one console that reshapes itself.
None of that needs a deploy. Products, prices, content, discounts, fulfilment and refunds are worked in the console by the people who run the business, on the same records the storefront is serving.
Both figures are counts of what this page already shows you: the systems listed in the section above, and the modes the switcher further up moves between. Neither is a survey, a projection or a customer number.
One Object, And The Backend Is On It
Drop in your key and products, cart, checkout, auth and content are all typed properties of one client. None of it is scaffolding you then have to maintain.
// Use it anywhere: server or browser.const products = await dash.products.list()const cart = await dash.cart.get()const order = await dash.checkout.complete({ … })const posts = await dash.blog.list()const reviews = await dash.products.getReviews("slug")// Same client, signed in as the shopper.const history = await dash.auth.getOrders()const book = await dash.auth.getAddresses()const rates = await dash.shipping.getRates({ … })// And the content the same backend is serving.const about = await dash.pages.getByPath("/about")const coas = await dash.coa.list()The storefront
Catalog, cart, checkout, posts, reviews
The shopper
Their orders, their address book, their rates
The content
Pages and documents the same backend serves
- Server Or Browser
- The same client renders on both. No second package.
- Typed End To End
- Declarations ship with it, so your editor knows an order.
- Any Framework
- Next.js, Remix, Astro, Vue, or none. It is a plain ES module.
- Attribution Built In
- Sessions and UTM sources land on the order record.
From An Empty Folder To A Live Store.
No sales call, no onboarding call, no implementation partner. This is the whole path, and these are the actual commands.
- 01
Create An Organization
Sign up, name the business, pick the mode. You get a public key for the browser and a secret key for your server.
pk_live_… / sk_live_…
- 02
Scaffold The Storefront
One command writes a Next.js App Router project wired to the SDK, and installs it.
npx dash4devs init my-storefront
- 03
Ship It
Builds the site, uploads only the assets that changed to the CDN, and activates the deploy atomically.
npx dash4devs build
npx dash4devs init my-storefrontNext.js App Router project writtenSDK installed and wired to your keysPublic and secret keys read from your organizationnpx dash4devs buildSite builtChanged assets uploaded to the CDNDeploy activatedTwo Things You Would Otherwise Build Yourself.
Each of these is a project of its own when the backend underneath does not have it. This one has them already.
- 01
Many Storefronts, One Backend
Every site is its own tenant, with its own keys, its own domain and its own content, all running on one backend you do not rebuild per site. Add the fifth storefront the same way you added the first.
How tenancy works - 02
Your Data Stays In Your Backend
First-party analytics captured into your own backend rather than rented from an ad network, with tenant isolation and field-level encryption underneath it. Nobody else is holding your customer list.
How the data is held
Take A Key And Start.
Sign up, take your keys, and scaffold a storefront against a real backend. Nothing on this page is behind a sales call.
Resources
Reading From the Team
One Backend. Build The Rest However You Like.
Sign up, take your keys, and point whatever you were going to build at a backend that is already running.
Start building