How to build a rental booking platform with v0

Rule of thumb: if you run more than a handful of properties and want the booking flow, cancellation policy, and payout split to match exactly how you operate, building your own pays for itself within months of what a per-listing subscription would have charged. If you need built-in OTA channel sync today and would rather not touch a codebase, buy, then revisit once the bill outgrows the value.

* Supabase is free while you build and for light use, though projects pause after 1 week of inactivity, and the free tier caps you at 500 MB of database and 2 active projects. The Pro plan, from $25/mo, keeps your database running around the clock for real guests and hosts.

Either way you own the code outright, so there is no per-listing subscription and every new host account costs you nothing. The one cost neither column shows is the payment processor’s fee on each booking, because a guest’s money has to reach a host somehow. That fee is a percentage of what you take rather than a monthly bill, so it grows with your bookings and not with your listings. The payments section below prices the three usual ways to move it.

Prices and rates from supabase.com, developex.com, v0.app, v0.app and vercel.com, checked August 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 search and listing screens, no backend yet

   Start a new v0 chat and describe the two screens every visitor sees first, before a database exists behind them. v0 generates a working Next.js interface you can click through right away, filled with placeholder listings. The real data comes in the next step.

   PromptSketch the first screensCopy

   Build a Next.js app with Tailwind for a rental marketplace. Start with two screens: a searchable listings page (cards showing photo, title, location, and nightly price, with filters for location, dates, and price) and a listing detail page showing photos, amenities, and an availability calendar. Use realistic placeholder data for now. We’ll connect a real database in the next step.

   Placeholder data is deliberate here, because it’s faster to see the shape of a screen before there’s a schema underneath it.

2. 02

   Give those screens something real to save: connect Supabase

   Connect a Supabase project from the project menu, then ask for the two tables the screens from step 01 actually need: a listing, and a calendar that can never double-book it.

   PromptConnect Supabase and model listings and availabilityCopy

   Connect this project to a Supabase database from the project menu. A listing needs an owner (the host), a name and a description, a place, a list of amenities, what it costs a night, and a set of photos. Store the photos in Supabase Storage rather than the database row itself. Alongside it, track which date ranges are already booked on each listing, and stop a new booking from landing on one that already exists with a database-level constraint, not a check in the interface. Once that migration is applied, write the routes that read from it, and swap the search and listing pages over to them instead of the placeholder data from step 01.

   This is the one migration worth reading end to end, because a listing page that shows an already-booked night is worse than one that just loads slowly.

3. 03

   Turn on sign-in, then split guest, host, and admin

   Add sign-up and login through Supabase Auth, then a role model that lets one account be a guest on one booking and a host on another, the normal case on a real marketplace.

   PromptAdd auth and rolesCopy

   Add Supabase Auth email-and-password sign-up, login, and logout, called from Next.js route handlers with the session available to the rest of the app. Then create an app_role enum for 'guest', 'host', and 'admin', and a user_roles table linking a user_id to a role, letting one account hold more than one. Add a has_role(_user_id uuid, _role app_role) SECURITY DEFINER function reading from user_roles, so the routes we write next can check it without recursing.

   Keep roles in that table, never on the Supabase user object itself. A role a user can edit is a role they can grant themselves.

4. 04

   Add bookings and payouts, then lock every row down

   Add the table that turns a stay into a real booking and the one that tracks what a host is owed, then let row-level security decide who can reach which rows.

   PromptAdd bookings, payouts, and RLSCopy

   Create a bookings table (a listing, the guest, check-in and check-out dates, a status, and the total price) and a payouts table that links a host to one of their bookings, with the platform’s commission already split out as its own column. Then turn on row-level security: a guest can read and insert only their own bookings, a host can read and manage only the listings and payouts tied to their account (checked with has_role), and an admin (also checked with has_role) can reach every row. Name the WITH CHECK clause on every insert and update explicitly, so nobody can create a booking or payout under someone else’s name. Write the routes for creating a booking and viewing payouts next, then show me how you’d prove a second guest can’t read the first guest’s bookings.

   Read this one closely before merging the pull request it lands on. A mistake in these policies means one guest reading another guest’s booking history.

5. 05

   Connect checkout, the host dashboard, and admin to real data

   Sketch the remaining screens the same way as step 01 (checkout, a host dashboard, an admin dashboard), then connect each one to the routes and tables that already exist, instead of building them against data you’d have to redo later.

   PromptBuild and connect the remaining screensCopy

   Build a checkout flow that creates a booking and takes payment through Stripe, a host dashboard covering listings, bookings, and payouts, and an admin dashboard covering listings, disputes, and transactions. Connect all three straight to the routes and tables from the earlier steps. These have no reason to start on placeholder data the way the first two screens did.

6. 06
   Destination

   Wire in reviews and messaging, then open the pull request

   Two more tables round out the marketplace, reviews and a booking-scoped inbox, then open a pull request for this chat’s work and try the real flow before you merge it.

   PromptAdd reviews, messaging, and testCopy

   A review only means something once the stay is actually over, so tie it to a completed booking and hold it back from view until both sides have submitted one. Alongside it, add a messages table scoped to a single booking, so a guest and host talk about that stay and nothing else. Then connect this project to GitHub, open a pull request from this chat’s branch, and walk me through testing the full flow before we merge it: search, book, pay, message the host, leave a review after checkout.

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.

The one rule that matters: never put a secret key, database or payment provider, in the app or a public repo. If one ever leaks, reset it right away.

Any of these works. One thing to check before you settle: a free tier is not automatically free for *business* use. Vercel’s Hobby tier is the strictest here, personal projects only, so a marketplace handling real guests and hosts belongs on a paid plan. Read the plan terms for the host you pick, not just the price.

Work out one number before you connect anything: the fee on a single booking, times the bookings you expect in a year. Three hundred stays at $900 costs roughly $7,900 a year on the first row and roughly $9,600 on the second, for the same money arriving, and paying twenty hosts once a month adds about $480 in account fees on top of the first. Connecting nothing is still a real answer: the calendar, the booking and the commission you record are all correct whether or not a card is ever charged, and a site that introduces guests to hosts and lets them settle up directly pays none of this.

Add a "Suggest a reply" button on the host inbox that sends the guest’s message, the booking details, and the last few messages in the thread to your ai function, and returns a short, editable reply draft the host can edit before sending.

Add a "Suggested price" panel on the host’s calendar that sends the listing’s upcoming occupancy, day of week, and how far out the date is to your ai function, and returns a suggested nightly rate with a one-line reason the host can accept or ignore.

Add a "Summary" block on the listing page that sends its most recent reviews to your ai function and returns a short summary of recurring praise and complaints, refreshed whenever a new review is added.

Add a "Generate description" action on the listing editor that sends the property’s type, amenities, and the host’s rough notes to your ai function and returns a polished draft description the host can edit before publishing.

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.