AI app builders can now make a booking site from one paragraph. A schedule, slot limits, a booking form and an owner page appear in about ten minutes. The preview looks finished.

Looking finished isn't the same as working for a real business, though. Below are the five checks I run on every AI-built booking app, including the ones we build ourselves. Each takes a couple of minutes, and you don't need to read any code.

1. Book from two different devices

This is the most common failure. Many AI builders make a frontend-only app that saves bookings in the visitor's browser (localStorage). In the preview it works perfectly: you book a slot and it shows up in the list.

Now book from your phone and look at the list on your laptop. If your phone's booking isn't there, every customer's booking is living on that customer's phone, and the owner's list will always be empty.

What to ask for: "a full-stack app with a database, so bookings from every device land in one list."

2. Try to take the last spot twice

Set a slot to 1 place. Open the booking page in two browser windows and book that slot in both at the same moment.

If both bookings succeed, the slot limit is only checked in the browser. Real customers will double-book you. The limit has to be enforced on the server, inside the same database transaction that saves the booking.

3. Open the owner page without signing in

Copy the URL of the owner or admin page and open it in a private window. Then try the API behind it, if you can see one in the browser's network tab.

A "hidden" link isn't a login. The owner side should refuse you, both the page and the data behind it, until you sign in with a real password.

4. Check what the customer keeps

After booking, does the customer get anything: a booking code, a ticket number, a confirmation they can show at the door? If they close the tab, can they find their booking again?

If not, you'll get "did my booking go through?" messages all day.

5. Change something without touching code

Ask the builder to add a new time slot, change a price or rename a service. Then run checks 1 to 3 again.

AI builders often fix one thing and quietly break another. A change that removes the database or the sign-in is a common way a working app stops working.

A real example, including what's still wrong

Here is one we built with NoCoder, the AI app builder I work on. It came from a single prompt:

I run a mobile knife sharpening van. I park at a different street stop each day of the week. Make a site where customers pick a stop and time slot, say how many knives (and if any are serrated or scissors), and get a pickup ticket number. I need an owner page showing the day's queue in order so I can tick knives off as done.

It's a Next.js app with Prisma and database-backed API routes. Each stop has slots with a capacity limit, customers get a ticket number, and the owner signs in to work through the queue. Signed-out and wrong-password requests to the owner side are refused. It passes checks 1, 3 and 4. We haven't run check 2 (the double booking) on this build yet.

It isn't perfect, and the gallery page lists what's still wrong:

  • switching stops can briefly show "van is not at this stop" until you pick the date again, because two requests race;
  • one panel says "Next show", a theatre word in a knife-sharpening app.

That's the point of the checklist. Whatever tool you use, don't take "done" as evidence. Run the five checks before a real customer does.

Disclosure: I'm on the NoCoder team. NoCoder's agent runs the build, sends a real request to the running app and clicks through it in its own browser before it says done. The checks above still apply to anything you build, with any tool.