I rebuilt the hospitality sector’s supplier survey in 42 hours. Here’s what it took and why I wanted to do it.

Why I’m supporting the Hospitality Sector Council with my time.

200 commits, 61 reviewed pull requests, 72 database migrations and a security audit of 120 checks. The code was the quick bit. The decisions were not.

In 1997 I opened a pub in a derelict swimming pool in Sheffield. I chose every supplier the way everyone did: a salesman’s word and a mate’s recommendation. There was nowhere to find out what other landlords actually thought of any of it. Twenty-nine years and two software companies later, operators are still buying technology largely blind, and the suppliers (I was one of them) still mark their own homework.

So when Tom James at Bill’s, who leads the Hospitality Sector Council’s Innovation Working Group, suggested building on last year’s survey with a new independent, HSC-owned platform, I put my hand up to take it on. Last year’s survey was run by a supplier, and the question of independence hung over it. This year that question lands on me instead. I’ve addressed it at the end of this piece, and I’d welcome your thoughts.

The survey goes live at hscsurvey.org on 16 November and gets its push at the Peach conference on the 18th. This is what it took to get there, with the real numbers. I’m not a developer. I built it by talking to Claude Code, and Claude keeps a log of everything.

It started as something much bigger, and that’s just me thinking bigger than was required.

Back in the summer I spent a weekend building a whole platform, not a survey. I called it SupplierCheck. An operator reviewed a product, the supplier was told, the supplier could respond in public, and when enough operators said the same thing the system would draft a specification for the supplier to build. Fix it, and the same operators would be asked to re-rate you.

I showed it to Tom on 7 October and we agreed to throw most of it away. Better to get 2,000 honest reviews on a plain survey by 18 November than to launch something clever that nobody finishes. Everything from the platform that didn’t serve the survey was cut or hidden. The response feature, the badges, the back and forth between operator and supplier, and the billing all went. The database tables are still there, so it can come back, but the live site is a survey first.

The first tool had left no trace of how it was built.
The summer version was made with a drag-and-drop AI builder. It worked, and it taught me a hard lesson about those tools: the database behind it had been created by clicking, and none of it was written down. When I moved the project to proper source control on GitHub, the original project no longer existed. On 7 October Claude had to reconstruct all 27 core tables from the code that used them, marking every guess as a guess.

The data came from four places and three people’s weekends.
A survey about suppliers is only as good as its list of suppliers. If an operator can’t find their till system, they’ll type it in, and you end up with six spellings of the same company.

The list was built up in layers. The first was last year’s survey, so nobody who was rated last year disappeared. The second was a survey that came out this autumn: Claude ran 15 agents for about 5 hours to pull its company list into the database. The third came from Steve Cowie at Chance & Counters, who had spent a weekend building a crawler that started with one supplier’s integrations page and kept following the links, and ended up with about 180 enriched entries on who integrates with whom. He offered it over a call on 26 October, and it caught companies the other three sources had missed. The fourth was a research pass of my own across the websites and email domains of every company on the list, so the survey could tell a supplier’s staff from an operator by their address.

On 19 October the catalogue went in with 26 product types. On 12 November it came out the other side of a clean-up with 18 types, 223 companies and 298 products. AI and Automation was retired as a category, because a product should be filed by what it does and this catagory was too broad. Products that belong to a group now sit under the group. Every change is in a spreadsheet in the repository, one row per product, with what moved and why.

The working group changed the journey four times.
The site that went to the Innovation Working Group on 29 October is not the site that launches. Their feedback, and the awkward moments of watching people use it, rewrote the flow.

Rate first, register second. The original asked you to create an account and then take the survey. Nobody wants to make an account for a thing they haven’t seen. Now you pick your suppliers, answer the eight questions, and only then give your name, company and work email. Everything is saved in one go and the review counts once you confirm your email.

Only what you use now. Every product starts with a tick box saying you currently use it and your review is based on the current platform. Past grudges are not data.

Eight questions, scored 0 to 10, with a would-you-recommend score first. Overall capability, ease of use, technical support, connectivity with the rest of your stack, value for money, keeping up with technology, growing with your growth, and one I added this year: how well the supplier makes your own data available through an API or an MCP server. Each question got a one-line description after the group said the titles alone were too bare.

Did you mean? When someone types "Nory Ltd" the survey now asks whether they mean Nory before it creates a duplicate. New suppliers and products are held for a human to approve before anyone else sees them, and the person who added one gets an email when it is accepted.

