Restaurant ·

We had four AI models build the same restaurant system. The screens matched. The workflows didn't.

Put four restaurant systems side by side and they are hard to tell apart. Each has a till with a menu down one side and a running check on the other. Each has a kitchen screen with tickets, a floor plan with tables that change colour, a stock page, a reports page. Click through them for ten minutes and you would struggle to say which one is better, let alone which one you could run a Friday night on.

We know, because we did exactly that and got it wrong. Our first pass scored three of these builds level. They were not level. The difference only showed up when we stopped looking at screens and started pushing orders through them: selling a dish and checking what happened to the stock, splitting a party and clearing the table, refunding a settled bill, clocking a server in for a shift.

This is what four frontier coding models built from one restaurant planner, what separated them, and what that means if you are about to build one yourself.

The setup

One planner, four models, one brief.

The planner was PlanSmith's advanced full-service restaurant package — the largest scope anyone had attempted on it: sixteen features, from point of sale and the kitchen display through floor plan, reservations, QR ordering, inventory, purchasing, recipes, staff scheduling, loyalty and multi-location reporting. Every model received the same package, the same discovery answers and the same feature ledger. None was told what the others were doing. None was coached before it was scored.

The four models:

  • Claude Fable 5, which built Copperline
  • Grok 4.5, which built Passline
  • GPT-5.6 Sol, which built Miseboard
  • Gemini 3.1 Pro, which built SavoryPOS

Each build was scored against its own selected scope. That matters more than it sounds. Two of these builds chose different, equally legitimate ways to track food cost, and a rubric written around one of them would quietly mark the other wrong. We score what each build said it would deliver, not what one build's architecture happens to look like.

What shipped

Copperline (Claude Fable 5). All sixteen features, on a conventional stack that deploys anywhere, with real sign-in and permissions checked on the server. It flagged its own unfinished edges on a go-live checklist instead of hiding them — the only build that told us, unprompted, where it was not done.

Passline (Grok 4.5). All sixteen features on a service floor in Karachi, priced in rupees, with the best multi-site handling of the four and the strongest sign-in security. It shipped one-click role buttons for its demo, so a visitor can be a server, a host or a group manager in a second.

Miseboard (GPT-5.6 Sol). The same sixteen features, spread across 93 sub-features and 109 ledger rows, and the most rigorous about money: a till has to be open for today's trading before anything can be rung up, and past days lock. It was built to sign people in through the platform it was built on, and nowhere else.

SavoryPOS (Gemini 3.1 Pro). The widest surface by the end: eighteen staff screens, including accounting, catering, a self-service kiosk and delivery-app orders. It did not start there. The first version it handed over was roughly half the product — seven of its thirteen planned build steps were missing — while reporting itself complete.

The board

As published on the restaurant build-off board, as found at audit:

RankModelBuildScore
1Claude Fable 5Copperline96
2Grok 4.5Passline91
3GPT-5.6 SolMiseboard89
4Gemini 3.1 ProSavoryPOS58

These are as-found scores. Two of the builds were repaired after the audit, and the board says so under each one, but a repair never moves the number. A build that shipped correct is not ranked level with one that was fixed later, and the gap between them is exactly what someone building this for real needs to see.

What broke

Nothing below is a missing screen. Every build that lost points had a screen for the thing in question. What it did not have was the behaviour behind it.

Selling a dish has to do something to the stock

This is the restaurant's core loop, and it is invisible on a screenshot. When a burger is sold, the kitchen consumes a patty, a bun and some butter. A restaurant system either records that or it does not.

Copperline records it at the moment of sale. We sold a burger and watched the patty count fall from 60 to 58 across two orders, the buns from 58 to 57, and the butter drop by exactly the recipe amount plus the modifier, each movement tagged as a sale. That is a perpetual model: stock is always current.

The other two leading builds took a different route that is just as valid. They compare what you should have used, based on what you sold, against what a physical count says you actually have. The variance between the two is your waste, theft and over-portioning. Restaurants run both ways, and scored against its own chosen model, each build passed. If you are auditing builds like these yourself, this is the trap to watch for: test every build for the model you happen to prefer and you will fail a build that is correct.

What Copperline did not hide: seventeen of its thirty menu items had no recipe costed against them, so selling those reduced nothing. Its own checklist said so. That is the difference between a gap and a defect — one is disclosed, the other is discovered.

