How to build a rental booking platform with Claude Code

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 and claude.com, checked August 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

   Set up the project

   Get an empty app running and connected to your database, and hand Claude Code a short notes file so it stays consistent as you go. One prompt does the whole setup.

   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 those values never reach GitHub. Add a typed Supabase client under src/lib, and write a short CLAUDE.md describing the rental-marketplace stack and conventions so later edits stay consistent.

   Gives Claude Code a project and a memory to work against.

2. 02

   Design listings and availability

   Tell Claude Code the two things a marketplace can’t work without: a listing, and a calendar that can’t double-book it.

   PromptSet up listings and availabilityCopy

   Create the core data model as Supabase migrations: listings (host-owned, with title, description, location, amenities, base nightly price, and photos in Storage) and an availability table that tracks booked date ranges per listing. Add a database constraint or trigger that rejects an insert whose date range overlaps an existing confirmed booking for the same listing, so double-booking fails at the database, not just in the UI. Write the migration SQL, let me review it, apply it, then regenerate the TypeScript types.

   The availability rule has to live in the database. That’s what makes double-booking actually impossible, not just unlikely.

3. 03

   Add sign-in and write the roles migration

   Add sign-up and login, then a guest/host/admin role model where the same person can hold more than one role, because on a real marketplace, they often do.

   PromptAdd auth and rolesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a useUser hook. Then create an app_role enum with 'guest', 'host', and 'admin', and a user_roles table linking a user_id to a role, allowing a user to hold more than one, since the same person can book a stay and list their own property. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads user_roles, so later policies can call it without recursing. Put it all in a migration.

   Roles live in a table you control, not in the user’s own metadata. That closes the classic Supabase privilege-escalation hole.

4. 04

   Bookings, payouts, and locking the data down

   Add the booking and payout tables, then let the database enforce who can touch which rows: a guest their own bookings, a host their own listings and payouts, an admin everything.

   PromptAdd bookings, payouts, and RLSCopy

   Create a bookings table (linked to a listing and a guest, with check-in/check-out dates, status, and total price) and a payouts table (linked to a host and a booking, with the platform’s commission split out). Enable row-level security on listings, bookings, and payouts. A guest can read and insert their own bookings. A host can read and manage the listings and payouts that belong to them, checked with has_role. An admin, also checked with has_role, can reach every row for moderation. Name the WITH CHECK clause explicitly on every insert and update, so nobody can create a booking or payout for someone else. Put the policies in a migration, then show me how to verify that a second guest cannot read the first guest’s bookings, that a host cannot read another host’s payouts, and that an admin can read both.

   Skip this and any guest could read another guest’s bookings, or any host could see another host’s payouts.

5. 05

   Build the search, checkout, and dashboard screens

   Now the marketplace you actually use: search with filters, a listing page with live availability, checkout, and dashboards for hosts and admins.

   PromptBuild the screensCopy

   Build the core screens against these tables: a searchable listings page with filters (location, dates, price), a listing detail page showing live availability, a checkout flow that creates a booking and calls Stripe for payment, a host dashboard (listings, bookings, payouts), and an admin dashboard (listings, disputes, transactions). Keep all data access in typed hooks.

6. 06
   Destination

   Add reviews and messaging, then try it

   Round out the marketplace with reviews and a booking-scoped inbox, then click through the whole flow and fix anything that’s off.

   PromptAdd reviews, messaging, and testCopy

   Add a reviews table (linked to a completed booking, visible once both guest and host have left one) and a messages table for a booking-scoped inbox between guest and host. Then run the app and walk me through the full flow (search, book, pay, message the host, leave a review after checkout), then fix anything that breaks.

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.

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.