How to build a team meeting scheduler with Bolt

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 bolt.new, checked September 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 a team meeting scheduler, the vocabulary we will use throughout (member, host, weekly hours, date off, meeting type, one-on-one, group, round robin, collective, slot, booking, manage link) and two standing rules. First: 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. Second: every moment is stored in UTC, each host’s weekly hours are kept in that host’s own zone, and the page converts only for display.

   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 team and the meeting types in one prompt, then look at the page

   Hosts with their own hours, meeting types with their own rules, and the booking page reading them. Nothing writes yet, which makes this the cheap moment to find out your meeting types do not match how clients ask.

   PromptModel the team and build the booking pageCopy

   Connect a database for this project, then design the schema and build the public side 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 pages: 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 prompt.

   Two time zones in that seed data is not decoration. It is what will later prove your availability is computed per person rather than drawn as one grid, and adding it now costs one clause in a prompt you are sending anyway.

3. 03

   Plan the availability rules before Bolt writes them

   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 a meeting type and a range of at most 45 days, it returns 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. Talk me through the plan first, especially how you turn a host’s hours into UTC on a day the clocks change and how you compare a booking with its gaps against a start. Once I agree it, write the function with tests, expose it through one route, and print the working for one Wednesday for the round robin type.

   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 booking write and the manage link, then clear the context

   The first prompts that write anything: a booking the database refuses to duplicate, and a client with no account who still needs a safe way to move it.

   PromptTake the booking in one protected writeCopy

   Build the booking side as one database function called by a server function, 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: a lock per host involved, the start worked out again with the same rules as the availability function, 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 a database 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 with an .ics attached, skipped with a log line when no key is set, and a honeypot field that rejects the submission when filled. Then show me two sessions booking the same host and time at the same moment, and one refused.

   When this is working, clear Bolt’s context before you start the back office. The dashboard 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 a 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-in with a reset, linking each 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 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 with no rule for anonymous visitors at all: the booking page keeps reading through the server functions from the last two prompts. A host reads the bookings they are on and edits their own hours and dates off, and an admin reaches everything. The branding storage is public to read, admin-only to write, and refuses SVG. Then prove, signed in as a host, that another host’s booking comes back empty, that an anonymous request to the bookings table returns nothing, and that a host cannot make themselves admin.

   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

   Google Calendar, the back office, a full week, then publish

   The calendar connection, your dashboard and the embed, then a week worked through the running app before you publish it.

   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 encrypted and read only by server functions, 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 when the location is Google Meet, and delete it on cancellation. Then the admin side: 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 walk me through a week in the live preview: 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, and add a busy event in Google to watch the time disappear.

   Put a real event in a real host’s Google Calendar before you check the page, rather than trusting the connection because it saved. A calendar link that stores its token and never reads busy time is invisible until the first client books over something your host already had in the diary.

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.

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.