Two builds: agent-era commerce and a UK property-price map

Two projects went from empty repo to running production this week. They look unrelated on the surface. One is a commerce platform, the other is a property-data map of Kent. What they have in common is the part I find interesting right now: both treat machines as first-class users, not an afterthought bolted on at the end.

Here is what each one does and the decisions behind them.

shop-template: commerce that an agent can actually buy from

Most "AI-ready" claims mean a chatbot in the corner of the page. shop-template takes a different position. It is a normal Laravel storefront that a human can shop, and the same checkout actions are exposed over three separate agent payment rails so software can shop too.

The human side is conventional and fast. Inertia v3 with server-side rendering, React 19, Tailwind 4, AVIF images, and the SEO work done properly: per-page meta, Product and Offer and Breadcrumb JSON-LD, a sitemap, canonicals. It scores Lighthouse 100s because the boring parts were not skipped. Catalogue is products to options to variants, each variant carrying its own SKU, price, and stock. Checkout uses GoCardless Instant Bank Pay, so there are no card forms and no PCI scope to worry about.

The agent side is the reason the repo exists. Three surfaces, all sitting on top of the same checkout code:

• MCP server at /mcp/shop. An agent can search the catalogue, build a basket, and reach a checkout, all conversationally. A second admin MCP, gated behind OAuth, lets the merchant run the shop by chat.
• Agentic Commerce Protocol, the standard ChatGPT shopping speaks. That means a signed product feed and checkout sessions.
• x402, where an agent settles an order in USDC on Base with no human in the loop. For a digital product, an agent can discover, buy, and download a file on its own.

One design choice is worth calling out because it gets the boundary right. The agent checkout deliberately stops at a signed pay link. Payment is authorised by a person at their own bank. Agents assemble the order, people approve the money. That keeps the autonomy useful without handing a wallet to a script.

The rest is the unglamorous merchant reality that a real shop needs and most templates ignore: a guarded order status machine with refunds and packing slips, discounts including once-per-customer, VAT handling, review moderation behind RBAC, abandoned-checkout recovery, back-in-stock waitlists, and support replies drafted from the customer's actual order history. It ships with 200-plus tests, Larastan at level 7, and a CI gate that fails the build if you add a capability without documenting it.

It runs on SQLite with no external services until you want them. Payments, address lookup, and the AI features all use the same driver pattern with a none or fake default, so a fresh clone runs with zero API keys. Swapping SQLite for Postgres, local media for S3, or search for Meilisearch is configuration, not code.

It is open source under MIT. Clone it, change two files to brand it, and you have a working shop the same afternoon.

real-estate-data: what a house actually costs per square foot

The second project answers a question that sounds simple and is not: what does property cost per square foot, street by street, across an area? Asking prices tell you almost nothing. Sold prices exist in Land Registry data but carry no floor area. Floor areas exist in EPC certificates but carry no price. Neither source agrees on how an address is written.

The repo is the pipeline that reconciles them. It is a sequence of artisan commands, each one a stage:

1. Import postcode district and sector boundaries from ONS.
2. Import two years of Land Registry price-paid transactions.
3. Pull floor areas from around 400,000 EPC certificates.
4. Match transactions to certificates to produce a price per square foot.
5. Geocode the results through Postcodes.io.
6. Import roughly 845,000 OS building footprints.
7. Match each property to its building polygon.
8. Pre-calculate district and sector aggregates.

The matching step is where the real work lives, because addresses never line up cleanly. A match is recorded with an honest confidence level rather than a false binary. An exact match means postcode and address agreed. A fuzzy match means the addresses were close enough to trust. An estimated match means the floor area was inferred from similar properties nearby. Storing that confidence means the map can be truthful about how sure it is, which matters more than pretending every point is gospel.

The output is a Mapbox map backed by PostGIS that changes what it shows as you zoom. At low zoom you get a choropleth of postcode districts. Zoom in and sectors become circle markers. Zoom further and individual properties appear as points, then as their actual building outlines. The API serves each layer from pre-aggregated tables and viewport bounds, so panning around the south east does not melt the database. Filters cover time window and property type.

There is also an "ask the map" endpoint. It takes a plain English question about the data and answers it using Claude, with a clear failure mode if the model is unavailable rather than a hang or a stack trace. It is a small feature, but it is the same theme as the shop: give a machine a sensible way in, and handle the unhappy path like an adult.

The thread between them

A commerce template and a property map do not belong in the same sentence, except for one thing. In both, the interesting design pressure came from a non-human consumer. In the shop it is an agent that needs to transact without a browser. In the property pipeline it is a matching process that has to make defensible decisions across messy public data, and a model that has to answer questions without making things up.

Both are live. shop-template is open source and the code is there to read. If either is close to something you are trying to build, the repos are the fastest way to see how I approached it.