Skip to content

A booking CRM in one prompt: what you actually get, and what the subscription was paying for

One prompt gets you a booking form and a table, published online. A booking service is what sits underneath: no double bookings, verified and paid messaging, payment and personal-data rules, access control, and someone who fixes it when it breaks.

A booking form with a table behind it is now one prompt away. A booking service is not, and the gap between the two is what a salon or clinic pays a subscription for. That is the answer. The rest of this piece is the proof.

Over the past month several videos have made the same promise in different words: drop your booking subscription and have AI build your own CRM with client booking, in one prompt, in minutes, for free. On 6 November we checked that promise against vendor documentation, pricing pages and published security audits. Here is the strongest version of it, then what the screen leaves out.

The strongest version of the claim

Part of it is true, and we will say so first.

OpenAI's guide says a Codex project is tied to a folder on your computer, and an empty folder works as the place where Codex creates a new project. OpenAI's curated skills catalog includes vercel-deploy and netlify-deploy, so "now put it online" is a supported request. Since July 2026 ChatGPT Sites can publish a site too. Lovable sells a barbershop booking template.

So an empty folder, one prompt and a public URL is real. If the question is "can I put a working booking prototype online", the answer is yes, and it is a good way to start.

The claim goes further than that. It says the result replaces the service. That part does not hold.

What is not on the screen

In the demos we reviewed, the screen shows the client-side form: pick a service, a date, leave a contact. That is the top layer of a booking product. Five things sit under it.

1. Two people, one slot. A prototype that checks availability and then inserts a row has no transactional protection for the slot. Sooner or later it gives the same 3 p.m. to two clients who pressed the button in the same second. The fix doesn't go in the interface. It is a guarantee in the database.

-- the check a prototype does (in the browser or the API):
select count(*) from bookings
 where staff_id = $1 and slot && tstzrange($2, $3);
-- returns 0 for both clients, both inserts succeed

-- the guarantee: the database refuses an overlap, whoever arrives second
create extension if not exists btree_gist;
alter table bookings
  add constraint no_double_booking
  exclude using gist (staff_id with =, slot with &&)
  where (status <> 'cancelled');

2. Messages that actually arrive. Reminders are what clients notice. WhatsApp reminders go through the WhatsApp Business API, which needs a verified business, a provider's monthly fee and Meta's own message charges on top. Grey bulk sending from an ordinary number gets the number blocked. SMS needs a paid gateway. None of that is code a prompt can write. It is accounts, verification and a monthly bill.

3. Money and personal data. Once you take prepayment or store client phone numbers, law applies to you. In Russia, for example, online prepayment needs an online cash register issuing fiscal receipts under 54-FZ, connected to a fiscal data operator, and client records fall under 152-FZ on personal data. Elsewhere, check your own country's rules; we are not lawyers. Either way, someone has to answer a request about a client's data, and a one-prompt prototype has no one to do it.

4. Who can see what. A booking table holds names and phone numbers. A prototype built from one prompt has no server-side authorization and no roles. The documented case is CVE-2025-48757: apps generated on Lovable shipped with Supabase row-level security switched off, so their data could be read without authorization. Audits also found keys left in client code. The rule that closes it is short. Writing it is easy. Remembering it is the hard part.

alter table bookings enable row level security;

-- a client sees only their own booking; staff see their own day
create policy client_reads_own on bookings
  for select using (client_id = auth.uid());
create policy staff_reads_own_day on bookings
  for select using (staff_id = auth.uid());
-- no insert policy for anon: public bookings go through one narrow function

5. Who fixes it. Running the system by chatting with the model works until the first conflict in the data. Then someone has to know where the truth lives, at 2 a.m. if that is when it breaks. That person is part of what the subscription pays for.

"Free" has a ceiling

The free tiers are real and fine for a prototype. Here is where they stop, and what starts billing once the prototype becomes a service:

Free, for the prototype
  Lovable free plan   5 credits a day, no more than 30 a month
  Supabase free tier  database up to 500 MB

Paid, once it is a service
  WhatsApp            verified Business API account + Meta message charges
  SMS                 paid gateway
  Prepayment (RU)     online cash register under 54-FZ + fiscal data operator

What the audits say about generated code

These aren't our numbers. Across the 2025–2026 audits we read, 45–55% of AI-generated code fails basic OWASP security tests. The audits are Veracode's 2025 GenAI Code Security Report, the SusVibes benchmark (arXiv 2512.03262), built on feature tasks from real open-source repositories, and Escape.tech's scan of public apps built on vibe-coding platforms.

None of these says AI code is unusable. Our reading, and it is ours: it works on the screen and fails where nobody looked.

How we build it

We built a clinic booking system under NDA, so no name here. The brief was a folder of Instagram videos and screenshots. Double booking is stopped by a database exclusion constraint plus a transactional booking function. Role access is enforced twice, in application logic and in row-level security, so a bug in one layer doesn't leak data. Every public write goes through a narrow single-purpose function. Doctors see their day in Google, Apple or Outlook through a private calendar feed.

The repository carries 13 ordered migrations, unit, integration and end-to-end suites, an hourly reminder job and a six-document handover kit. The form was the smallest part of it.

Our view: build the prototype first. It is the cheapest way to find out what your booking flow actually needs. Then, with that list in hand, decide whether to build the rest or keep paying someone who already did.

What would change our mind

If a one-prompt build passes a concurrent-booking test (two clients, one slot, the same second) and arrives with access rules and verified messaging in place with no extra work, this piece is wrong. We would take it down and say so here, at the same length.

FAQ

So is the one-prompt promise wrong? Half of it. The prototype is real: an agent creates it in an empty folder and publishes it, and the free tiers carry a test with real clients. The "replaces the service" half is the part that fails. In our reading, generated code tends to skip what nobody asked for, so check access rules and keys by hand, every time.

What breaks first when a prototype goes live? In our experience, the slot. Two clients book the same time, or a reminder never arrives because the messaging account was never verified. Neither shows up in a demo with one user.

When does building your own booking system make sense? Our view: when booking is part of what you sell, not just how clients reach you. Think a portal with patient records, doctor schedules and content your staff edit themselves. If you only need a calendar and reminders, a subscription is usually the cheaper engineering.

Related case

The same rule runs through RE Intelligence, our analytics of the Dubai real-estate market: the guarantees live in the database. Every number comes from a deterministic query, and the model only narrates what the data already proved. Read the case at iloblique.com/re-intelligence. The short version of this piece is on LinkedIn.

If you have something worth building, we'd like to hear about it.

Sources