Built on Y Build Build this app yourself — prompt to deployed, on your own domain. Start free
BuildShipCompareThe LabAbout Start building →
Build

Build a booking app with AI in 30 minutes

A real bookings app — auth, calendar, payments, reminders — built and deployed in half an hour. The full stack, the prompts, and the one part AI gets wrong.

Marcus TanFounding Engineer, Y Build
Published Jun 12, 2026
8 min
read
cover · 1200×600

We built a working bookings app — sign-in, a calendar of open slots, payments, and email reminders — start to finish in 30 minutes, and logged every step. Not a demo that stops at a pretty preview. A real one, on a real domain. Here’s the stack and the prompts.

The stack

You don’t need much, and AI builders wire most of it for you:

  • Supabase — Postgres database, plus Auth (email/password, magic links, and OAuth with Google or GitHub) and row-level security. This is the backbone.
  • Stripe — the payment step for a paid booking.
  • Resend — the confirmation and reminder emails.

Supabase is the piece that matters: it gives you a real database, real auth, and storage from one dashboard, which is why most AI builders integrate it directly.

The build, prompt by prompt

Roughly five prompts gets you there:

  1. Scaffold — “A bookings app. Email sign-in. A calendar showing open 30-minute slots.” You get a running app with auth in minutes.
  2. Data model — a slots table and an appointments table, with row-level security so a signed-in user only sees their own bookings.
  3. Payments — a Stripe checkout step before a slot is confirmed.
  4. Notifications — a Resend email on confirmation, and a reminder before the appointment.
  5. Admin — a page listing today’s bookings.

The part AI gets wrong

Here’s the bug AI builders ship by default, every time: double-booking. Naively, the generated code reads the open slots, then writes the booking — and if two people click the same slot at the same moment, both writes succeed. You’ve sold one slot twice.

The fix is to make the reservation a single database transaction with row-level locking — lock the slot row, check it’s still free, write the appointment, release. In Supabase that’s a Postgres transaction (a SELECT ... FOR UPDATE inside a function), not two separate queries from the client. AI will almost never reach for this unless you ask. So ask:

“Make the slot reservation a single Postgres transaction with row-level locking so two users can’t book the same slot.”

This is the difference between a demo and something you’d let a customer touch — and it’s exactly the kind of correctness-critical logic AI still needs a human to catch.

Ship it

A working app on a preview URL still isn’t a product. Point it at your domain — that’s a 10-minute job — and you’re live.

Bottom line

Thirty minutes is real, with one asterisk: the AI gets you 95% there fast, and the last 5% — concurrency, security rules, the edge cases money depends on — is where you earn your keep. Know where that 5% is and you ship something real, not a screenshot.

Liked this teardown?
Get the next experiment the day it drops. One email a week, raw numbers included.
Written by
Marcus Tan Founding Engineer, Y Build

Marcus has shipped 40+ production apps with AI tooling and runs the Build Lab experiments — the timed, reproducible head-to-heads behind every Compare and Lab note. Previously built developer platforms at two YC startups.

40+ apps shipped 8 yrs full-stack Author · The Lab
More from Marcus → @marcustan github ↗

Keep reading

All of The Lab →
Build your own app
Free · no card
Start free →