Online Store Planner

The problem

Most ecommerce projects built with AI tools fail at the same places: a checkout that does not create a saved order, inventory that is only for show, variants that are labels and not real choices, and a mobile storefront nobody tested before handover. The builder assumed the agent knew what a real online store looks like. It did not.

There is a deeper failure under those. "Online store" covers six different businesses: 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. Each has its own checkout, fulfillment model and admin queues. Ask an agent for "an online store" and it blends all six into a generic app that creates and edits products, with a cart added on. That is why the result feels wrong even when the feature list looks complete.

What it is built from

The planner rests on two separate research passes that do different jobs.

The first pass counted features across 90 core sources: official platform docs, open-source ecommerce starters, live marketplace scripts and audits of demo admin panels. It counted how many sources showed each feature and did not infer any:

• Product variants with real SKU, stock and checkout-line snapshot behavior: 49 of those 90.
• Customer accounts: 48.
• Order management: 47.
• Checkout and order creation: 44.
• Payment gateway integration, and storefront search/filter/sort: 42 each.

The second pass, run in July 2026, rebuilt the model from the start across 72 named sources and corrected its shape. Its finding: the main object in a store is a path, and a product record is only one part of it. The path runs from the product the customer sees, to the option or variant choice, the cart line, checkout, the order, admin fulfillment and the handoff to the customer. If that path is not visible early, the build feels wrong however many admin screens exist. The second pass also showed that marketplace and store-builder are expert branches. They are far more than a checkbox inside a normal store.

A coding agent cannot state "found in 49 of 90 reviewed sources" unless it repeats the research, and it cannot work out the six store types from a prompt. Both passes are built into the decision rules, so the generated spec treats them as required checks.

What you get

The planner fixes your store type first, then sizes the build to it. The number of questions depends on the depth you choose: Basic asks 16 questions in about four rounds, Moderate 22 in five, Advanced 23 in six. It asks about marketplaces or gateways only when the answer would 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 do not get all twenty-one in one build. A scope budget limits what each depth may include:

• Basic: 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.

Families you did not select may appear only in the out-of-scope list, the risks and the roadmap.

The package contains START-HERE.md and three working directories:

• instructions/ holds the automated QA rules and UI audit script, a runtime, the rules for the generated spec, and the scope budget.
• tools/ holds an executable scope resolver, a 25 KB scope policy and smoke tests you can run.
• wiki/ holds a 251 KB feature map, its validator and question files for each depth.

Tested in a build-off

Three coding models built three working storefronts from this planner: 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.

What it covers

Store type first. Single-product offer, multi-product catalog, digital product store, productized-service store, marketplace or store-builder platform. Each has its own required product differences, so the six do not come out as the same app with renamed buttons.

Known failures, blocked by name. The planner blocks the specific failures the research found in real products:

• Admin sidebars that open with Governance, Policy or Audit Evidence. They should open with Dashboard, Products, Orders and Inventory.
• Variants built as display-only labels that never affect availability or the order snapshot.
• Returns built as a single status dropdown.
• Marketplace built as one vendor field.
• Fake SVG placeholder products in place of real product media.

A feature is done only on both sides. No feature counts as complete until it appears in the customer path and in the owner's admin path, wherever both apply. Stock is checked again when the order is created. Checkout must produce a saved order, or a payment-handoff record that is honestly labelled. Manual payment and cash on delivery are treated as full options. Any real gateway branch must handle webhooks, duplicate requests and refund reconciliation.

Tested in real builds. Three coding models built from this planner at full scope. Each one selected 15 of the 21 features on its own, and the six they left out were exactly the large branches that the research says belong outside a normal store. All three stores are live below.