# Storely

> An operator-owned, multi-tenant ecommerce platform for running independent merchant stores from one centrally maintained engine.

Source page: https://saascode.ai/products/storely
Machine-readable record: https://saascode.ai/products/storely.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $299 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

Storely is an operator-owned, multi-tenant ecommerce platform. You run one instance. Each merchant gets an isolated store organization, manages it from a back office, publishes a governed storefront template, and serves that storefront on their own domain. It replaces running one separate site install per client with one engine you maintain centrally.

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/storely — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://storely.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

3 roles seeded on the demo (of the 5 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Store staff** (`staff`) — `staff@demo.com` / `see the page`
  Works catalog, inventory, and orders with scoped access. Lands on `/merchant/dashboard`.
- **Store owner** (`org_admin`) — `org-admin@demo.com` / `see the page`
  Runs the full back office from catalog through publishing. Lands on `/merchant/dashboard`.
- **Platform operator** (`super_admin`) — `admin@demo.com` / `see the page`
  Governs every store, plan, flag, and commerce surface. Lands on `/admin`.

Or open a role directly: https://saascode.ai/demo/storely?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 5** — distinct roles accepted by the role CHECK constraint: admin, member, org_admin, staff, super_admin
- **tables: 97** — distinct CREATE TABLE statements across every applied migration
- **migrations: 130** — .sql files in supabase/migrations
- **page modules: 122** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 197,713** — lines of code (comments and blank lines excluded) across 1161 TypeScript files (173,527) and 152 SQL files (24,186); node_modules and .next excluded
- **api route files: 256** — files named route.ts under src/app/api
- **http operations: 350** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 97 tables, 171 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0 · built 2026-08-15

## Complete capability inventory

14 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### Commerce

- **Catalog, variants, collections and media (Manage products, variants, collections and media, with CSV/JSON portability for products, variants and customers)** *(seller-authored)* — Manage products, variants, collections and media, with CSV/JSON portability for products, variants and customers
- **Inventory ledger and short-TTL reservations** — Stock lives in an append-only ledger with short-lived reservations. Adding to a cart reserves; paying commits; abandoning releases. Each ledger entry carries an idempotency key so a replay converges rather than double-counting.
- **Cart, discount, checkout and order engine** — 1. Quote — revalidate price, stock, discounts, shipping and tax against live data, and snapshot the result. 2. Finalize — take payment against that quote, write the order with its item snapshots, commit inventory, convert the cart, record redemptions, update usage counters and emit events.
- **Payments and refunds through enabled matrix cell (Stripe Connect payments and refunds using direct charges on connected accounts)** *(seller-authored)* — Stripe Connect payments and refunds using direct charges on connected accounts
- **Shipping zones, table rates and one pickup address** — Shipping supports zones, table rates by weight and price, a free-shipping threshold, and one local pickup address per store.
- **Deterministic tax rules and outage policy (Deterministic tax calculation with snapshots on checkout quotes and configured outage fallbacks)** *(seller-authored)* — Deterministic tax calculation with snapshots on checkout quotes and configured outage fallbacks
- **Customer account, addresses and store-scoped order history** *(seller-authored)* — Lets shoppers keep an account with saved addresses and view order history for the store where they bought.
- **Merchant orders, fulfillment, refund and credit note operations** — Orders move through a state graph and support partial fulfillment, refunds, credit notes and messages to the customer. Item details are snapshotted onto the order, so a later catalog edit never rewrites history.
- **Abandoned-cart eligibility and recovery (Consent- and suppression-aware abandoned-cart email sequences)** *(seller-authored)* — Consent- and suppression-aware abandoned-cart email sequences

### Storefronts

- **Governed storefront template, slots, preview, publish and rollback** — A merchant's storefront is a governed template filled with their own data, published as an immutable version and served on a hostname.
- **One custom merchant hostname (Custom merchant hostname provisioning with ownership verification)** *(seller-authored)* — Custom merchant hostname provisioning with ownership verification

### Operations

- **Scheduled operations and report templates** *(seller-authored)* — Runs recurring commerce operations and gives teams reusable report templates for routine work.
- **Connect API workflow verbs** *(seller-authored)* — Exposes opt-in workflow actions through organization-bound API keys.

### Roles & access

- **Staff invitations and merchant roles** — A shopper is not in this table. A shopper is a store customer record scoped to the store where they bought, authorized by participation rather than by membership.

## What each system gives the operator

*stated.*

- **Commerce** — Keep every sale coherent from catalog work through fulfillment and recovery.
- **Storefronts** — Let merchants publish storefront changes without turning every release into a gamble.
- **Operations** — Automate recurring commerce work and keep operational data portable.
- **Roles & access** — Give each team the right workspace without crossing store boundaries.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### Every merchant can sell without another installation to maintain.

Running one site per client makes every improvement a fleet problem. A routine change becomes a sequence of upgrades, plugins drift apart, storefront behavior diverges, and the operator spends more time reconciling installations than helping merchants sell. The damage compounds as the customer base grows: one fix reaches some stores but not others, support must first discover which version a merchant has, and every new account adds another environment to watch. A commerce business needs each merchant to feel independent without turning the platform behind them into a collection of unrelated projects.

### Storefront changes reach shoppers without turning publication into guesswork.

A storefront is the merchant's public promise, so a change that cannot be trusted is more expensive than a slow edit. Teams hesitate to update campaigns, switch presentations, or correct content when they cannot tell what will go live, whether the last version can be recovered, or which hostname shoppers will actually reach. That uncertainty creates stale stores and late-night launch checks, then turns every correction into an incident. The operating goal is simple: merchants should be able to change the storefront confidently while the platform owner avoids a support queue filled with preventable publishing surprises.

### The selling loop stays legible after the customer completes checkout.

The moment after checkout is where fragmented commerce systems start charging interest. Stock, payment, fulfillment, customer history, adjustments, and recovery often tell different stories, leaving staff to reconstruct what happened before they can answer a simple question. Every handoff increases the chance of duplicate work, an incorrect promise, or a customer waiting while two dashboards disagree. As volume grows, the cost is not just slower support; it is the loss of confidence that the order record reflects the business. Store teams need one operating story they can follow from demand through resolution.

### Owners and staff work each store without inheriting the whole platform.

Multi-store operations fail quietly when access is broader than the job. A store employee sees controls they should never need, an owner cannot tell where merchant authority ends, and the platform team becomes the only group trusted to make ordinary changes. That produces support dependency on one side and avoidable risk on the other. The problem grows with every merchant because permissions that were understandable in the first store become impossible to reason about across dozens. Each seat needs a clear scope so daily commerce work can move without turning every task into a platform-level decision.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node host** (required) — Next 16.2.10 and React 19.2.3.
- **Supabase** (required) — Supabase is present in the product tree.
- **Scheduled runner** (required) — Four jobs are declared in `vercel.json`; on another host they must be wired manually.
- **Email delivery** (optional) — Brevo, Mailgun, Resend, SendGrid and SMTP providers ship.
- **Optional environment services** (optional) — UPSTASH, NEXT and SENTRY families appear in the shipped example configuration.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 197,713 lines across the application and its database, 97 tables defined by 130 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Storely demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 3 of them: Store staff, Store owner, Platform operator. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 122 page modules and 350 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node host, Supabase, Scheduled runner. Optional: Email delivery, Optional environment services. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 130 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $299?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Multi-tenant ecommerce platforms in 2026, organized by what you maintain](https://saascode.ai/inside/multi-tenant-ecommerce-platforms-2026-maintenance-unit.md)
- [Storely: a multi-tenant ecommerce platform for independent merchant stores](https://saascode.ai/inside/storely-multi-tenant-ecommerce-platform-independent-merchants.md)
- [Storely vs Shopify: operate the platform or subscribe to a store](https://saascode.ai/inside/storely-vs-shopify-platform-operator-or-merchant-service.md)

## Links

- Catalog page: https://saascode.ai/products/storely
- Product record: https://saascode.ai/inside/products/storely
- Live demo: https://storely.saascode.ai
- Every product: https://saascode.ai/llms.txt