How to build a team meeting scheduler with Lovable

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 docs.lovable.dev, checked September 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   Attach the database before you ask for a single screen

   Any booking screen designed over data that does not exist yet gets rebuilt the day it does. Connect the database first, and put the two rules this build rests on into the conversation while it is still short enough for them to hold.

   PromptSet up the projectCopy

   Connect my Supabase project before building any screens at all. Then set up a team meeting scheduler, and hold two rules for the rest of this project. 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 at the moment a booking is saved, never taken from what the page was showing. Second: every moment is stored in UTC, each host’s weekly hours are kept in that host’s own time zone, and the page only converts them for display. Use these words consistently: member, host, weekly hours, date off, meeting type, one-on-one, group, round robin, collective, slot, booking, manage link. Confirm the connection is live, then tell me which of those two rules changes how you will design the weekly hours table, before you design it.

   That closing question earns its extra exchange. It is the cheapest way to find out now whether Lovable has in mind hours stored per person in their own zone, or one grid for the whole business, and only one of those two survives your first host in another country.

2. 02

   Describe your team and your meeting types, and watch the page appear

   The part Lovable is fastest at, and the part where looking at it beats specifying it. Get your meeting types in front of your own eyes before a single booking exists.

   PromptModel the team and build the booking pageCopy

   Design the tables and build the public side over them. 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 business name, accent colour, logo and default zone. Add three hosts across two time zones as sample data, one meeting type of each kind, and one host who is off on Fridays. Then the public pages: a page listing the meeting types, and a page per type with a month calendar, placeholder start times for the chosen day, and a time-zone picker that guesses the visitor’s zone. No sign-in and no bookings in this message.

   Click your own booking page in the preview before moving on, and use Select elements to fix what looks wrong rather than describing it. How a meeting type’s length, location and host sit together on its card is most of whether somebody picks it, and it is far quicker to point at than to word.

3. 03

   Ask for availability on the server, in those words

   A preview will not show you that availability is wrong, because every host you invented is in your own time zone and you know what is booked. Ask for the calculation explicitly and then test it with a day you have deliberately filled.

   PromptWork out availability properlyCopy

   Build availability as a server-side function rather than logic in the screen, and treat this as the most important message in the project. Given a meeting type and a range of at most 45 days, return only genuinely free start times. 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. 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 only if every host has it, and a group start already booked stays on offer until its seats are full. Afterwards, show me two things by running them: the working for one Wednesday for the round robin type, listing each host’s starts and which rule removed each missing one, and the same week as a visitor in Tokyo would see it.

   Bookmark the version you are on before you send this. Availability is the message most likely to take two or three goes, and coming back to a version you know worked beats untangling a half-changed schema. Remember that restoring code in Lovable does not roll back your database, so a bookmark is worth more here than anywhere else in the build.

4. 04

   The booking, the manage link, and the email that confirms it

   The first messages that write anything. A booking has to be refused when the time went a second ago, and a client with no account has to be able to move it.

   PromptTake the booking in one protected writeCopy

   Build the booking as one database function called by an edge function, never as separate saves from the page. It takes the meeting type, the start, and the guest’s name, email, time zone and answers. Inside one transaction: a lock per host involved, the start worked out again with the rules from the last message, the round robin host picked (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), seats and the daily limit checked, then the booking and a row per host saved. Add a database constraint so one host can never have two confirmed bookings that overlap. Create a manage link from 32 random bytes, keep 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 skip the email with a log line when no key is set. Reject any submission that fills a hidden honeypot field. Then show me two bookings for the same host and time sent at the same moment, and one of them refused.

   Add the Resend key as an edge function secret when Lovable asks for it, never pasted into the chat. Then book yourself a meeting and open the email on your phone: the .ics has to land in your own calendar at the right hour before you trust it with a client’s.

5. 05

   Logins, two roles, and a booking page that reads no tables

   Your team signs in, and clients never do. The rules have to hold both of those, and keep the visitor who opens the network tab away from the tables themselves.

   PromptAdd auth, roles, and access rulesCopy

   Add sign-in for my team with email and password and a password 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 become admin, and any later sign-up whose email is not a member gets no access. Keep the role on the member row, with a trigger that refuses changes to role, active, email, priority or the rotation flag unless an admin is asking, and one that refuses to remove the last admin. Then row-level security on every table with no policy for anonymous visitors at all: the booking page keeps reading through the edge functions from the last two messages. 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 show me, 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.

   Check the anonymous case from a private browser window rather than from the preview, where you are signed in. The shortcut to refuse here is a policy that opens the meeting types and hours to public reads so the page can query them directly: the page already gets what it needs through the edge functions, and that policy would hand anybody your team’s whole schedule.

6. 06
   Destination

   Google Calendar, the back office, and a week worked through the preview

   The calendar your hosts already use, the screens your team works from, and the snippet that puts the page on your own site. Then a week of meetings booked by people who are not you.

   PromptConnect Google, add the back office, and rehearseCopy

   Finish the app. Google Calendar first: a 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 edge functions, and busy times from free/busy removed from the available starts (when Google errors, offer the times and log it). Write each booking as an event on the first connected host’s calendar with the guest and any other hosts invited, a Meet link when the location is Google Meet, and delete it 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 walk me through a week: book each kind of meeting as a stranger, book the round robin type five times and show me who got them, cancel and reschedule from the email link, and add a busy event in Google to watch the time disappear.

   Your Google client ID and secret go in as edge function secrets, and the redirect address in Google Cloud has to match the published URL exactly, not the preview one. Connect a real calendar and put a real event in it before you believe the page, since a connection that saved its token but never reads busy time looks fine until a 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.

One button, and the app you have been previewing is live.

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.