There were smaller ones: three drop-downs for job level, area and base instead of a free-text job title; a tick box to share a closing comment anonymously; a Dictate button so you can talk your comments in; a "Skip for now" that parks a product on your stack for later; team size at sign-up; and an invite that only goes to colleagues on your own company’s email domain, so the invite button can’t be used to email strangers in the Council’s name.

Then I asked the AI to attack it.
On 29 October, and again on 1 November, I ran a security audit: 120 numbered checks across the code, the database, the live site, sign-in, email and the admin pages. The two passes produced 22 separate fixes between them. Administrators now need two-step sign-in, enforced in the database as well as the site. Review text and scores are not readable through the public data interface at all this year. Rate-limit records are hashed. Preview deployments were switched off because they would have run against the live database with the live secrets. Passwords went to 12 characters. Every response now carries a content security policy.

Some of what the audit found was embarrassing. It was useful too. Two database changes from that weekend turned out never to have been applied to the live database at all. I found that on 12 November, six days before launch, during a final pass. The code assumed protections that were not there. Now the working notes say, in capital letters, to check the migrations screen after every merge.

I tested it with 1,000 fake operators before any real one.
On 10 November I ran a load test: 500 full survey submissions, twice, on the smallest and a medium database size. Both completed 500 of 500 at a steady 1.1 submissions a second. The limit turned out to be the number of calls the database’s API layer will take each second, not the database itself. Each submission was making about 44 calls. By 12 November that was down to the mid-twenties, which should roughly double what the site can take on launch day.

The limits got the same treatment. A launch event on shared Wi-Fi would have hit a cap of 20 sign-ups an hour per connection, so it is now 300. The site-wide cap went from 300 to 1,500 an hour. Confirmation links last 24 hours instead of one, and there is a button to get a new one. The fake operators also found a bug where a half-saved submission could be left behind. That was fixed the same morning.

What it adds up to.
I keep hearing that AI builds a site in an afternoon. Here is what the log actually says.

Between 19 October and 12 November there were 200 commits in 61 reviewed pull requests across 12 working days. By commit times, that is about 42 hours of build sessions, which is my time in the chair with Claude. Twelve of those hours were on 12 November alone, 56 commits in a day. The summer weekend on the first version and the research before it are not in that number. Finally, On 13 November I gave what was left, a new sharper design style, using the new Fable 5.2.

The code base is about 35,000 lines of TypeScript, 11,000 of them added since 19 October, and 72 database migrations running to just under 5,000 lines of SQL. Over the whole history Claude wrote and rewrote about 163,000 lines to get there. There are 56 pages on the site, 20 of them admin screens, 13 email templates, and 32 test files. The working notes that tell the next person (or the next AI session) how it all fits together run to 11,000 words, which is longer than this piece by some distance.

The running costs are a domain name, a database plan and an email plan. In October I logged 50 hours in Claude across everything I’m building. This was the biggest of them, and the one that most often had me context-switching between five things with the brain fog to prove it.

Now the independence question

You might wonder whether someone who co-founded Airship and Toggle, sold them to Zonal, and sits on the boards of three of the suppliers in the survey, should be anywhere near an independent supplier survey. It’s a fair question, and I asked it of myself on 4 November, in a call with Tom.

I’ve lived hospitality my whole life, first as an operator and then as a tech supplier, and I care what happens in the sector. I want to keep working on this because there are real problems to solve, and I believe I can help. I’d like to see operators and suppliers working more closely together, especially around transparency on the flow of data, integrations and a more common data model. I think this is the start.

Here is where we landed. The code enforces that nothing can be bought: no supplier can edit a score, respond to a review this year, or see who said what. There’s a full recorded audit log. An address at a supplier’s domain cannot rate that supplier’s own products, and anything else it rates is held for a human. I will build the dashboards that show the results and evolve the platform into something that benefits the sector, and the Council is working with the Department for Business and Trade who will have access and oversight. Operators, and suppliers, will have to decide for themselves whether that is enough.

The survey opens on 16 November at hscsurvey.org. If you run a hospitality business and use any of these tools, please fill it in, and tell your team to.

What I’d tell anyone about building with AI

Three things.

Build the plain version first. The thing you are proudest of is usually the thing to cut.

Treat the keys and the dashboards as the job. The code will be fine. The leaked key, the migration that never ran and the deployment with the wrong name were all mine, and none of them were typing.

Let real people use it before you believe it works. The working group found more in a week than I found in a month.

This piece was written with my writing skill, and its structure is modelled on Bill Gates’s essays (which I have as a skill in Claude), because I think they get it right. Every number in it comes from the project’s own history, database and meeting notes.