Event ticketing — the model build-off
We hand the same event-ticketing planner to four coding models, lock the discovery answers and the feature ledger, then audit what each one actually shipped. Ticketing looks like ordinary online shopping right up until the doors open. A ticket is not stock on a shelf — it is admission to one night, and the same seat sold twice is a real person turned away in front of a queue. So these scores are about the things that only matter under pressure: whether the last seat can be sold twice, whether a refunded ticket still opens the gate, and whether the person scanning at the door can tell a duplicate from a valid entry in one action.
How the builds ranked.
Beacon Hall Presents
Best OverallThe one to copy. It is also the only build here that runs anywhere you want to put it.
- Best at
- Being checkable. Every claim it made about itself held up when we re-ran its own checks on our machine — all 114 of them, plus 43 separate acceptance checks, with no failures. Money behaves: a refund needs a stated reason, and refunding the same order twice still only returns the money once. The door works — a ticket admits on the first scan and is flagged as a duplicate on the second, and a refunded ticket is refused. Nobody else's customer details are reachable from a ticket link, because those links are effectively unguessable.
- Watch for
- A handful of its checks are summaries that lean on other checks rather than testing anything themselves, so the honest count of independent checks is 103 rather than 114. Staff screens also pull their fonts from the internet, which a venue with poor connectivity would notice.
Lantern Tickets
Cleanest ReportingSolid work, and the closest of the three to being publishable — it needs its framework brought up to date, nothing more.
- Best at
- Saying what it actually did. Its checks re-ran perfectly on our machine, and where something could not be tested automatically it says so plainly instead of quietly counting it as a pass. It never claims to be finished — its own status reads 'waiting for QA'. Staff sign in with real passwords, properly scrambled. When it refuses a member of staff, it names which roles do have access, so the person knows who to ask.
- Watch for
- It is built on a version of its web framework that has sixteen published security problems, including ways to inject content into pages and to poison what other visitors are served. Nothing this build wrote is at fault, but we did not put it online because of it. Upgrading the framework is the whole fix.
No public demo — held back until its web framework is updated to a patched version.
Juniper Arc Events
Most ThoroughThe most carefully engineered build here — and the one you can least easily take away with you.
- Best at
- Depth and self-honesty. It wrote the most checks by a distance — 149, nearly all of them treated as launch-blocking — and it records its own failures, including an earlier review round that it failed before passing. It builds a second pretend company into its own testing so it can prove one organisation cannot read another's records. Protections live in the database itself, not just in the app code, so they hold even if a screen forgets to ask.
- Watch for
- It has no way to log in. Passwords were never built — signing in only ever worked through a role picker that the finished build switches off, so on a real server every page sends you to a sign-in screen that returns 'not found'. Its original home handled that for it. Separately, 105 of its 149 checks no longer re-run cleanly, because they look for exact wording in code that later work legitimately changed — in one case the code is actually safer than its own check expects.
No public demo — the finished build has no sign-in screen, so there would be no way for a visitor to get in.
Apex Stage Ticketing
Not ReadyDo not ship this one without repairs. The repairs are small, and we have written them up.
- Best at
- The fundamentals, oddly. It scrambles passwords properly, signs its sessions, and its door scanner is correct — admits once, flags the duplicate, refuses a refunded ticket. The machinery is sound.
- Watch for
- Two leftover shortcuts hand anyone a manager's account without a password — one of them just by loading a page. And any signed-in account, including a customer's, can read every order in the system: names, emails, phone numbers, amounts. It also reports one whole feature as finished that was never built, and its own checks report all-green while ten of the most important ones never ran.Fixed since audit — the sign-in shortcuts are deleted, orders are scoped so a customer sees only their own, and the app now refuses to start on the signing key that shipped inside its own source. Repairing it also uncovered something the shipped database had been hiding: on a genuinely empty database this build could not start at all. The two remaining items — the feature reported finished but never built, and the ten checks that never ran — are unrepaired.
Models tested: Claude Fable 5, GPT-5.6 Sol, Ox Alpha and Gemini 3.7 Flash. Three of the four — Fable 5, Sol and Gemini — built from a byte-identical planner package, so those three numbers are directly comparable. Ox Alpha ran a slightly earlier version of the same planner (15 build steps rather than 16), so its score is indicative rather than strictly like-for-like. Scores are as found at audit; later fixes are noted but do not change the number. Not every build earns a public demo, and where one is missing we say why rather than quietly linking nothing. These grade correctness, not visual design.