Online Store Planner
Research-backed ecommerce planner that turns 90-source feature counts into an agent-executable one-store spec with hard checkout and inventory gates.
The problem this kills
Most vibe-coded ecommerce projects collapse at the same places: checkout that does not create a durable order, inventory that is purely decorative, payment webhooks that never fire, and a mobile storefront that nobody tested before handover. The builder assumed their agent knew what a real online store looked like. It did not — because it was guessing from generic patterns, not from the actual surface area of 90 production ecommerce sources.
The result is a "store" with a cart that does not recheck stock at purchase, a checkout that accepts an empty cart, an admin with no order queue, and a product grid full of repeated placeholder images. These are not polish issues. They are the reason the agent's first delivery fails QA.
Why your agent cannot fake this
This planner was built by extracting feature frequency from 90 core sources spanning official platform docs, open-source ecommerce starters, live marketplace scripts, and demo admin audits. It counted how many of those sources showed each feature — not inferred it, counted it.
Product variants with real SKU, stock, and checkout-line snapshot behavior appear in 49 of 90 sources reviewed. Customer accounts appear in 48. Order management in 47. Checkout and order creation in 44. Payment gateway integration and storefront search/filter/sort each in 42.
Your agent cannot generate "found in 49/90 reviewed ecommerce sources" without redoing that scrape. The inventory anchors those facts into every planner decision rule, so the buyer's generated spec inherits the frequency data as hard gates, not as suggestions.
What you actually get
A structured multi-phase planner that walks your agent through eight decision blocks before writing a single line of spec:
- Delivery Mode — Production foundation, Internal dogfood, or Showcase demo. This controls whether demo auth and in-memory state are ever acceptable.
- Depth — Basic (7-9 build steps), Moderate, or Advanced. Basic means lean scope, not fake architecture.
- Store subtype — physical goods, one-product landing, small catalog, digital downloads, B2B, subscription, marketplace, or headless platform — with the last four cleanly separated as branch families or forbidden families.
- Payment and fulfillment — Manual/COD/bank-transfer is first-class. Integrated gateway is branch scope with webhook and idempotency gates.
- UI fingerprint — storefront image treatment, product-card rhythm, checkout compactness, admin command-center composition, typography scale, and data-viz tokens — not a generic dashboard with swapped labels.
- Optional branches — coupons, returns/RMA, reviews, subscriptions, digital downloads, multi-currency, marketplace, POS, ERP, native app — none enter Basic unless explicitly selected.
The planner then generates a hot CLAUDE.md or AGENTS.md under 35 KB plus ten split detail files under docs/plansmith/spec/. A spec custody gate prevents the agent from scaffolding before the spec is written and locked.
Coverage
Phase 0 — Delivery Mode. Forces an explicit choice between production-grade, dogfood, and showcase constraints.
Phase 1 — First Delivery Depth. Sets Basic, Moderate, or Advanced scope and flags the difference between "smaller scope" and "toy architecture."
Blocks 1-8 — Structured decisions. Store model, roles and must-love user, core store loop modules, payment and fulfillment mode, optional branches, UI direction and device target, stack and hosting, and build execution mode.
Non-negotiable rules. 24 hard gates baked into the planner: stock recheck at order creation, checkout must create a durable order or payment-handoff record, product media requires real bitmap assets and stable aspect ratios, admin UI must expose every selected module through navigation, mobile storefront requires desktop and phone-size screenshots, reports must derive from real order/product/inventory records, and exported files must be content-asserted against current-run records.
Forbidden-family scan. Before writing the spec, the planner scans for marketplace, store-builder SaaS, POS, ERP/accounting, enterprise headless, native app, subscription, digital download, B2B/wholesale, dropshipping, and advanced tax/shipping terms. Unselected families are allowed only in non-goals, risks, and roadmap.
Acceptance test families. Commerce-loop proof, stock recheck proof, export content assertion, screenshot semantic proof, visual-fingerprint proof, and product-media authenticity proof are all required before handover.