A manager has to be able to build the menu

Every build could sell an item with required modifiers — how the steak is cooked, which side. Only some could let a manager create one.

Passline enforced modifier groups correctly at the till, but they could only be loaded in beforehand. There was no way to add a new required choice from inside the app. For a restaurant that changes its menu seasonally, that turns a two-minute edit into a support ticket. Copperline and Miseboard both let us create a sellable item with a required modifier live.

A settled bill should stay settled

Refunds are where money software earns its keep. Every build gated refunds behind a manager and refused a server who tried. But refunding a bill that had already been paid in full did something odd in Passline: it reopened the bill. A closed check came back to life, which is the kind of thing that makes a Z-report stop matching the drawer at two in the morning.

A manager's approval has to check who they are

Discounts and voids need a manager. The obvious way to build that is a password prompt. The subtle failure is a prompt that accepts any valid password. Copperline re-checks the role behind the password: a real cashier's correct password still would not authorise a discount. It is a small detail, and it is the detail that decides whether a discount control is a control.

The system has to run where you put it

Miseboard was the most rigorous build on money, and on the day we audited it, nobody could sign into it anywhere except the platform it was built on. Its login was delegated to that host. For a buyer who wants to run their own restaurant system on their own server, the most careful build in the group had no front door.

It was repaired afterwards — it now has its own password accounts and runs on its own — and the board marks that as fixed since audit. The score stays where it was on the day.

Screens have to survive being clicked

SavoryPOS is the reverse story. Where Miseboard was deep and fenced, SavoryPOS was wide and cracked. By the time we drove its sixteen workflows it had eighteen screens, a real database and proper sign-in. It also had a receipt page that went blank after a sale, staff who could not clock in, and a group dashboard that counted every sale twice — $66.96 reported against a true $33.48 — because two records described the same register. Two exports produced output no spreadsheet could use.

Each of those was a small fix, and all five were fixed and re-checked on a clean install. But each would have broken a live demo in front of a customer.

Branch managers should only see their branch

This is where the three leading builds were genuinely strong, and where Passline was best. A branch manager at one location could not see another location's sales, and the refusal happened on the server, not by hiding a menu item. With two sites open side by side, the numbers stayed apart.

See it running

All four builds are live. Sign in and push an order through — it is the only way to see the differences above.

The Miseboard and SavoryPOS demos are the repaired builds. The scores are not.

What it means if you are building one

The lesson from this build-off is not that one model is better. On a single vertical, with a single planner, three frontier models produced restaurant systems that genuinely work, and the fourth got there with help. The lesson is that feature parity is not product parity, and you cannot tell them apart by looking. It is the pattern behind why AI coding agents over-build your app: the surface arrives first, because it is what the model can picture.

Every build that lost points had the screen. What it lacked was the behaviour a restaurant depends on when nobody is watching: stock that moves when food leaves the kitchen, a bill that stays closed, a manager who can change the menu, a login that works on your own server, a dashboard that adds up.

So test the behaviour, not the screen. Before you trust whatever your coding agent hands you:

  • Sell a dish and look at the stock. Either it moved, or a variance report accounts for it against a count. If neither, food cost is a label.
  • Create a new menu item with a required choice, from inside the app. If you cannot, your menu is frozen at whatever the seed file said.
  • Refund a bill that is already paid. It should record a refund and stay closed.
  • Approve a discount with a cashier's correct password. It should still be refused.
  • Split a party of six across two checks, then clear the table. The table should free up once, not twice and not never.
  • Clock a staff member in and run payroll. If hours are zero, scheduling is decoration.
  • Compare the group dashboard with the register it summarises. They should agree to the cent.
  • Deploy it to your own server before you believe it. If sign-in only works where it was built, you do not own it yet.
  • Open two locations and sign in as one branch's manager. The other branch's numbers should not exist for them.

None of these take more than a minute. Together they are the difference between a system that demos and a system that runs.

The Restaurant Management planner exists to make those behaviours decisions rather than accidents. It carries a frequency-ranked inventory of what real restaurant software does, and it makes your coding agent decide — before it writes code — how stock moves, who may approve what, and what each location can see. Four models built from it, and the results, including the lowest score, are published in full on the build-off board. For the full scope of what a restaurant system involves, see restaurant management system: what it includes, and why it isn't one product.