Orchard - Multi-Tenant Commerce Control Plane
One admin, many bespoke storefronts, full per-tenant isolation
Top outcome
Production-deployed control plane hosting live brands - 3,500+ merges shipped via an AI-directed dev model.
Stack
Next.js 16 App Router · React 19 · TypeScript 5.6 strict · pnpm 9 + Turborepo
Overview
Spin up a new store in a day
Provisioning wizard plus bring-your-own Stripe takes a brand from zero to deployed in hours, not weeks. Each new tenant inherits the full admin, all integrations, and four-layer data isolation by default.
86 integrations, one install flow
Sales channels, payments, fulfillment, marketing, analytics, AI agents, tax, content - all first-party. Tenants connect once via a four-step lifecycle (Connect / Permissions / Configure / Health) with a tenant-isolated encrypted credential vault.
Self-serve for store operators
Tenant admins run their own brand end-to-end - products, orders, inventory, subscriptions, marketing, returns, customer service - without touching the platform operator. A separate operator console handles cross-tenant fleet management.
Built for developers too
Typed @orchard/sdk client plus a documented public REST API at /api/v1/*. Three storefront delivery models support shared, per-tenant fork, or fully external frontends - tenants can run anything from a managed theme to their own bespoke Next.js app.
Enterprise-grade tenant isolation
Four-layer data isolation per table (app filter + Postgres GUC + RLS + custom Postgres roles), per-tenant encrypted credential vault, AES-256-GCM + HKDF key derivation, full audit log, RBAC across 7 roles × 52 permissions.
Dogfooded from day one
Built originally to run my own DTC brands - Human Nature and Besteas. Every feature ships because I need it for my own stores - then generalizes to other operators and developers.
Orchard is the multi-tenant commerce control plane I built to run my own portfolio of DTC brands - and then opened up to other operators and developers. One admin, one set of integrations, one operational stack; completely bespoke storefronts per brand.
Read the full story
Production-deployed today with three live tenants (Human Nature, Besteas, De Alma y Corazón) and a queue of brands behind them. Public platform documentation at docs.theorchard.dev; the operator console and tenant admin live behind auth at admin.theorchard.dev. The marketing site is at theorchard.dev.
Architected and built end-to-end - product strategy, multi-tenant data model, design system, full-stack implementation, CI/CD, security posture, and the autonomous-agent operating model. Claude Code agents (principal PM + dev-lead) operate against a 14-gate release checklist that opens, reviews, and merges PRs on a scheduled cadence; ~1500+ PRs merged on main with multi-deploy cadence (4 production deploys in the last build session alone). The architectural lessons from Human Nature informed Orchard - but Orchard is a rebuild, not an extraction. Multi-tenancy is an architectural posture, not a refactor.
The Problem
I was running multiple direct-to-consumer brands and building storefronts for others - each one needing its own admin panel, its own integrations to maintain, its own operational backlog. Zero leverage across them. Every platform upgrade had to be repeated per store; every new integration had to be wired separately each time. The math became obvious: pay forever to rent a generic admin per brand, or build a multi-tenant control plane once and own it.
The Solution
I built Orchard - a from-scratch multi-tenant commerce control plane - originally to run my own portfolio of stores with full control and one operational stack. The thesis: backend and admin should be shared across brands; the storefront should be completely bespoke per brand. Now also opens up to other operators and developers via a typed SDK and a public REST API. Single deployment serves many siloed stores, each fully isolated at the database, auth, domain, payment, and audit layers. Designed against seven distinct stakeholder perspectives (marketing, fulfilment, finances, customer service, operations, administration, customer) from day one.
Impact
- 1Production-deployed with multi-deploy cadence (4 prod deploys in the last build session alone). Three live tenants: Human Nature (TCM herbal supplements), Besteas (specialty tea), and De Alma y Corazón (hand-crafted gift + ritual brand)
- 2Marketplace with 86 first-party connectors across 11 categories (sales channels, marketing, payments, fulfillment, support, tax & compliance, back office, analytics, AI & agents, content, platform); OAuth chassis with a four-step connector lifecycle (Connect / Permissions / Configure / Health) and tenant-isolated encrypted credential vault
- 3Four-layer tenant data isolation per table: app-level filter, Postgres GUC (orchard.tenant_id), RLS policies, and dedicated custom Postgres roles. service_role is revoked on every public.* table; enforced by CI lints
- 4Operator console (cross-tenant fleet view) vs tenant admin (single-tenant view) as first-class separate roles, each with their own UI chrome, RBAC, audit trails, and notification surfaces
- 5Mobile-responsive admin shell with off-canvas drawer, command-palette quick actions, and pinned navigation; phone-tested at 375x812 with feature parity to desktop
- 6Autonomous shipping model: PM agent + dev-lead agent operate against a 14-gate release checklist; ~1500+ PRs merged on main; agents amplify cadence, owner sets strategy
Key Decisions
- Designed and built end-to-end - product strategy, multi-tenant architecture, design system, full-stack implementation, CI/CD, security posture, and the autonomous-agent operating model. Claude Code agents as force multipliers across a 14-gate release checklist; ~1500+ PRs merged on main
- Designed around seven stakeholder perspectives (marketing, fulfilment, finances, customer service, operations, administration, customer) from day one - not personas added later, but the abstraction the admin is organized around
- Reframed the project as a from-scratch rebuild rather than a Human Nature extraction - multi-tenancy is an architectural posture, not a refactor
- Four-layer tenant isolation enforced by CI lints: app-level filter, Postgres GUC, RLS policies, and dedicated Postgres roles. No service-role bypass for convenience
- Auth split by identity type: operators (TOTP required), tenant admins (TOTP optional), customers (passwordless magic-link)
- Three storefront delivery models in v1 (shared runner / per-tenant fork / external API consumer) so the platform fits both managed and headless tenants
- Integrations are per-tenant by default - every external service (Stripe, Mailchimp, Resend, EasyPost, Sanity, TikTok Shop, etc.) is a per-tenant credential. No global singleton clients
- Business logic lives in storefront-runner, not API routes - API routes are thin HTTP wrappers. Admin surface and public surface share the same business code
Lessons Learned
Multi-tenancy is not a feature you add later - every primary key, every query, every cookie, every webhook URL changes shape
Seven stakeholder perspectives is the right abstraction for a commerce admin platform - designing only for the developer perspective is how Shopify burns out at five stores
Append-only architectural decision logs are the single most important guardrail against silent reversals across long-running sessions and autonomous agents
Autonomous agents amplify both throughput and damage potential - the gate checklist, the protected-paths list, and the PAUSED kill-switch are the load-bearing parts of the operating model
A "rebuild informed by prior art" framing produces cleaner architecture than a "port" - re-deriving the shape forces honest tradeoffs
Screens
1 / 7