How to build a team meeting scheduler with Claude Code

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 claude.com, checked September 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 Claude Code runs the commands.

1. 01

   Get it running, then write the two rules down

   An app booting against your own database, and a CLAUDE.md carrying the two constraints every later step leans on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a team meeting scheduler (member, host, weekly hours, date off, meeting type, one-on-one, group, round robin, collective, slot, booking, manage link) and recording two standing rules. First: whether a time is free is always worked out on the server from each host’s own rules and existing bookings, and worked out again inside the write that creates a booking, never taken from what the browser was shown. Second: every instant is stored in UTC, each host’s weekly hours are kept in that host’s own time zone, and the browser only ever converts for display.

   Put both rules in the file, not only in this message. Everything after this assumes them, and a time zone handled “just in the browser for now” is the shortcut any assistant will reach for the first time a page needs to show a Friday.

2. 02

   Model the team and the meeting types, then a page over them

   Hosts with their own hours, meeting types with their own rules, and the public booking page reading them. No bookings and no accounts yet, which makes this the cheap moment to find out your meeting types are organised the wrong way.

   PromptModel the team and build the booking pageCopy

   Write the data model as Supabase migrations, with no authentication yet. 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 that member’s own zone, and dates off per member. Meeting types: name, URL slug, description, length in minutes, 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 (Google Meet, Zoom, Teams, phone or in person, with a detail field), minutes of gap before and after, minimum notice, the interval between start times, a daily limit, and which members host it. Questions per meeting type, with a label, a type, options and whether it is required. One workspace row for the business name, accent colour, logo and default time zone. Seed three hosts in two time zones, one meeting type of each kind, and one host who is off on Fridays. Then build the public side: a page listing the meeting types, and a page per type with a month calendar, the start times for the chosen day as placeholders, and a time-zone picker that guesses the visitor’s zone.

   Seed the two time zones and the Friday off on purpose. Two hosts in London and one in New York is what proves the next step is computing times per person rather than drawing one grid, and inventing them now is easier than remembering you need them later.

3. 03

   Work out availability, per host and then for the team

   The step this application is made of. Ask for it as a server-side calculation that combines hosts by the kind of meeting, then make Claude Code show you its working for one day rather than a screenshot of a calendar.

   PromptWork out availability properlyCopy

   Build availability as pure TypeScript shared with a server function, not in the browser. Given a meeting type and a date range of at most 45 days, return the start times that are genuinely free. For each host and each date: take that host’s weekly hours for the weekday in the host’s own zone and turn them into UTC moments for that date, drop the date if they marked it 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 would overlap one of that host’s confirmed bookings, and every start on a day where the host has reached the daily limit. Then 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 offers it only if every host has it. For a group, a start already booked stays on offer until its seats are full, and other starts overlapping it are removed. Write unit tests for each rule and for a day when the clocks change. Then print the working for one Wednesday for the round robin type, listing each host’s starts and which rule removed each missing one, and show the same week as a visitor in Tokyo would see it.

   Ask for the working, not just the calendar. A grid of times looks correct whatever produced it, and the order of those subtractions is where every double booking and every missing Friday in this category comes from. Reading them once, in order, for one real day is the cheapest review you will do on this build.

4. 04

   Take the booking in one write the database protects

   The first step that writes anything: the booking itself, the link that lets a guest move or cancel it, and the email that tells them it happened.

   PromptTake the booking in one protected writeCopy

   Build the booking write as one Postgres function called by a server function, never as separate inserts from the browser. It takes the meeting type, the start, and the guest’s name, email, time zone and answers. Inside one transaction: take an advisory lock per host involved, work the start out again with the same rules as step 03, pick the host for round robin (balance means fewest confirmed bookings from seven days ago to thirty days ahead with priority breaking ties, priority means the highest-priority host who is free), check seats for a group and the daily limit, then insert the booking and a row per host. Add an exclusion constraint so two confirmed rows for the same host with overlapping times can never exist. Generate 32 random bytes as a manage token, store only its SHA-256 hash, and build a manage page where the guest can cancel with a reason or pick a new time, keeping the same calendar invitation id with its sequence increased. Send a confirmation, a reschedule notice and a cancellation through Resend with an .ics attached, and log and skip the email when no key is set. Reject any submission that fills a hidden honeypot field. Then prove the race: fire two bookings for the same host and start at the same moment, and show one of them refused.

   Insist on that last demonstration as running code rather than an explanation. Two people pressing the same 10am is the failure a client experiences as your team being disorganised, and it is invisible in every test you run on your own.

5. 05

   Sign-in, two roles, and nothing at all for anonymous visitors

   The database now holds the names, emails and answers of real clients. Two kinds of account share it, and the visitor with no account should reach none of it directly.

   PromptAdd auth, roles, and access rulesCopy

   Add Supabase Auth with email and password, a password reset, and linking an account to its member row by email, ignoring case. The first account on an empty project becomes the admin, under a lock so two sign-ups at once cannot both become admin, and a later sign-up whose email is not a member gets no access at all. Keep the role on the member row and add a trigger that refuses changes to role, active, email, priority or the rotation flag unless an admin is asking, plus one that refuses to remove the last admin. Then enable row-level security on every table with no policy for anonymous visitors at all: the public page keeps reading through the server functions from steps 03 and 04, which return only what a booking page should show. A host reads the bookings they are on and edits their own hours and dates off. An admin reaches everything. The branding bucket is public to read, admin-only to write, and refuses SVG. Then prove four things by querying as a signed-in host: another host’s booking comes back empty, an anonymous request to the bookings table returns nothing, a host cannot make themselves admin, and the last admin cannot be demoted.

   The anonymous case is the one to check hardest. The tempting shortcut is a policy that lets anybody read the meeting types and hours so the booking page can query them directly, and it passes every test you will think of while publishing your team’s whole schedule to anyone who opens the network tab.

6. 06
   Destination

   Google Calendar, the back office, the embed, and a rehearsed week

   The calendar your hosts actually live in, the screens your team works from, the snippet that puts the page on your own site, and then the part most builds skip: use the scheduler as five different people.

   PromptConnect Google, add the back office, and rehearseCopy

   Finish the app. Google Calendar first: an OAuth connection per host asking only for calendar.events and calendar.freebusy, a signed state on the callback, the refresh token stored in Supabase Vault and read only by server functions, and busy times from free/busy removed from the starts in step 03 (if Google errors, offer the times anyway and log it). Write each booking as an event on the first connected host’s calendar with the guest and any other hosts invited, add a Meet link when the location is Google Meet, and delete the event on cancellation. Then the back office: bookings by week, month and list with a host cancel, the meeting type editor with details, limits, questions and hosts, each host’s hours and dates off, the team with invites and round robin settings, analytics over 7, 30 or 90 days, branding, and a share page that writes the embed snippet as inline, a popup button or a popup text link, with the iframe resizing itself. Then rehearse a week: book each kind of meeting as a stranger, book the round robin type five times and check who got them, cancel and reschedule from the email link, add a busy event in Google and watch the time disappear, and embed the page on a test site.

   Do the rehearsal in separate browser profiles rather than switching your own role, and put a real event in a host’s Google Calendar before you check the page. A calendar connection that saves its token and then never reads busy time looks exactly like one that works until the first client books over a dentist appointment.

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, your Google client secret, the secret that signs a calendar connection, and any AI provider key live on the server and nowhere else: not in the app a visitor downloads, and not in a public repository. Treat any of them 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. Whether it publishes from a private repository, because this code sits beside your clients’ details. And whether a deep link resolves in a browser that has never seen your site: a link to one meeting type and the manage link in a confirmation email 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 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.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.