DEV Community: iloblique

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

iloblique — Fri, 13 Nov 2026 05:01:51 +0000

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 &amp;&amp; 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 &amp;&amp;)
  where (status &lt;&gt; '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

OpenAI Academy, Codex: how to start — https://openai.com/academy/codex-how-to-start
OpenAI skills catalog (curated) — https://github.com/openai/skills/tree/main/skills/.curated
Lovable, TrimSync barbershop booking template — https://lovable.dev/templates/websites/services/trimsync-premium-barbershop-booking-template
Lovable pricing — https://lovable.dev/pricing
Supabase pricing — https://supabase.com/pricing
Meta, WhatsApp Business Platform pricing — https://developers.facebook.com/docs/whatsapp/pricing
Veracode, 2025 GenAI Code Security Report — https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/
SusVibes, arXiv 2512.03262 — https://arxiv.org/html/2512.03262v2
Escape.tech, vulnerabilities in vibe-coded apps — https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/
CVE-2025-48757 write-up, Superblocks — https://www.superblocks.com/blog/lovable-rls-breach

Originally published at iloblique.com.

Claude Sonnet 4.5 retires on November 30. The migration is not one line

iloblique — Wed, 11 Nov 2026 05:01:40 +0000

On November 30, 2026, Anthropic retires claude-sonnet-4-5-20250929 from the Claude API. After that date, requests to it fail. They do not slow down or fall back to something close. They return an error. As of November 9, that is 21 days away. The same day, fast mode for Claude Opus 4.8 is removed, and that ends in an error too.

2026-09-30  claude-sonnet-4-5-20250929 marked Deprecated     (notice: 61 days)
2026-10-21  API version where temperature / top_p / top_k -> 400
2026-10-30  release notes: fast mode for Claude Opus 4.8 deprecated
2026-11-30  claude-sonnet-4-5-20250929 retired           -> requests fail
2026-11-30  claude-opus-4-8 with speed: "fast" removed    -> requests return an error

Anthropic's named replacement for Sonnet 4.5 is claude-sonnet-5-5. The obvious fix is to change one string. It may not be enough. The deprecations page notes that since API version 2026-10-21 the sampling parameters temperature, top_p and top_k return a 400. Code that was tuned with those parameters can fail even with the right model name.

So the work before November 30 has three steps: find every place the old identifier still runs, fix the request, and rerun your own cases before you switch traffic.

In our view, this hits one founder hardest: the one whose AI feature was built by a contractor who has since moved on. The model name can sit in code nobody on the team has opened in a year.

Step 1: find where the old model still runs

Start from usage, not from the code. Code tells you what could call the model. Usage tells you what actually does.

Anthropic's deprecations page points to Claude Console → Usage → Export. The CSV breaks usage down by API key and by model. It shows which keys still send traffic to the retiring identifier, and a key can map to a service, an environment or a person.

Claude Console -> Usage -> Export (CSV)

filter:   model = claude-sonnet-4-5-20250929
group by: API key
-> one row per key still calling the old model
-> for each key: which service, who owns it, who can deploy it

Then search the code and config behind those keys. Search beyond the main repository too: env files, a config table, a no-code automation, a function someone deployed by hand.

grep -rn "claude-sonnet-4-5" .
grep -rn "claude-opus-4-8" .
grep -rn "speed" .                      # speed: "fast" on Opus 4.8
grep -rnE "temperature|top_p|top_k" .

Our opinion: a key with traffic and no owner is the real finding of this step. It is the part of the product nobody is responsible for.

Step 2: fix the request, not just the name

A one-line migration looks like this:

- "model": "claude-sonnet-4-5-20250929",
+ "model": "claude-sonnet-5-5",

What the deprecations page warns about is the rest of the request body. If the integration sets sampling parameters, those lines return a 400 from API version 2026-10-21 on. An illustration:

  {
    "model": "claude-sonnet-5-5",
-   "temperature": 0.2,
-   "top_p": 0.9,
    "max_tokens": 1024,
    "messages": [...]
  }

Deleting the lines is the easy part. The harder part is that they were there for a reason. A low temperature may have been how someone kept a classifier stable or a JSON extractor from drifting. Take the setting away and the behavior it bought has to come from somewhere else: the prompt, a schema, a validation step after the call. That is a code change and a design decision, not a find-and-replace.

Fast mode is the same kind of change. Per the release notes of October 30, after November 30 requests to claude-opus-4-8 with speed: "fast" return an error. Any call that sends it needs an edit, and that edit goes through step 3 like the rest.

Step 3: rerun your own cases before the switch

A new model passing a demo proves little. What matters is whether it handles your inputs the way the old one did, including the ordinary ones nobody thinks to test.

A team described exactly this in an r/AI_Agents thread on October 2, 2026. They changed only a prompt. The change passed the cases they had tuned it on. On a set it had not seen, it wrongly blocked 17 of 30 ordinary requests. They now ship any model or prompt change as its own version. A commenter in the same thread named the buyer's fear: not wanting every model release to turn into a testing project for their team.

That fear is fair. Our answer is a small, boring harness that exists before the next release, not after it:

cases/
  tuned/     # inputs the prompt was written against
  holdout/   # real, ordinary inputs it never saw
  edge/      # cases that once broke production

for model in [current, candidate]:
    for case in tuned + holdout + edge:
        out = call(model, case.input)      # same prompt, same code path
        record(model, case.id, check(out, case.expected))

compare pass rate per folder, per model
ship only if holdout does not get worse

The holdout folder is the point. Tuned cases tell you the prompt still fits what it was aimed at. Holdout cases tell you whether it still behaves on Tuesday's traffic.

Run the current model through it now, while it still answers. After November 30 there is no baseline to compare against.

What the steps leave out

Our recommended order, not Anthropic's. Two things the steps above do not say:

migrate on a branch, not in place    -> the old path stays runnable until the switch
keep the harness after November 30   -> the next notice starts from a baseline, not from zero

We do not expect this to be the last retirement. In our view, a team that keeps the harness turns the next deprecation notice into routine work.

What would change our mind: if your integration sets no sampling parameters and does not use fast mode, step 2 shrinks to the one-line diff. Steps 1 and 3 stay.

FAQ

Is the 400 tied to the new model or to the API version?
The deprecations page ties it to API version 2026-10-21, not to a model name. Our reading: test the full request body on the API version your client actually sends, not only the new model string.

Does this touch Claude Opus 4.8 without fast mode?
The October 30 release notes describe the removal of fast mode: requests to claude-opus-4-8 with speed: "fast" return an error after November 30. That entry announces nothing beyond fast mode.

How many test cases do we need?
There is no official number. Our view: start with the inputs the prompt was tuned on, a holdout set of real ordinary requests, and every case that has broken production before. The holdout set is the one that catches what the team in the thread above missed.

A related case

The same discipline runs through Holt, our language-learning product. No model output reaches a learner unvalidated, and generated material is judged against blind golden sets by a model with no hand in it: 96.7% pass and 0.0% substantive defects on the wave of August 19, 2026. That is the harness from step 3, kept running. The case is at iloblique.com/holt.

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

Sources

Anthropic, Model deprecations, Claude API docs (checked November 9, 2026): https://platform.claude.com/docs/en/about-claude/model-deprecations
Anthropic, Claude API release notes, entry of October 30, 2026: https://platform.claude.com/docs/en/release-notes/overview
A thread in r/AI_Agents, October 2, 2026, paraphrased in our words

Originally published at iloblique.com.