How to build an appointment booking system with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   One message for the app, the database, and the ground rules

   Postgres is part of this workspace rather than an account you go and open, so it belongs in the opening request, together with the two constraints the rest of the build stands on.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind and a server, and add a Postgres database to this Repl, the one Replit provisions, not anything outside. Write a short notes file at the project root recording three things. This is an appointment booking system. The words throughout are service, duration, opening hours, slot, availability, booking, hold, guest, and review. And two standing rules: 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, and every list of another person’s appointments is narrowed in the database rather than on a page, with a guest reaching their own booking going through a server-side token check rather than a rule that opens the table. Keep the database connection details in Replit’s Secrets rather than in the code.

   Both rules go in the file, not only in this request. Trusting a slot the page already knows about is what any assistant reaches for once the booking form obviously has the answer in hand, and on this app that particular shortcut is how two customers turn up for the same appointment.

2. 02

   The catalog and the shop window, checked at a checkpoint

   Schema and public pages in one go. Nothing writes anything yet, which makes this the inexpensive moment to discover your service list is organised the wrong way round.

   PromptModel the catalog and build the public pagesCopy

   Design the schema and the server routes 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 holding 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 side over it: a landing page, a catalog with category filters showing each price and length, and a service page with photos and a place for reviews. No accounts and no bookings in this message.

   Open your own catalog in the preview before going any further, and take the checkpoint while you are there. How you group services is the one structural choice customers navigate with their thumbs, and a grouping that read beautifully as a list of words rarely survives becoming a menu.

3. 03

   Availability in Postgres, written by the Agent

   The step that decides whether the times on screen mean anything. Ask for it in the database explicitly, and judge it on the slots it takes away rather than the ones it offers.

   PromptWork out availability properlyCopy

   Build availability in Postgres rather than in the application. Given service ids, a date range, and the duration the customer picked, return only genuinely free slots: 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. Store appointments as absolute moments. Expose it through one server route the picker calls, and do not fetch bookings and filter them in the route. Build the picker over it with a clear empty state for a closed day. Then, in the preview, print the working for one specific Tuesday (which slots each rule removed and why) and show me what the picker offers for a day I have deliberately booked solid.

   This is the step where checkpoints earn their keep. Availability reaches into the schema, and a rollback here offers to take the database along with the code, a gift while every row is seed data you made up, and a decision worth pausing over the moment real appointments are in there.

4. 04

   The hold, the guest token, and photos your server hands out

   Bookings that leave a slot out of circulation while somebody types, a guest who has no account, and one decision about files that does not come up on the other tools.

   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 writes a pending booking held for the minutes in my settings, removing it from availability at once. Confirming makes it confirmed and clears the hold. Inside that write, work availability out 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. Then the service photographs: uploaded through my own server into object storage, with the catalog images served publicly but the upload route open only to me later, once roles exist. Finally, show me two requests confirming the same slot at the same moment, and one of them refused.

   Insist on that last demonstration as running code. On a tool where the preview, the database, and the eventual host are all the same workspace it is tempting to trust what you can see working, and a booking form used by one person at a time is the one thing this bug cannot be caught by.

5. 05

   Sign-in your server owns, then rules that read what it says

   Nothing hands this database an account id by itself, so the Agent builds both ends of the chain: the sessions your own server issues, and the policies that go looking for whichever identity it has just announced.

   PromptAdd sign-in, roles, and access rulesCopy

   Build sign-up, login, logout, and a server-side session on email and password, with one profile row per account. Add a roles table giving each account customer or admin, in its own table, never on the account record, since anything there is editable by that user. Then turn on row-level security across every table: have the server declare the current account and its role as session-local settings at the start of every request, and write the policies to read them. A request with no account declared may read services, the settings the page needs, and approved reviews, and nothing else. 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 an undeclared request. Explicit with-check clauses on inserts and updates, and a review allowed only where a completed booking for that service belongs to that customer. Then show me how to prove, as a signed-in customer, that another customer’s booking comes back empty, that an undeclared request cannot list bookings, that a guest lookup with the wrong token returns nothing, and that a review without a finished appointment is refused.

   Nothing hosted is handing Postgres an account id here, which leaves your own server as the only part of the system that knows who is asking. Prove the announcement works before writing a policy that depends on it: a policy with nothing to read does not complain, it simply lets everybody through, and what it would be letting them through to is the name, number, and Thursday afternoon of every customer you have.

6. 06
   Destination

   The back office, a Scheduled sweep, and publishing

   The admin screens, then the one piece of this build that is not a request from a browser at all, and on this tool it is a deployment of its own rather than a database feature.

   PromptAdd the back office, the sweep, and publishCopy

   Three things left. 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 the value booked by service. Second, the sweep that cancels pending bookings whose hold has expired: authenticate it with a secret from Replit’s Secrets rather than a session, make it safe to run twice, and set it up as its own Scheduled deployment rather than something the app does when somebody happens to visit. Third, help me work a whole day: book as a stranger, abandon a booking and watch the slot come back once the sweep has run, follow a guest link, reschedule as a customer, try to cancel too late, add a walk-in from the schedule, moderate a review, check the dashboard, and when that holds, take me through Publishing: which deployment type suits the app, why the sweep is a second one, and who the app ought to be visible to on day one.

   Publish the sweep separately and then actually wait for it once. A scheduled job that was never triggered looks identical to one that works, and the first evidence you get either way is a calendar that either frees itself up overnight or quietly fills with appointments nobody made.

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 connection, any AI provider key, and the secret guarding your scheduled sweep belong in Replit’s Secrets and nowhere else: not in the app, and not in a repository you push. Treat any of the three that escapes as burned, and replace it the same day.

All of these are Replit rather than a third party, so the choice is shape rather than vendor, and this build wants two of them: one to serve the app, and Scheduled for the sweep. Review who the app is visible to before the first release, since Publishing is what sets it.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.