← Writing

12 November 2026

I built a tool with AI in 27 hours. Here is every step.

How I built a free Site Visibility Checker for hospitality with Claude Code: the research first, then 96 messages, 27 reviewed changes, tests on 15 real venue sites and a security audit. With the real numbers for time and tokens.

Site Visibility Checker

It took 96 messages from me, 27 rounds of reviews & security audits. 27 hours from start to finish, and 6.5 hours of my actual time. The typing and voice dictation was the easy part.

In this age of Agentic Engineering (previously called vibe coding) you can build pretty much anything, it’s a real leveler, the only limitation is your imagination.

So this week I built a free tool for hospitality operators called the Site Visibility Checker. You give it your venue’s web address and it tells you how your site looks to Google and to AI assistants, how easy it is to book, and how well it collects guest details. As with everything right now, I built it with Claude as an experiment, to test and improve my skills, but it’s a handy little tool...

You can try it here: https://danbrookman.co.uk/resources/join/ (pop in your email to access)

Here’s how I went about it.

##1. The idea: AI is changing the way that consumers interact with the world, my focus is hospitality, and I’m incredibly interested in the AI PA’s and the new way that people are booking. So I dictated a long message to Claude. I folded into this my specialism around data collection and also a focus on larger party booking.

##2. I ran a /Deep-Research skill to find the best information out there on the topic using multiple agents to give me an output to then test against. Here’s what it found:

Three findings shaped everything that followed.

Your own website is a minority source. One study ran 60,970 checks across 1,355 locations and found that in most AI answers about local hospitality, the venue’s own site is not where the answer comes from. Your Google listing matters more than most operators think.

The demand is real. A survey of more than 5,000 British consumers found 19 per cent already use AI tools to plan pub, bar or restaurant visits. It’s 34 per cent of Gen Z and 39 per cent of Londoners.

Some popular advice doesn’t hold up. Structured data is widely sold as the way into AI answers. The best controlled test I could find showed it barely moved the needle.

That last one changed how I built the tool. Every finding in a report carries a label saying what it rests on: official guidance, UK law, a large study, an industry survey, or just expert opinion. If it’s asking you to spend budget with your web team, it has to be accurate.

The research became a requirements document, and that document went through several versions before any building started.

##3. I then ran a PRD (product requirements document) This takes some time as it’s a question and answer approach to get to the outcome.

##4. I then reviewed the PRD (again this takes a little time)

##5. Next was the build: This is a conversation broken down into tasks

Each one followed the same loop. Claude built it on its own branch. It told me what it had checked and, just as usefully, what it had not. I said "merge" or I said what was wrong. Then the next one.

Database changes had a stricter rule. Claude wrote the change as a file but was never allowed to apply it alone. Each time it walked me through what the change did in plain English, did a read-only look at the live database first, and waited for me to say yes. Six database changes went in that way.

I have a setting turned on called ’insight’ so at the end of each change it tells me what it’s doing and why, it really helps me build knowledge of the nuts and bolts...

The slow parts were not the AI: You might be wondering where the hours went, if the code comes that fast. It’s a good question. They went on three things.

Accounts and keys. The tool needs a key from Anthropic and a key from Google for three services: page speed, real-user speed data, and business listings. The Google part was fiddly and my brain struggles with the use of ’keys’ everywhere (I’m getting better at it)

Things that only show up when a real person tries them. Nailing the user journey from the get go is something that I need to work on, we went through a few iterations of how this would work in tandem to those users on my Claude Coaching course as they already have access to this without having to register again. It’s complex stuff though, and I’m a team of one.

Plumbing. A deploy job sat in a queue and refused to be cancelled. A preview build never appeared. A login token stopped working on the last change of the night. It’s complex to figure out some of this stuff the first time. And it all takes time.

##6. Testing: The first real check ran on a Sheffield pub. It took 25 seconds and cost about 19p.

Then I gave Claude 15 real venue websites and asked it to compare what the tool reported with what was actually on each page. This was the most valuable hour of the whole build, because the tool was wrong in seven different ways.

It mistook "Group Bookings" pages for the main booking page. It missed a booking system that was plainly there. It reported no book button on a site where the button simply wasn’t built as a normal link. And it read one well-known bar group’s name off its website as "UK".

Everything was fixed and retested.

Real sites also changed the product. Four of the fifteen used a booking system the tool could see but couldn’t name. So the form gained an optional question: which booking system do you use? You can answer a question that can save the AI time (and tokens).

##7. Security Audit: Before telling anyone about it, I asked for a security audit: 120 checks across the code, the database, the live site, sign-in, email and admin access. Claude ran three reviewers in parallel and checked the live database itself.

We fixed the holes and retested.

##Here’s the stats##

  • From the first message to live was 27 hours
  • Claude sent 865 replies and took 803 actions
  • I sent 96 messages
  • 27 separate changes went live
  • Claude used 786k of tokens, the code, the tests, the explanations and the database changes.
  • 600k of words generated.
  • My ’actual time’ was 6.5 hours.

The running cost is small by comparison. A check costs about 20p, and I’ve capped the tool’s spend at £50 a month. If it hits that, it pauses until the next month (or I up the budget)

My advice to you

Could you build something like this? I think so, with three conditions.

Do the research and write down what you want first. Check everything on real examples, because that’s where it can be wrong. And expect the hours to go on keys, accounts and testing, not on the code.

AI didn’t remove the work. it did the build and guidance. I spent my time deciding, checking and refining.

The checker is free and it’s early. Run it on your own site, and tell me where it’s wrong.

This blog was written using my writing skill and one that I took built from analysing Bill Gates Notes (as I really like the structure). I then edit the final output.

The bar at the top of the page indicates the Dan/AI split. (another little experiment)

← Back to writing