From one person to a marketplace

The most useful thing to understand about building here is that scale is additive rather than a rewrite. This page follows one commerce app through four stages, because commerce exercises nearly every part of the platform: catalogue, money, inventory contention, multi-party access, operations, and audit.

Stage 1 — A solo storefront

One person, no engineering team, a couple of days. Describe the shop; review what gets built.

What matters at this stage is what you didn't do: no server to size, no database to provision, no CI to configure, no CDN to put in front. The catalogue pages are edge-cached from the first deploy, so the shop is fast before anyone thinks about performance.

The thing to get right early is the data model — products, variants, orders, customers. Everything later is easier if those tables are sane, and a migration to fix them later is real work.

Stage 2 — A real shop

Orders are arriving and one person can't watch everything.

Added:

• A backoffice — order list, fulfilment status, stock levels, refunds. Just more routes in the same app.
• Inventory with proper decrementing on checkout, which is the first place concurrency matters: two customers buying the last unit must not both succeed. A version check on the row is the cheap correct fix.
• A support agent on the storefront, answering from real order data through browser chat — it reads orders through your code, so it can't invent a delivery date.
• A staging environment, because now a mistake costs money. One command; separate database, same codebase — see Environments.
• Discounts and promotions, with the margin floor enforced in code so nothing can discount below it regardless of who or what asks.

That last point is worth pausing on. The rule lives in a domain function, so it binds the backoffice form, the agent, and any future integration identically. Putting it in an agent's instructions instead would mean it holds until someone phrases a request persuasively.

Stage 3 — A multi-vendor marketplace

Third parties now sell through you. This is the stage where the shape genuinely changes, because money moves between parties and several actors touch the same rows.

Added:

• Vendor onboarding and a vendor portal — self-service signup, catalogue upload, order visibility scoped to their own products.
• Commission and payouts — the calculation, the run, the statement. Money, so it goes behind transactional operations with the invariant enforced in one place.
• Contended inventory — a vendor's stock is decremented by customer orders, vendor edits, and returns simultaneously. This is where a Durable Object per SKU earns its complexity: one writer at a time, so double-selling is impossible by construction.
• Order processing at volume — a queue rather than doing the work inline, so a burst doesn't fail checkouts and a downstream outage doesn't lose orders.
• Moderation — listings reviewed before they go live, which is the first genuinely agent-shaped job: an agent audits every submission and escalates the ambiguous ones.
• Roles — staff, vendors, and admins seeing different things. Your application's authorization, which is yours to implement because only you know your rules.

The architecture pattern that carries this stage: the Durable Object makes the contended decision, the database records it, the cache and KV serve the read traffic. Contention is handled exactly once, in the one place that can handle it correctly — see Choosing a data store.

Stage 4 — Enterprise grade

Now the marketplace is the business. Someone asks for your SLA, your auditors ask who approved a payout, and the operational load has outgrown the team.

Added:

And the operational picture changes shape: instead of a team draining queues, a set of agents handles the routine flow and escalates exceptions. Order triage, restock proposals, promotion drafting, dispute evidence, catalogue QA, vendor review, and a morning digest of what needed attention — each with an audit trail, each with the consequential writes gated on a human. That's Backoffice run by agents.

What carried through all four stages

Worth listing, because it's the argument for starting small without painting yourself into a corner:

• The codebase. Extended and refactored, never restarted.
• The domain and URL. No cutover, no migration announcement.
• The full history. Every change since the first deploy, attributed and revertible.
• The infrastructure. Same edge deployment, same database engine, same storage. Stage 4 added a dedicated account and Postgres for one table; it didn't replace the stack.
• The deployment path. sf deploy at stage one; sf deploy at stage four, with branch-based promotion and a one-minute rollback.

Other shapes this applies to

Commerce is the illustration, not the limit. The same progression fits:

• A customer portal — account view → self-service actions → partner access → audited entitlements
• An internal operations tool — one team's workflow → several teams → cross-department with roles → governed with approvals
• A booking or scheduling system — calendar → staff and resources → multi-location → enterprise with SLA and audit
• A data or reporting portal — dashboards → alerts → self-service exploration → governed access with residency requirements

The common thread is that each starts as something one person can build in days, and none of them need to be rebuilt to become the enterprise version.

Next

• Backoffice run by agents — the operational half in detail.
• How software is changing — why this progression is newly possible.
• Getting started — build stage one.