Restaurant Management Planner

The problem

"Build me a restaurant POS" is a prompt that reliably goes wrong with a coding agent. The agent builds something (a sales form, an invoice screen, maybe a good-looking dashboard) and calls it done. Then you find there is no kitchen ticket flow, no shift close, no floor plan and no way to record a split bill. Nothing shows that the reports come from real orders and not from seed constants. You spend two weeks debugging a system that was never scoped as a restaurant system.

Restaurant management software is several products under one name. The subtypes include counter-service cafe, full-service dine-in, QSR, bar, pizza/takeaway, cloud kitchen, QR table ordering and multi-location chain. Each has different required modules, different optional branches and different ways to fail. A generic prompt merges them into one invented mix, or picks the wrong subtype without telling you. The result is scope that drifts: integrated payments that are claimed but missing, hardware integration that is implied but untested, a KDS that is a static admin table when it should be a working kitchen screen, and a floor plan replaced by a text box for the table number.

What it is built from

The planner is based on research done in two passes: 145 source pages reviewed and 50 uniquely counted restaurant products. A strict audit then removed duplicates and grouped the pages into sets of comparable products, and only after that was anything counted as evidence.

Core POS and kitchen features are measured against a set of 29 comparable products:

• Menu and item catalog, service modes, and POS order entry: 29/29.
• Payments: 28/29.
• Receipts and kitchen tickets: 27/29.
• Reporting: 25/29.
• Order-status lifecycle: 23/29.
• A real kitchen display system: 15/29.
• Configurable modifier groups: 10/29.

Optional capabilities outside core POS are measured against their own smaller sets, so a specialist feature is compared only with products of its own kind:

• Ingredient stock and purchasing: 8 inventory-and-cost products.
• Reservations and host-stand features: 8 booking products.
• Direct/QR/delivery ordering: 14 ordering products.
• Staff scheduling: 4 workforce products.
• Loyalty and guest engagement: 6 guest-engagement products.

A coding agent cannot produce these counts unless it repeats the research and the pass that removed duplicates. It can generate a restaurant app. It cannot tell you, with evidence, that:

• A visual floor plan is a common dine-in branch and should not be a Basic default (52% of the core set, and only where there is table service).
• The moment when ingredients are taken out of stock is a hard design decision. Taking them out at payment can be too late for a kitchen.
• Shift close and the cash drawer cause real disputes between staff. They need a structured review screen that shows expected amount, counted amount and the difference. A browser confirm box is too little.

The planner writes these points as decision rules tied to the product set they come from, so the generated spec follows what the market has already tested.

What you get

One build spec ready for your agent, produced after a structured discovery interview: CLAUDE.md for Claude Code, AGENTS.md for ChatGPT Codex, or the file your tool prefers. The planner asks its questions in grouped blocks: First Delivery depth (Basic, Moderate or Advanced), venue shape, service mode (counter, dine-in, takeaway, delivery, phone, QR or a mix), roles, the core POS and order loop, which optional branches belong in First Delivery, payment method, hardware plans, local policy fields, UI priority, visual direction, stack and hosting preference, and Build Execution Mode.

The generated spec includes locked decisions and a list of what is out of scope, a scope table with citations, roles and permissions, a full data model, a screen map, UI requirements with visual direction, workflows, technical requirements, setup and seed data, reports, a step-by-step build sequence, acceptance tests, handover audit requirements, risks and points still to confirm, a plan for later changes, and the result of a forbidden-family scan, which stops deferred modules from entering the active build sections.

You choose the Build Execution Mode and it is then locked:

• Guided Step Mode stops after each step and needs proof before it continues.
• Batch Mode stops after a batch of steps that you choose, with proof for each step.
• Autopilot Mode continues only while every check passes and stops at the first failure.

Tested in a build-off

Four coding models built four working restaurant management apps from this planner: Claude Fable 5, GPT-5.6 Sol, Grok 4.5 and Gemini 3.1 Pro. All four run as live demos you can log into from this page, and the full audited ranking is published as a PlanSmith benchmark. We decided the ranking by running all sixteen lifecycles from start to finish. Reading feature lists would have missed the difference: for example, whether a sale takes the recipe's ingredients out of stock.

What it covers

The planner runs six structured discovery blocks before it writes the spec:

• Phase 0 picks the First Delivery depth and warns early if the scope is too large, before any code is written.
• Block 1 locks venue shape, service mode and number of locations. Basic defaults to a single counter-service restaurant. Multi-location is an Advanced branch you must choose.
• Block 2 identifies the roles and the one user First Delivery must serve best. That decides the main screen.
• Block 3 covers the core POS and order loop: menu, modifiers, sold-out toggle, POS grid, payments, receipts and order tickets, shift open and close, dashboard, reports, audit log and go-live checklist.
• Block 4 asks about every optional branch: dine-in floor plan, split bill, KDS and station routing, QR ordering, phone and delivery queues, reservations, inventory and recipe costing, integrated payments, hardware drivers, offline sync, multi-register, multi-location and loyalty.
• Block 5 and Block 6 lock payment method, hardware plans, local policy fields, UI priority, visual direction, stack preference and Build Execution Mode.

The planner then runs a forbidden-family scan across roles, data model, screens, workflows, technical requirements, reports, jobs and APIs, build sequence and acceptance tests before it writes the final spec. Deferred modules may appear only in the out-of-scope list, the deferred list, the risks and points to confirm, the plan for later changes, or the scan result.