How to build an appointment booking system with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   A repository first, then the rules, then Bolt

   Bolt has no upload button, so the project starts on GitHub. Once it is imported, the first message spends its tokens on the two constraints the whole build leans on.

   PromptSet up the projectCopy

   This project is imported from my GitHub repository. Set it up as a React 18 + Vite + TypeScript app with Tailwind and the Supabase JS client, reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from environment variables and never from the code, with .env in .gitignore. Add a typed Supabase client under src/lib. Then write a short notes file at the project root: the stack, the fact that this is an appointment booking system, the vocabulary we will use throughout (service, duration, opening hours, slot, availability, booking, hold, guest, review) and two standing rules. First: whether a slot is free is worked out on the server from my opening hours and existing bookings, and worked out again 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 rule that opens the table.

   Keep the notes file short and keep it accurate. Bolt reloads your whole project as context on every message, so a rules file is the cheapest thing in the repository, and a stale one is the most expensive, because it gets re-read on every turn whether or not it is still true.

2. 02

   The catalog, in one prompt, then look at it

   Services with a price and a length, your opening hours, and the public pages reading them. Nothing writes yet, which makes this the cheap moment to find out your categories do not match how customers ask.

   PromptModel the catalog and build the public pagesCopy

   Connect a database for this project, then design the schema and build the public side over it. 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, how many minutes a slot is held, my currency, and my cancellation policy as text. 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. Then the public pages: a landing page, a catalog with category filters showing each service’s price and length, and a service page with photos and a place for reviews. No accounts and no bookings in this prompt.

   Two lengths over the same day is not decoration in that seed data. It is what will later prove your availability is computing a grid rather than drawing one, and adding it now costs one clause in a prompt you are sending anyway.

3. 03

   Plan the availability calculation before Bolt writes it

   The step this application is made of, and the best possible use of Plan Mode: talk through the inputs and the order they apply in, agree it, then have it written once rather than three times.

   PromptWork out availability properlyCopy

   Use Plan Mode for this one before writing any code. I want availability as a server-side function, not logic in a screen: given service ids, a date range, and the duration the customer picked, it returns only genuinely free slots. For each day take that service’s own opening hours if it has them and my defaults otherwise, cut the day into slots of the requested duration, then remove anything in the past, anything overlapping a booking that is confirmed or pending, and anything overlapping a hold that has not expired. Appointments are stored as absolute moments. Talk me through the plan first, especially how you compare an appointment’s start and end against a slot’s, and once I agree it, write the function, expose it through one route, and build the picker over it with a clear empty state for a closed day. Then print the working for one specific Tuesday: which slots each rule removed, and why.

   Plan Mode is worth the extra turn here more than anywhere else in the build. Availability is the piece most likely to be rewritten twice, and on a tool that bills by tokens and reloads the project each message, agreeing the shape before any code exists is cheaper than correcting it afterwards.

4. 04

   The hold and the guest path, then clear the context

   The first prompts that write anything: a slot that leaves circulation while somebody types, and a customer with no account who still needs a safe way back to their booking.

   PromptTake the booking, with a hold behind itCopy

   Build 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. Picking a slot creates a pending booking held for the minutes in my settings, which removes it from availability at once. 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, with 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 requiring the token, the email, and the booking id together rather than a booking id in a URL. Then show me two sessions confirming the same slot at the same moment, with one refused.

   When this is working, clear Bolt’s context before you start the back office. The admin screens share almost nothing with the booking flow, and carrying the whole of one into the other is the main way a token budget disappears on this build without anything to show for it.

5. 05

   Sign-in and the rules, pointed at the tables that need them

   Two kinds of account and two kinds of visitor with none. Point this prompt at the schema rather than the whole project, and read what comes back before you accept it.

   PromptAdd auth, roles, and access rulesCopy

   Add email-and-password sign-up, login, logout, a persisted session, and a profile row per account. Add two roles (customer and admin) in their own 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: a visitor who is not signed in 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 server-side token check, so no rule opens the bookings table to anonymous reads. Explicit with-check clauses on inserts and updates, a review allowed only where a completed booking for that service belongs to that customer, and the service-images storage public to read and admin-only to write. Then prove four things: one customer cannot read another’s booking, a signed-out request cannot list bookings, a guest lookup with the wrong token returns nothing, and a review with no matching booking is refused.

   Point this at the migrations and the tables rather than letting it range over the whole project. Narrowing a prompt’s scope is Bolt’s own advice for keeping token use down, and it happens to make the diff on the most security-sensitive change in this build short enough to actually read.

6. 06
   Destination

   The back office, the sweep, a full day, then publish

   Your schedule, the editors, the numbers, and the job that clears abandoned holds, then a whole day worked through the running app before you publish it.

   PromptAdd the back office, the sweep, and rehearseCopy

   Finish the app. The admin side: 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 when a booking arrives or moves, and a dashboard charting bookings and the value booked by service. Then a scheduled job that cancels pending bookings whose hold has expired, protected by a shared secret rather than a sign-in, safe to run twice, and tell me where that schedule runs given how this project deploys. Then walk me through a whole day in the live preview: book as a stranger with no account, abandon a second booking and watch the slot return after the sweep, follow a guest link back to a booking, reschedule as a customer, try to cancel too late and meet my own policy, add a walk-in from the schedule, moderate a review, and confirm the dashboard agrees. When it holds up, publish, to Bolt’s own hosting by default, or to Netlify if I would rather manage the domain there.

   Do the abandoned booking for real rather than reading about it. A held slot that never comes back is invisible until the day you notice a fully-booked Tuesday with nobody in the chair, and it is the one bug in this build that costs money quietly every week it survives.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.