How to build an appointment booking system with OpenAI Codex

Rule of thumb: if several people work a rota, money changes hands at booking time, and you would rather never think about a reminder or a time zone again, rent. Those are real products and none of them is a weekend of describing. If the shape of your problem is that your own site should show what you offer, at your prices, with your rules about cancelling, and you would like the bill to stop growing every time you get busier, that is the half worth owning. Two findings worth weighing whichever way you go. In an MGMA poll of 622 medical groups published in January 2025, 42% charged a no-show fee, and those that did reported more improvement in their no-show rates over the year than those that did not, 25% against 16%. And in a second MGMA poll, published in July 2025 with 244 responses, 71% of practices had fewer than a quarter of their patients self-scheduling at all. Offering online booking and having it used are two different projects, and the second one is mostly about telling people it exists.

* The free-tier line that matters here is the pause, not a storage number. Free gives you a 500 MB database, 1 GB of file storage, and 5 GB of egress a month, and bookings and services are small enough that only the photographs of what you offer will ever push at those. The pause is different: a free project stops after a week with no activity, and a booking page that has gone to sleep is a business that looks closed, which lands squarely in the week after launch, before anybody has found you. From $25/mo, Pro removes the pause, raises egress to 250 GB (then $0.09 per GB), and keeps a daily backup for 7 days.

The two meters a rented scheduler runs are the ones missing from this table. One charges for every person whose diary can be booked, the other for every appointment that gets taken, and both grow as the business does. Neither column above has either, so your busiest month costs exactly what your quietest one does, and the only line that moves is whichever AI model you decide to call. That shape suits a business whose bookings are going up, which is the only kind of business anybody is trying to build.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   AGENTS.md first, before a single file is scaffolded

   Codex opens that file at the beginning of every task, so writing it now puts the two constraints this build depends on into memory before any code exists that could contradict them.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is an appointment booking system. Fix the vocabulary (service, duration, opening hours, slot, availability, booking, hold, guest, review) and record two standing constraints. First: whether a slot is free is derived on the server from the opening hours and the existing bookings, and re-derived inside the write that creates a booking, never taken from the client. Second: every list of another person’s appointments is narrowed in the database rather than in a component, and a guest reaching their own booking goes through a server-side token check rather than a policy that opens the table. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The re-derive-inside-the-write rule is the one worth writing down rather than saying. Trusting a slot the browser has already been shown is a reasonable-looking thing for any assistant to write when the booking form clearly knows the answer, and it is exactly how two customers end up with the same appointment.

2. 02

   One task for the schema, one for the shop window

   Nothing depends on either yet, so both are cheap to get wrong and cheap to throw away. Run them back to back and you have a clickable catalog, which is what tells you whether your service list makes sense to somebody who has not seen it before.

   PromptModel the catalog and build the public pagesCopy

   Two tasks. First, the data model as Supabase migrations, with no authentication in this task: services with a title, description, category, price, one or more durations in minutes, an image, and optional opening hours of their own. A settings table holds my default weekly opening hours, the slot length, the hold length in minutes, my currency, and my cancellation policy as text. Show me the SQL before you run it, then seed eight services across three categories with deliberately mixed lengths (a 30-minute one, a 90-minute one, and one offered on two days a week only) plus opening hours with one day closed. Second task, the public reading side: a landing page, a catalog with category filters, and a service page carrying photos, price, duration, and a slot where reviews will appear. Nothing signs in and no bookings exist yet.

   Read the settings table’s shape in that first diff before you approve it. Whether opening hours live per service, per business, or both is the decision the whole availability task is written against, and changing your mind about it later means changing every query that reads them.

3. 03

   Give availability its own task, and read the query it writes

   The task that decides whether this application is safe to point customers at. Ask for the SQL and the function before either runs, and judge it on the slots it removes rather than the ones it shows.

   PromptWork out availability properlyCopy

   One task, availability. Build it as a server-side function taking service ids, a date range, and the duration the customer picked, returning only genuinely free slots. For each day: take that service’s own opening hours where it has them and my defaults otherwise, cut the day into slots of the requested duration, then remove any slot in the past, any overlapping a booking with status confirmed or pending, and any overlapping a hold that has not yet expired. Every appointment is stored as an absolute moment. Show me the function and any SQL it depends on before you run them, and be explicit about how you are comparing an appointment’s start and end against a slot’s. I want to read the overlap condition rather than infer it. Then build the picker over it, and print the working for one specific Tuesday: which slots each rule removed, and why.

   Read the overlap condition character by character. An off-by-one there (a slot that ends exactly when a booking starts, treated as a clash, or the reverse) is invisible on a quiet calendar and shows up as either a day that looks fully booked or a 90-minute service laid over the top of a 30-minute one.

4. 04

   One task for the booking, with the hold and the guest path in it

   The first thing here that writes anything, and the two halves that only make sense together: a slot taken out of circulation while somebody finishes, and a customer with no account who still has to find their way back.

   PromptTake the booking, with a hold behind itCopy

   One task, the booking side. A booking records the services and durations chosen, its absolute start, a status of pending, confirmed, completed, or cancelled, its customer or a guest name and email, notes, and a hold expiry. Choosing a slot writes a pending booking whose hold expires after the hold minutes in my settings, which takes the slot out of availability at once. Confirming flips it to confirmed and clears the hold. Inside that write, re-derive availability and refuse the booking if it changed while the customer was typing, a plain message about the slot having gone, not an error. Add a cart so several services become one appointment long enough for the total. For guests: a name and an email, a long random token with an expiry generated server-side, and a lookup requiring the token, the email, and the booking id together. Flag in the diff anywhere you have relied on a value the client sent about availability. Those are the lines I want to read first.

   That closing instruction is the review. Codex has no policies to lean on yet at this point, so the natural code here trusts the page more than it should, and asking for those spots marked gives you a short list to read instead of a diff to search.

