How to build a team meeting scheduler with v0

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, v0.app, v0.app and vercel.com, checked September 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Sketch the booking page, because that is what v0 leads with

   The whole public side with invented hosts and invented times, in one chat. The point is to look at how somebody gets from a meeting type to a confirmed time before anything is stored anywhere.

   PromptSketch the booking screensCopy

   Build the public screens for a team meeting scheduler in Next.js, using placeholder content for now. A booking page with the business name, logo and a card per meeting type showing its length, location and host. A page per meeting type with a month calendar, a list of start times for the chosen day, and a time-zone picker that guesses the visitor’s zone. A booking form with the name, email and a few custom questions, then a confirmation page. A manage page where a guest can cancel or pick a new time. Include one 15-minute type and one 60-minute type so I can see how differently their times lay out, and show me the empty state for a day with nothing free. Keep it responsive, because most people will book this from a phone.

   Use Design mode for the visual corrections rather than describing them. On a booking page the tap targets on the list of times and how the calendar reads on a phone are most of the product, and those are exactly what Design mode is for.

2. 02

   Connect the database and let the page read real meeting types

   Where the hand-off happens. Add the integration from the project menu, then ask for the schema and the routes that retire the placeholders you just looked at.

   PromptModel the team and connect the databaseCopy

   A Supabase integration is now connected to this project. Design the schema and the routes that read it, then take the placeholder content out of the screens you already built. 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. Write server-side routes for the booking page and a single meeting type, and wire the existing pages to them. The start times stay placeholders until the next chat.

   Get this done before another screen exists. From here on everything reads or writes a real row, and a time list designed against invented times has to be rebuilt the moment the real ones turn out to arrive in a different shape.

3. 03

   Ask for availability on the server, not in the component

   The step that decides whether the times on screen mean anything, and the one where a tool that leads with interfaces will happily hand you something that looks like availability and filters an array in the page.

   PromptWork out availability properlyCopy

   Start a new chat for availability. Build it as a pure TypeScript module called from one server-side route, not in a component. 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. Read the bookings inside the route at request time, never from a copy the page fetched earlier, and wire the real times into the screen from step 01. Then show me the working for one Wednesday for the round robin type, listing which rule removed each missing start.

   Say “on the server, not in the component” and then check the diff for it. Filtering a fetched list of bookings in the page is the natural thing to write when the interface came first, and here it is worse than slow: that list is a snapshot, and the whole point of this function is to be right at the moment somebody presses the button.

4. 04

   The booking as its own chat: one write, a manage link, and the race

   The first part of this build that writes rather than reads. Give it a chat to itself, because at some point you will restore an earlier version here and you would rather the booking page did not travel back with it.

   PromptTake the booking in one protected writeCopy

   New chat for the booking side. Write it as one Postgres function called from a server route, never as separate inserts from the client. 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 same rules as the availability module, 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 route that cancels with a reason or moves the booking to a new time, keeping the same calendar invitation id with its sequence increased, never a booking id alone in a URL. 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 demonstrate two requests booking the same host and time at the same moment, with one refused.

   The manage link is the one to be firm about. A URL carrying only a booking id is the default shape for this feature, and it is a page anybody can walk through by changing a character, which here means somebody else’s name, email and the reason they wanted the call.

5. 05

   Roles and access rules, in a separate chat and its own pull request

   Two kinds of account over the same tables, and a visitor with none who should reach no table directly. Its own chat again, and its own reviewable diff.

   PromptAdd auth, roles, and access rulesCopy

   New chat, for authentication and access rules. 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 policy for anonymous visitors: the booking page keeps reading through the server routes from the last two chats. A host reads the bookings they are on and edits their own hours and dates off, and an admin reaches everything. The branding bucket 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.

   Give this its own pull request rather than stacking it on the booking work. Of every change in this build, the access rules are the one you will most want to read back as a single self-contained diff in six months, when somebody asks you what stops a host reading a colleague’s clients.

6. 06
   Destination

   Google Calendar, the back office, then merge and deploy

   The calendar connection, the dashboard and the embed, a week worked through the app, and only then the merge that publishes it.

   PromptConnect Google, add the back office, and rehearseCopy

   Last chat. Google Calendar first: an OAuth connection per host asking only for calendar.events and calendar.freebusy, with the callback as a server route checking a signed state, the refresh token stored in Supabase Vault and read only on the server, busy times from free/busy removed from the available starts (when Google errors, offer the times and log it), each booking written to the first connected host’s calendar with the guest and other hosts invited and a Meet link for Google Meet, and the event deleted on cancellation. Then the dashboard: 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. Finally, walk a week with me on the preview deployment: 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.

   Add the production address to Google Cloud’s redirect list before you merge, as well as the preview one. The callback URL has to match exactly, and a calendar connection that works on every preview and fails on the real domain is the most common way this step reaches launch day unnoticed.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.