Retail POS Planner

The problem

Most POS builds made with AI tools fail at the counter. The agent delivers something that looks like a till, then fails as soon as money moves:

• Checkout never writes a saved, numbered receipt.
• Stock does not go down when you sell.
• A "void" button removes the sale from the very report that exists to catch theft.
• A return hands cash back but never reverses the stock, the loyalty points or the store credit that the sale created.

One person can ring a sale, pocket the cash, void it under their own name and leave a drawer that balances to zero.

These are serious faults, well beyond polish. They are why a retail POS is the hardest small-business app to get right. The failures are on the money path, and a generic agent has no reliable picture of the controls a real till enforces. It shows background inventory, policy and admin menus before the counter even works, treats a refund as a status dropdown, and labels three hardcoded numbers a "Z-report".

What it is built from

The planner is based on a count across a fixed set of 60 retail POS products, drawn from 127 inspected source pages: live products (Lightspeed, Hike, Shopify POS, Square, ERPNext, Dynamics, RMH and more), marketplace scripts and open-source codebases. Every capability carries a coverage figure that links to a product-feature table a program can read:

• Cashier sell/checkout: 60/60.
• Stock visibility: 58/60.
• Reporting backed by source records: 51/60.
• Register/cash close: 18/60.

A coding agent cannot state that register close appears in 18 of 60 inspected sources, or that its risk matters more than that low count suggests, unless it repeats the research. More important, it does not know the control rules the research records:

• A void must reverse every ledger the sale wrote, and must still appear in the reports.
• A refund reverses stock, loyalty and stored value in one transaction, or it does nothing.
• A large register variance and a discount above the limit need a second signature from someone other than the person acting.

These rules are in the package because a real till depends on them, and they are where generic builds fail.

Tested in a build-off

Three coding models built three working point-of-sale systems from this planner: GPT-5.6 Sol, Claude Opus 4.8 and Grok 4.5. All three run as live demos you can ring a sale through from this page, and the full audited ranking is published as a PlanSmith benchmark.

What you get

A planner that settles the counter experience before anything else. It takes your agent through the depth and store-model decisions, then holds the build to checks on the money path:

• Depth tiers with clear limits. Basic is a counter you can sell from: 8 features / 24 functions / 5 workflows. Moderate is an owner-operated store: 14-18 features / up to 54 functions. Advanced reaches 19-22 features / up to 66 functions, with register control, purchasing, counts, staff approvals, transfers, offline and stored value.
• The cashier is the user the product must serve best. The cashier must complete a correct sale fast without losing the queue. Sell, held sales, tender, receipt, lookup and permitted returns lead the product. Governance, policy and audit menus are not allowed in the main navigation.
• Money integrity as required checks. Saved numbered receipts, stock that matches every movement, refunds that reverse stock + loyalty + stored value together, register open/close with a counted variance, and second-signature approval on the screens that move money. Each one is proven by running its own lifecycle. A ticked box is not accepted as proof.
• Store model as a separate choice. Single store, multi-location with transfers, and omnichannel/ecommerce are separate decisions. None of them is added to a core till without your selection.

The planner produces a main CLAUDE.md or AGENTS.md and separate spec files. A custody check stops the agent from writing code before the spec is written and locked.