5. 05

   Tighten the permission boundary, then add the roles

   Sign-in, and the rules standing between a diary of names, numbers, and addresses and everybody who has no business reading it. This is a task to run Codex on a shorter leash than you would for an ordinary edit.

   PromptAdd auth, roles, and access rulesCopy

   Narrow your permissions for this task before starting it. Everything here touches authentication. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, a profile row per account, and a useUser hook. Add a role enum of 'customer' and 'admin' in a user_roles table kept off the account record, since anything stored there is editable by its owner, plus a SECURITY DEFINER has_role function. Then row-level security on every table: an anonymous visitor reads services, the settings the page needs, and approved reviews, and nothing more. A customer reads and cancels only their own bookings. An admin reaches everything. A guest reaches their own booking only through the server-side token lookup, so no policy opens the bookings table to anonymous reads. Explicit WITH CHECK on every insert and update, a review permitted only where a completed booking for that service belongs to that customer, and the service-images bucket public to read and admin-only to write. Show me the policies as SQL before they run, then walk me through proving four things as a signed-in user: one customer cannot read another’s booking, an anonymous request cannot list bookings, a guest lookup with a wrong token returns nothing, and a review with no matching booking is refused.

   Ask Codex which tables and which roles it actually covered, then check that list against your own schema rather than assuming it came out complete. The table that gets forgotten here is rarely bookings. It is the cart, or the notifications, both of which carry a customer’s name next to what they were about to buy.

6. 06
   Destination

   Send the back office to a cloud run, then work a day yourself

   The admin screens and the dashboard are tightly specified and depend on nothing outside themselves, which makes them fair to hand off and walk away from. The day at the end is the opposite kind of work, and it catches what reading a diff never will.

   PromptAdd the back office, the sweep, and rehearseCopy

   Two pieces, each contained enough to run unsupervised. First, the back office: a schedule by day and week, bookings I can add and cancel from it myself, a bookings manager filtered by status and service, a reschedule that moves an appointment and keeps its history, a cancellation window read from my settings, a service editor with photo upload and per-service opening hours, a settings screen, review moderation, in-app notifications on a new or moved booking, and a dashboard charting bookings and value booked by service. Second, the scheduled sweep: cancel pending bookings whose hold has expired, authenticate it with a shared secret rather than a session, make it safe to run twice, and tell me where the schedule lives given the app deploys as static files. When both are merged, work a full day yourself: book as a stranger, abandon a second booking and watch the slot return after the sweep runs, follow a guest link back to a booking, reschedule as a customer, try to cancel too late, add a walk-in from the schedule, moderate a review, and confirm the dashboard agrees, then fix what does not hold up.

   Should you send the first half off to a cloud run, read the sweep’s diff before it merges. A job that cancels rows on a timer is the one piece of this build nobody is watching when it runs, and the difference between cancelling expired holds and cancelling pending bookings is one clause and a very bad afternoon.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks the rest here: the database service key, any AI provider key, and the secret guarding your scheduled sweep live on the server and nowhere else: not in the app a customer downloads, and not in a public repository. Treat any of the three that escapes as burned, and replace it the same day.

Any of them serves the app perfectly well, so judge them on three questions instead of on speed. Whether the plan allows commercial use, since Vercel’s Hobby tier does not and taking paid bookings is commercial by any reading. Whether it publishes from a private repository, because this code sits beside a diary of where your customers are going to be. And whether a deep link resolves in a browser that has never seen your site: a link to one service, and the link a guest follows back to their own booking, both have to land on the right page rather than the home page.

Add a server-side ai function (one place, with my provider key only on it) and a screen where I paste a message from a customer. Send the message to that function and get back a structured guess: which of my services they seem to want, roughly when they are asking for, and the name and contact detail if the message contains one. Then match that guess against real availability and show me the three closest free slots as a draft booking I confirm or discard. Never write a booking directly from the model’s output, and where the message is ambiguous say so rather than choosing for me. If it says “sometime next week” I want to see that, not a Tuesday you picked.

When a booking is cancelled, build me a shortlist for the freed slot: customers who asked for that service, whose earlier bookings suggest they are around at that time of day, who have not already got an appointment that week, and who have not asked me to stop contacting them. Send only what my ai function needs to rank them and nothing else: no contact details in the prompt. Show me the list with a one-line reason each, and let me pick who gets the message. Nothing goes out automatically, and anybody who has opted out is filtered before the model sees them.

Add a “draft a reply” action on a booking that sends the booking, its history, and my cancellation policy text to my ai function and returns a short, warm reply I can edit before it goes anywhere. Rules: it may only state what my policy actually says (if the policy is silent on something, the draft says it will check rather than inventing a rule), it never offers a slot without checking availability first, and it never promises a refund or a waived fee, because this application does not take payment and I am the one who decides that.

Add a panel on the admin dashboard that groups the last period’s reviews by what they are actually about, using my ai function, and returns each theme with a count, one representative quote, and which service and which day of the week it concentrates on. Send the review text with customer names removed. State counts as figures rather than describing them vaguely, print the period it covered beside the result, and where a theme rests on one or two reviews say so instead of presenting it as a trend.

Add a panel that answers questions about my own booking history through my ai function: no-show and cancellation rates by service, by day of the week, by time of day, and by how far ahead the booking was made, plus how many holds expired without becoming bookings. Have it compute the figures with queries and use the model only to explain what they suggest, so no number is invented. Every answer states the period and the sample size, and where a pattern is thin it says the pattern is thin. Send no customer names or contact details at all.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.