Online Store Planner

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, variants that are labels rather than real choices, and a mobile storefront nobody tested before handover. The builder assumed their agent knew what a real online store looked like. It did not.

There is a deeper failure underneath those. "Online store" is not one product. A single-product offer page, a multi-product catalog, a digital download store, a productized-service store, a multi-vendor marketplace, and a store-builder platform are six different businesses with six different checkouts, fulfillment models and admin queues. Ask an agent for "an online store" and it silently averages all six into a generic product-CRUD app with a cart bolted on. That is why the result feels wrong even when the feature list looks complete.

Why your agent cannot fake this

This planner stands on two separate research passes, and they do different jobs.

The first extracted feature frequency from 90 core sources — official platform docs, open-source ecommerce starters, live marketplace scripts and demo admin audits — counting how many showed each feature rather than inferring it. Product variants with real SKU, stock and checkout-line snapshot behavior appear in 49 of those 90. Customer accounts in 48. Order management in 47. Checkout and order creation in 44. Payment gateway integration and storefront search/filter/sort in 42 each.

The second, run in July 2026, rebuilt the model from scratch across 72 named sources and corrected the shape of the thing. Its finding: the primary object is not a product record, it is a path — customer-visible product, option or variant choice, cart line, checkout, order, admin fulfillment, customer handoff. If that path is not visible early, the build feels wrong no matter how many admin screens exist. It also established that marketplace and store-builder are expert branches, not checkboxes inside a normal store.

Your agent cannot generate "found in 49 of 90 reviewed sources" without redoing the scrape, and it cannot infer the six-shape split from a prompt. Both passes are compiled into the decision rules, so the generated spec inherits them as gates rather than suggestions.

What you actually get

The planner locks your store shape first, then sizes the build to it. Discovery is depth-gated rather than a fixed interrogation: Basic asks 16 questions across about four rounds, Moderate 22 across five, Advanced 23 across six. Nothing about marketplaces or gateways is asked unless the answer would actually change your build.

Twenty-one features are defined (OS-F01 through OS-F21), each with its own lifecycle and acceptance wording — store identity, catalog media and variants, storefront discovery and product page, cart and checkout, order admin and timeline, stock, customer accounts, dashboard reports and exports, discounts, returns and refunds, shipping and pickup, reviews, notifications, import/export, digital downloads, productized services, preorders and subscriptions, multi-currency and regional tax, marketplace vendors and commission, store-builder multi-tenancy, and payment gateway reconciliation.

You are not sold all twenty-one. A scope budget caps what any depth may claim: Basic is 8 features and 42-45 functions across 8 workflows with 5-6 buyer checkpoints; Moderate 12-14 features and 60-80 functions with 8-11 checkpoints; Advanced 15-17 features and 76-100 functions with 12-18 checkpoints. Unselected families are permitted only in non-goals, risks and roadmap.

The package ships as START-HERE.md plus three working directories: instructions/ with the automated QA contract and UI audit script, a runtime, a generated-spec contract and the scope budget; tools/ with an executable scope resolver, a 25 KB scope policy and smoke tests you can run; and wiki/ with a 251 KB feature map, its validator, and depth-specific question files.

Proven in a live build-off

This planner has been dogfooded end-to-end: three working storefronts were built from it by three coding models — Claude Fable 5, GPT-5.6 Sol and Grok 4.5. All three run as live demos you can shop and check out in from this page, and the full audited ranking is published as a PlanSmith benchmark. The planner is the product; the apps are the proof.

Coverage

Store shape first. Single-product offer, multi-product catalog, digital product store, productized-service store, marketplace, or store-builder platform — each with its own required product differences, so the six do not render as the same app with relabelled buttons.

Named anti-patterns. The planner blocks the specific failures the research caught in the wild: admin sidebars that open with Governance, Policy or Audit Evidence instead of Dashboard, Products, Orders and Inventory; variants implemented as display-only labels that never affect availability or the order snapshot; returns implemented as a single status dropdown; marketplace implemented as one vendor field; and fake SVG placeholder products standing in for real product media.

Done means both paths. No feature counts as complete until it appears in the customer path and the owner admin path where both apply. Stock is rechecked at order creation, checkout must produce a durable order or an honestly labeled payment-handoff record, manual and cash-on-delivery payment are first-class rather than second best, and any real gateway branch carries webhook, idempotency and refund-reconciliation gates.

Proven, not asserted. Three coding models built this planner to full scope. Each independently selected 15 of the 21 features — and the six they set aside were exactly the umbrella branches the research says belong outside a normal store. All three stores are live below.