How to build a team meeting scheduler with Replit

Rule of thumb: if your hosts live in Outlook, your sessions are sold as packages or with deposits, or your leads have to reach a CRM the moment they book, rent. Those are real products, and none of the three is a weekend of describing. If what you need is one page for the team, bookings that reach the right person, and a bill that stays put when you hire, that is the half worth owning. One figure worth weighing either way, with its source in view: in a survey Calendly commissioned in mid-2024 of 1,244 workers in the US and UK, 43% said they spend at least three hours a week just scheduling meetings, up from 36% the year before. A scheduling vendor has an interest in that number, and it still describes a week most readers will recognise.

* 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 are small enough that only your logo and cover image ever touch the storage figure. 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 team that looks unavailable. 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.

Neither column above grows with the team. The tenth host costs what the second one did, so after launch the only line that can move is an AI model you choose to call, and only if you add a feature that uses one.

Prices and rates from supabase.com, developex.com and replit.com, checked September 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 a team meeting scheduler. The words throughout are member, host, weekly hours, date off, meeting type, one-on-one, group, round robin, collective, slot, booking and manage link. And two standing rules: whether a time is free is worked out on the server from each host’s rules and existing bookings and worked out again inside the write that creates a booking, never taken from the client, and every moment is stored in UTC with each host’s weekly hours kept in that host’s own zone. 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. A time handled “in the browser for now” is what any assistant reaches for once every test host sits in the same city, and on this app that shortcut is how a client in another country joins an empty call.

2. 02

   The team and the booking page, checked at a checkpoint

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

   PromptModel the team and build the booking pageCopy

   Design the schema and the server routes over it. Members: name, email, title, a colour, a role of admin or host, their own time zone, a round robin priority, and whether they are in the rotation. Weekly hours per member per weekday as one or more ranges in their zone, and dates off per member. Meeting types: name, URL slug, description, length, a kind of one-on-one, group, round robin or collective, seats for a group, a round robin rule of balance or priority, a location with a detail field, minutes of gap before and after, minimum notice, the interval between start times, a daily limit, and the members who host it. Questions per meeting type. One workspace row for the name, accent colour, logo and default zone. Seed three hosts across two time zones, one meeting type of each kind, and a host who is off on Fridays. Then the public side over it: a page listing meeting types, and a page per type with a month calendar, placeholder start times, and a time-zone picker that guesses the visitor’s zone. No accounts and no bookings in this message.

   Open your own booking page in the preview before going further, and take the checkpoint while you are there. How you name and group meeting types is the one structural choice clients navigate with their thumbs, and a list that read well as words rarely survives becoming a page of cards.

3. 03

   Availability on the server, written by the Agent

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

   PromptWork out availability properlyCopy

   Build availability as a server module, not logic in a page. Given a meeting type and a range of at most 45 days, return only genuinely free starts. For each host and date: take that weekday’s hours in the host’s own zone and turn them into UTC moments for that date, drop dates off, cut the hours into starts at the meeting type’s interval, then remove any start inside the minimum notice, any whose meeting plus the gaps before and after overlaps one of that host’s confirmed bookings, and every start on a day where the host has reached the daily limit. Combine by kind: one-on-one and group use their one host, round robin offers a start if any host in the rotation has it, collective only if every host has it, and a group start already booked stays on offer until its seats are full. Expose it through one server route the page calls, reading the bookings at request time. Then, in the preview, print the working for one Wednesday for the round robin type (which rule removed each missing start) and show me the same week as a visitor in Tokyo would see it.

   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, which is a gift while every row is seed data you made up and a decision worth pausing over once real bookings are in there.

