Ecommerce Inventory Management Planner

The problem

Ecommerce inventory apps built with AI tools oversell, drift out of step with the sales channels and show wrong stock, in the same predictable ways:

• Available-to-sell is one editable number. It should be a computed value (on-hand − reserved − channel buffer + incoming), so orders keep arriving for stock that is already committed.
• Channel sync pushes a quantity and never reads it back. When a marketplace rejects the update or applies it late, there is no reconciliation queue, and the numbers quietly drift apart.
• Orders are ingested twice, because nothing checks for duplicates.
• Bundles and kits do not reduce their shared components in one step, so a two-SKU bundle keeps selling after one part has run out.
• Returns are a single "restock" button, with no receipt, no inspection and no choice between sellable and damaged.
• A "connected channel" has no model of who holds the stock: no baseline, no pause and no safe way to disconnect.

This planner is written so the generated spec rules these failures out. Quantity is worked out from movements and reservations. Every publish to a channel has a visible lifecycle (queued → sent → accepted → verified → failed → retried → reconciled). Order ingest removes duplicates and reserves stock before it promises anything. Bundles reserve against the component that runs out first.

What it is built from

The planner comes from a research pass over 97 live ecommerce inventory products: Shopify inventory and Marketplace Connect, BigCommerce, and the multi-channel operations products (Cin7, Linnworks, Sellbrite, Extensiv/Skubana and similar). The material was taken from the vendors' own product pages and not from marketing summaries. It was sorted into 11 product families:

• channel connection and custody
• catalog identity and listing mapping
• the inventory-network quantity model (on-hand, reserved, unavailable, buffer, incoming, available-to-sell)
• synchronization with failure recovery and reconciliation
• order ingest, reservation, fulfillment handoff and cancellation
• returns receipt, inspection and disposition
• bundles, kits and shared components
• replenishment, purchasing, receiving and transfers
• stock corrections, evidence, import and export
• operational intelligence and decision evidence
• governance and integration contracts

Five capability areas are kept apart as explicit branch families: marketplace/FBA/3PL fulfillment, distributed order orchestration, preorder/backorder supply, dropship/vendor fulfillment, and listing/PIM/content syndication. They are built only when you select them, so they never appear in a Basic build by default.

Per-feature figures from this research are still in verification review and are not cited as counts yet. What the planner delivers today is the set of families and the branch rules.

Tested in a build-off

Three coding models built six working ecommerce inventory apps from this planner: GPT-5.6 Sol in four build runs, Claude Opus 4.8, and Gemini 3.1 Pro. The five that were ready to deploy run as live demos you can log into from this page.

Stockweave, the strongest build of the set, with a six-dimension quantity model (on-hand, committed, available, incoming, in-transit, partner-held). You can log into it from the demos below.

What you get

A structured interview that makes you take the ecommerce decisions before any code is written: how many sales channels and which ones, whether stock is in one location or several, the exact quantity model (does available-to-sell subtract reserved stock and channel buffers, is incoming stock tracked), how sync failures appear and are reconciled, whether orders reserve stock on ingest, roles and tenant/location scope, bundles and shared components, the loop from replenishment to receiving, returns disposition, and which of the five advanced branches are in scope.

After discovery, a forbidden-family scan keeps neighbouring scope out unless you select it. Full POS retail, warehouse execution (bins, pick/pack, putaway), manufacturing/BOM and accounting ledgers are boundary or branch families. They belong to their own planners and do not enter an ecommerce stock build.

The output is one complete build spec written for your tool: CLAUDE.md for Claude Code or AGENTS.md for ChatGPT Codex. Each build step names the tables it touches, the screens it produces and its seed data, and has a firm acceptance check before the next step begins.

What it covers

Basic: canonical products/variants/SKUs, one or more sales channels with a real connection/custody state, the derived quantity model (on-hand, reserved, available-to-sell, incoming), sync that publishes and reads back, with a reconciliation queue, order ingest that reserves stock, adjustments and counts with reasons on a movement ledger that cannot be edited, low-stock review, reports with real CSV exports, and an operations dashboard where every tile opens its source rows.

Moderate adds: SKU alias/mapping across channels, multi-location and transfers, the replenishment → purchase-order → receiving loop, bundles and kits with shared-component reservation, returns receipt and disposition, and import/export at scale.

Advanced covers the branch families: marketplace/FBA/3PL custody, distributed order routing and promise optimization, preorder/backorder selling, dropship/vendor fulfillment, and listing/PIM/content syndication. Each one needs your selection before it enters the build.

Full POS, warehouse execution and manufacturing stay out.