We had three AI models build the same online store. Taking the order was easy. Taking the money exactly once wasn't.
An online store looks like the most solved problem in software. A catalogue, a cart, a checkout, an order confirmation email. Every coding agent has seen thousands of them, and every one of them can produce something that looks like a shop in an afternoon.
What it cannot see from the thousands of shops it has absorbed is what happens under the checkout button. A shopper double-clicks Pay. Two people buy the last jumper at the same moment. A payment provider says "pending" and never follows up. A customer chooses cash on delivery, and the order sits in the admin screen looking exactly like one that was paid.
We handed the same storefront planner to three frontier coding models and drove every workflow in all three. All of them took a real order from cart to confirmation. This is what separated them, and what to check if you are building one.
The setup
One planner, three models, one brief.
The planner was PlanSmith's online store package: fifteen features, from the catalogue, cart and checkout through payment, fulfilment, returns, reviews, discounts and spreadsheet imports. Each model ran it to full scope in batch mode. None was told what the others were doing. No live card credentials were issued for a demo, so all three keep payment in an honest test mode.
- Claude Fable 5 built Harbor & Pine
- GPT-5.6 Sol built Alder & Stone
- Grok 4.5 built Northstone Goods
The planner is built on a hand count of what 90 ecommerce sources show — platform documentation, open-source store software, store scripts and live admin demos. That count has a lesson of its own. Product variants, customer accounts and order management each appear in about half of them. Payment gateway integration appears in 42 of 90, and inventory tracking in 39. The two things that decide whether a store takes money correctly — the payment path and the stock count — are each documented by fewer than half of the 90. A model that learned e-commerce from what stores advertise has learned the storefront, not the till behind it.
What shipped
Harbor & Pine (Claude Fable 5). All fifteen workflows, driven end to end, with no failures. It ran its own hostile testing before release, found seven bugs in its own work, and fixed them.
Alder & Stone (GPT-5.6 Sol). The most rigorous payment engineering and the tightest permissions of the three. It was built in stages, and at first audit it had honestly stopped three steps in. It is complete now.
Northstone Goods (Grok 4.5). The widest choice at checkout — card, PayPal and pay-on-delivery — with orders that end up honestly marked paid, failed, abandoned or partly refunded.
The board
As published on the online store build-off board, as found at audit:
| Rank | Model | Build | Score |
|---|---|---|---|
| 1 | Claude Fable 5 | Harbor & Pine | 95 |
| 2 | GPT-5.6 Sol | Alder & Stone | 94 |
| 3 | Grok 4.5 | Northstone Goods | 91 |
Three frontier models within four points of each other, all taking real orders. The differences are small, specific and — for anyone about to take money online — exactly the ones worth knowing about.
What separated them
A payment has to be recorded exactly once
The most expensive bug in e-commerce is a double charge, and it comes from something ordinary: a shopper goes back to the payment page, or refreshes it, or the payment provider sends its confirmation twice. If the store records a payment every time it hears "confirmed", one order becomes two charges.
Harbor & Pine is built so that going back to a paid checkout page never charges again. Alder & Stone went furthest on this. Its test payment provider covers every outcome a real one produces — confirmed, declined, pending and abandoned — and a confirmed order is recorded exactly once, so a repeated confirmation cannot charge it again. That is the difference between a checkout that works in a demo and one that works on a flaky mobile connection.
The last item can only be sold once
Two shoppers, one jumper left, both press Buy. A store that checks stock when the item goes into the cart, and not again at the moment of payment, sells it twice. Then someone gets a refund and an apology.
Harbor & Pine checks the last unit inside the same transaction that takes the order, so the second shopper is stopped. Northstone does something related and equally important: stock only leaves the shelf once payment actually succeeds. A declined card or an abandoned checkout does not quietly reserve a product nobody paid for.
Cash on delivery is not cash
Pay-on-delivery is a real payment method in much of the world, and it is a trap for reporting. The order is placed, the goods ship, and the money arrives days later — or does not arrive. A store that counts the order total as revenue when it is placed will show money it does not have.
Harbor & Pine never counts unpaid cash-on-delivery orders as money received. Northstone offers pay-on-delivery alongside card and PayPal, and marks each order by what actually happened to the money. Both are the honest version of a feature that is easy to fake.
Prices can only be changed by the people allowed to change them
Every store has staff who manage the catalogue — photos, descriptions, stock — and should not be able to change a price. The obvious way to enforce that is to hide the price field from them. The subtle failure is every other way a price can change, and the one that catches almost everybody is the spreadsheet import.
Harbor & Pine's own hostile testing found exactly this: catalogue staff could change prices by importing a spreadsheet. It fixed it before release, and price changes are now locked to the owner in three separate places, including the import. Alder & Stone took the stricter route: its imports refuse to carry prices or stock at all. Catalogue staff cannot reach customers, orders, payments or exact prices, and accepting a return never quietly restocks or refunds by itself.
Northstone had the one gap of this kind on the board: its customer list could be read by catalogue and warehouse staff, which contradicted its own permissions table. That was closed after the audit, and the list is now owner-only.
A discount changes the tax
A small one, and a good sign of care. When a discount code reduces the price, the tax should be calculated on the reduced price. Northstone recalculates tax on the discounted price rather than the original one.
Honest progress beats a finished-looking build
Alder & Stone was built in stages, and at first audit it had stopped three steps in. Discounts, returns, reviews, imports and payments did not exist yet. What mattered is how it reported that: it said so plainly, instead of calling the store finished. The remaining stages were then completed, and all fifteen features are implemented with the payment loop closing end to end.
Harbor & Pine's honesty ran the other way: it attacked its own build, found seven bugs — including cancelled orders that could still be shipped — and fixed them before release. A build that reports its own flaws is more trustworthy than one that reports none.
See it running
All three stores are live, with demo sign-ins for the staff side.
- Harbor & Pine (Claude Fable 5): os-harborpine.demos.plansmith.io — click Owner on the staff sign-in
- Alder & Stone (GPT-5.6 Sol): os-alderstone.demos.plansmith.io — pick a role on the store-team demos screen
- Northstone Goods (Grok 4.5): os-northstone.demos.plansmith.io — Continue as Owner, password northstone-demo
Place an order, then go back to the payment page and try to pay again.
What it means if you are building one
A storefront is the part you can see. The store is the part underneath it, and it is the part a coding agent will build last and test least unless you make it a first-class requirement. Before you trust whatever your agent hands you, run these:
- Pay for an order, then press Back and pay again. You should see the same paid order, not a second charge.
- Put the last unit of a product in two carts, in two browsers, and check out both. One should fail.
- Abandon a checkout halfway through payment. The stock should still be there.
- Place a cash-on-delivery order and look at today's revenue. It should not include it until the money is marked received.
- Sign in as a catalogue editor and import a spreadsheet with changed prices. The prices should not change.
- Apply a discount code and check the tax line. It should be calculated on the discounted price.
- Accept a return. Stock and refund should each be a deliberate step, not something that happens on its own.
Each of these takes a minute, and each one is a real way stores lose money or trust.
The Online Store planner is the specification these three builds came from: the payment outcomes, the stock rules and the permission boundaries, written so a coding agent cannot quietly skip them. The full findings are on the build-off board. And for why agents skip the hard parts in the first place, see why AI coding agents over-build your app.