4. 04

   The booking write, the manage link, and mail sent from your server

   A booking Postgres refuses to duplicate, a client with no account who can still move it, and the three emails that tell everybody what happened.

   PromptTake the booking in one protected writeCopy

   Build the booking side as one Postgres function called by a server route, never as separate inserts from the page. It takes the meeting type, the start, and the guest’s name, email, zone and answers. Inside one transaction: an advisory lock per host involved, the start worked out again with the availability module’s rules, the round robin host picked (balance is fewest confirmed bookings from seven days ago to thirty days ahead with priority breaking ties, priority is the highest-priority host who is free), seats and the daily limit checked, then the booking and a row per host inserted. Add an exclusion constraint so one host can never have two confirmed bookings that overlap. A manage token of 32 random bytes with only its SHA-256 hash stored, and a manage page to cancel with a reason or pick a new time, keeping the same calendar invitation id with its sequence increased. Confirmation, reschedule and cancellation emails through Resend from the server with an .ics attached, the key in Replit’s Secrets, and the email skipped with a log line when no key is set. A honeypot field rejects the submission when filled. Finally, show me two requests booking the same host and time 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 look for whichever identity it has just announced.

   PromptAdd sign-in, roles, and access rulesCopy

   Build sign-up, login, logout, a password reset and a server-side session on email and password, linking each account to its member row by email, ignoring case. The first account on an empty database becomes the admin, under a lock so two sign-ups at once cannot both win, and a later sign-up whose email is not a member gets no access. Keep the role on the member row, with a trigger refusing changes to role, active, email, priority or the rotation flag unless an admin is asking and another refusing to remove the last admin. Then row-level security on every table: have the server declare the current member and their role as session-local settings at the start of every request, and write the policies to read them. A request with no member declared gets no policy at all, so the booking page keeps reading through the server routes from the last two steps. A host reads the bookings they are on and edits their own hours and dates off, and an admin reaches everything. Then show me how to prove, as a signed-in host, that another host’s booking comes back empty, that an undeclared request cannot read bookings, and that a host cannot make themselves admin.

   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 behaves as if nobody special is asking, and you want to know which way that falls before a client’s answers are in the table.

6. 06
   Destination

   Google Calendar, the back office, and publishing

   The calendar connection, the admin screens and the embed, then a week worked through the app and the release that puts it on a real address.

   PromptConnect Google, add the back office, and publishCopy

   Three things left. First, Google Calendar: an OAuth connection per host asking only for calendar.events and calendar.freebusy, a signed state on the callback, the client ID and secret in Replit’s Secrets, each refresh token encrypted with a key from Secrets before it is stored and never returned to the browser, and busy times from free/busy removed from the available starts (when Google errors, offer the times and log it). Write each booking to the first connected host’s calendar with the guest and other hosts invited, a Meet link for Google Meet, and delete it on cancellation. Second, the back office: bookings by week, month and list with a host cancel, the meeting type editor, each host’s hours and dates off, the team with invites and round robin settings, analytics over 7, 30 or 90 days, branding with the logo stored in object storage, and a share page that writes the embed snippet as inline, a popup button or a popup text link. Third, help me work a week: book each kind of meeting as a stranger, book round robin five times and check who got them, cancel and reschedule from the email link, add a busy event in Google, and when that holds, take me through Publishing and adding the published address to Google’s redirect list.

   The Google redirect address has to match the published URL exactly, and the one the preview runs on is different. Add both before you test, and connect the calendar again from the published app once it is live, since a connection that only ever worked in the preview is the one that fails on the first real booking.

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, your Google client secret, the key that encrypts calendar tokens, and any AI provider key belong in Replit’s Secrets and nowhere else: not in the app, and not in a repository you push. Treat any of them 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 needs only one of them to serve the app. 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 client. Send the message to that function and get back a structured guess: which of my meeting types they seem to want, the window they are describing, and their time zone if the message gives one away. Then run that window through the real availability for that meeting type and show me the three closest free times as a draft reply I can copy, with a booking link for each. Never create a booking from the model’s output. Where the message is vague, say so rather than choosing for me: if it says “sometime next week”, I want to see that, not a Tuesday you picked.

Add a “prepare” action on a booking that sends the meeting type, the scheduled time and the answers to my booking questions to my ai function, and returns a three-line brief for the host: what the client wants, what to have ready, and one question worth asking. Send no email address, no phone number and no name. Show the brief on the booking in the dashboard only, never write it to Google Calendar or into an email, and say plainly when the answers are too thin to brief from rather than padding them out.

Add a “draft a reply” action that takes a client’s message and the meeting type it is about, and returns a short, polite reply I can edit before it goes anywhere. It may only offer times that the availability function actually returns, it must say when nothing fits rather than inventing an exception, and it never promises that a host will make time outside their hours, because that is a decision for the host and not for the model.

Add a panel on the analytics page that groups the last period’s cancellation reasons by what they are actually about, using my ai function, and returns each theme with a count, one representative quote, and which meeting type and how far ahead the booking was made. Send the reason text only, with no names or email addresses. State counts as figures, print the period it covered beside the result, and where a theme rests on one or two cancellations, say so instead of presenting it as a trend.

Add a panel that answers questions about my own booking history through my ai function: bookings per host per week, how round robin meetings were shared out, cancellation rates by meeting type and by host, and which hours of the week fill first. Have it compute every figure 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 client 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.