How to build an appointment booking system with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Sketch the catalog and the picker, because that is what v0 leads with

   The whole public side with invented services and invented times, in one chat. The point is to look at how somebody gets from a service to a time before anything is stored anywhere.

   PromptSketch the booking screensCopy

   Build the public screens for an appointment booking system in Next.js, using placeholder content for now. A landing page. A catalog of services with category filters, each card showing a price and a length. A service page with photos, the description, and a reviews section. A booking screen with a date picker beside a list of times for that date, then a details form and a confirmation page. A simple “my bookings” page. Include one 30-minute service and one 90-minute one so I can see how differently their times lay out, and show me the empty state for a day with nothing free. Keep it responsive. Most people will book this from a phone.

   Use Design mode for the visual corrections rather than describing them. On a booking page the tap targets on the time list and how the picker reads on a phone are most of the product, and those are exactly what Design mode is for.

2. 02

   Connect the database and let the catalog read real services

   Where the hand-off happens. Add the integration from the project menu, then ask for the schema and the routes that will retire the placeholders you just looked at.

   PromptModel the catalog and connect the databaseCopy

   A Supabase integration is now connected to this project. Design the schema and the routes that read it, then take the placeholder content out of the screens you already built. 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. Seed eight services across three categories with mixed lengths (one 30-minute, one 90-minute, one offered on two days a week only) and opening hours with one day closed. Write server-side routes for the catalog and a single service, and wire the existing pages to them. Nothing writes yet, and the times in the picker are still placeholders until the next chat.

   Get this done before another screen exists. From here on everything reads or writes a real row, and a picker designed against invented times has to be rebuilt the moment the real ones turn out to arrive in a different shape.

3. 03

   Ask for availability in the database, not in the route

   The step that decides whether the times on screen mean anything, and the one where a tool that leads with interfaces will happily hand you something that looks like availability and filters an array.

   PromptWork out availability properlyCopy

   Start a new chat for availability. Build it as a database function, not in JavaScript in the route: given service ids, a date range, and the duration the customer picked, it returns the slots that are genuinely free. For each day, take that service’s own opening hours where present and my defaults otherwise, cut the day into slots of the requested duration, then remove anything in the past, anything overlapping a booking with status confirmed or pending, and anything overlapping a hold that has not expired. Appointments are stored as absolute moments. Expose it through one server-side route the picker calls, and wire the real times into the screen from step 01. What I am asking you not to do is fetch bookings and filter them in the route or the component. The overlap logic belongs in the database, next to the rows it is comparing. Then show me the working for one specific Tuesday, listing which slots each rule removed and why.

   Say “in the database, not in the route” and then check the diff for it. Filtering a fetched array is the natural thing to write when the interface came first, and here it is worse than slow: the array you fetched is a snapshot, and the whole point of this function is to be right at the moment somebody presses the button.

4. 04

   The booking as its own chat: holds, guests, and the race

   The first part of this build that writes rather than reads. Give it a chat to itself, because at some point you will restore an earlier version here and you would rather the catalog did not travel back with it.

   PromptTake the booking, with a hold behind itCopy

   New chat for 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 held for the minutes set in my settings, which removes it from availability immediately. Confirming makes it confirmed and clears the hold. Inside that write, call the availability function again and refuse the booking if the slot has gone, returning a message rather than 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 on the server, and a lookup route requiring the token, the email, and the booking id together, never a booking id alone in a URL. Then demonstrate two requests confirming the same slot at the same moment, with one of them refused.

   The guest lookup is the one to be firm about. A URL carrying only a booking id is the default shape for this feature and it is a page anybody can walk through by changing a number, which on this app means somebody else’s name, phone number, and where they are going to be on Thursday.

5. 05

   Roles and access rules, in a separate chat and its own pull request

   Two kinds of account over the same tables, plus two kinds of visitor with none. Its own chat again, and its own reviewable diff.

   PromptAdd auth, roles, and access rulesCopy

   New chat, for authentication and access rules. Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Add two roles (customer and admin) in a separate table rather than on the account record, since anything stored there is editable by its owner, with a security definer function to check a role. Then row-level security on every table: an anonymous visitor reads services, the settings the page needs, and approved reviews only. A customer reads and cancels only their own bookings. An admin reaches everything. A guest reaches their own booking only through the token route, so no policy opens bookings to anonymous reads. Explicit with-check clauses on inserts and updates, 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. Then prove four things by querying 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.

   Give this its own pull request rather than stacking it on the booking work. Of every change in this build, the access rules are the one you will most want to read back as a single self-contained diff in six months, when somebody asks you what stops a customer seeing the rest of your diary.

6. 06
   Destination

   The back office, the sweep, then merge and deploy

   The admin screens, the job that clears abandoned holds, a full day worked through the app, and only then the merge that publishes it.

   PromptAdd the back office, the sweep, and rehearseCopy

   Last chat. The admin side: a schedule by day and week, bookings I can add and cancel from it, 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. Then the sweep: a job that cancels pending bookings whose hold has expired, authenticated by a shared secret rather than a session, safe to run twice, and tell me where that schedule has to live given this app deploys to Vercel, rather than assuming it can live in the app itself. Finally, walk a whole day with me: book as a stranger, abandon a booking and watch the slot come back once the sweep runs, follow a guest link, reschedule as a customer, try to cancel too late, add a walk-in from the schedule, moderate a review, and check the dashboard agrees.

   Ask where the schedule lives rather than assuming. It is the one piece of this build that is not a request from a browser, and the piece most likely to be quietly left out and noticed weeks later, when a Tuesday that looks fully booked turns out to be four holds from people who never came back.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.