Retail POS Planner

The problem this kills

Most vibe-coded POS builds collapse at the counter. The agent delivers something that looks like a till, then fails the moment money moves: checkout that never writes a durable numbered receipt, stock that doesn't decrement when you sell, a "void" button that erases a sale from the very report that exists to catch theft, and returns that hand cash back but never reverse the stock, the loyalty points, or the store credit 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 not polish bugs. They are the reason a retail POS is the hardest of the small-business apps to get right — the failure surface is the money path, and a generic agent has no grounded model of the controls a real till enforces. It exposes background inventory, policy and admin menus before the counter even works, treats a refund as a status dropdown, and calls three hardcoded numbers a "Z-report."

Why your agent cannot fake this

This planner is grounded in a frequency audit of a fixed 60-product retail-POS cohort, drawn from 127 inspected source pages across live products (Lightspeed, Hike, Shopify POS, Square, ERPNext, Dynamics, RMH, and more), marketplace scripts, and open-source codebases. Every capability carries a coverage anchor — cashier sell/checkout 60/60, stock visibility 58/60, source-backed reporting 51/60, register/cash close 18/60 — tied to a machine-readable product-feature matrix, not to the model's guesses.

Your own agent cannot reproduce "register close appears in 18 of 60 inspected sources, and lifecycle risk overrides that low marketing frequency" without redoing the scrape. More importantly, it does not know the control rules the research encodes: that a void must reverse every ledger the sale wrote and still appear in the reports; that a refund reverses stock, loyalty and stored value inside one transaction or not at all; that a material register variance and an over-threshold discount need a second signature from someone other than the person acting. Those rules are in this package because a real till lives and dies by them — and they are exactly where generic builds fail.

Proven in a live build-off

This planner has been dogfooded end-to-end: three working point-of-sale systems were built from it by three coding models — 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. The planner is the product; the apps are the proof.

What you actually get

A cashier-first planner that locks the counter experience before anything else. It walks your agent through depth and store-model decisions, then holds the build to money-path gates:

• Depth tiers, honestly bounded. Basic is a shoppable counter — 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 must-love role is the cashier. 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 forbidden from primary navigation.
• Money integrity as hard gates. Durable numbered receipts, stock that reconciles to every movement, refunds that reverse stock + loyalty + stored value together, register open/close with counted variance, and second-signature approval on the surfaces that move money — each proven against its own lifecycle, not a completion checkbox.
• Store model as an explicit branch. Single store, multi-location with transfers, and omnichannel/ecommerce are separate decisions — never silently bolted into a core till.

The planner emits a hot CLAUDE.md or AGENTS.md plus split spec files, with a custody gate that stops the agent from scaffolding before the spec is written and locked.