How to build a rental booking platform with Bolt

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 bolt.new, checked August 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

   Push an empty repo to GitHub, then import it into Bolt

   Bolt has no upload button for a folder or a .zip, so before anything else exists, create a private GitHub repository and import it. Bolt scaffolds the project inside it and starts committing back on its own from here.

   PromptImport and scaffold the projectCopy

   I just imported an empty repository. Set up a React 18 + Vite + TypeScript project here with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key from .env, confirm .env is already in .gitignore so neither value ever reaches GitHub, and write a short notes file describing the rental-marketplace stack so later prompts stay consistent. Commit it back to the repository once it runs.

   Every other tool in this set can start from a blank chat, but Bolt needs this repository to exist first.

2. 02

   Build the two tables a marketplace can’t run without

   Listings and a calendar that can’t double-book them are what every later screen depends on. Watch the live preview rebuild as Bolt writes the migration.

   PromptSet up listings and availabilityCopy

   Ask for two migrations. First, a listings table: title, description, location, amenities, and a base nightly price live on the row itself, each one owned by a host account, with photos going into Storage instead of the table so a listing with fifty photos doesn’t bloat the row. Second, a table that records which nights are already booked on a given listing, with a constraint that blocks a new row from overlapping a night that’s already confirmed, so two guests booking the same night fails in the database itself, not in whichever screen happens to check first. Show me the SQL, then apply it and regenerate the TypeScript types.

   Put this constraint in the migration, not in a form’s validation. A form can be skipped by a different screen. The database can’t.

3. 03

   Add sign-in, then a role an account can hold more than one of

   Layer sign-up and login on top, then a guest/host/admin role model that doesn’t assume a person is only ever one of the three.

   PromptAdd auth and rolesCopy

   Wire in Supabase Auth first. Email and password is enough to start, covering sign-up, login, logout, a session that survives a refresh, and a useUser hook the rest of the app can read from. On top of that, this marketplace needs three roles rather than one flag on the account: an app_role enum for 'guest', 'host', and 'admin', and a user_roles table connecting a user_id to a role, allowing more than one row per user since a host is often a guest on someone else’s listing too. Add a SECURITY DEFINER function, has_role(_user_id uuid, _role app_role), that reads from user_roles so the next prompt’s policies can call it without recursing into itself. One migration for the whole thing, committed once it’s applied.

   A role stored on the user’s own account is one that account could edit, which is why has_role reads from a table of its own.

4. 04

   Use Plan Mode to lock down bookings and payouts

   This prompt reaches into both money and personal data, so talk the plan through with Bolt before any code exists, and test it against a second account once it does.

   PromptPlan, then add bookings, payouts, and RLSCopy

   In Plan Mode: I need a bookings table (listing plus guest, with dates, status, and total price) and a payouts table (host plus booking, with the platform’s commission split out), and row-level security across listings, bookings, and payouts so a guest reaches only their own bookings, a host reaches only their own listings and payouts (checked with has_role), and an admin reaches everything. Walk me through the policies, including an explicit WITH CHECK on every insert and update, before you write any SQL. Once I approve the plan, apply it and show me how to verify that a second guest can’t read the first guest’s bookings.

   Approving a plan isn’t the same as testing it. Try to break the policy with a second account before you trust it.

5. 05

   Prompt the search, checkout, host, and admin screens into place

   Point Bolt at the tables from the last three steps and build the screens that actually use them, checking the live preview after each one instead of approving several prompts in a row.

   PromptBuild the screensCopy

   Now the screens: on the guest side, a listings page with filters for location, dates, and price, feeding into a listing page with the live calendar, then a Stripe checkout that turns a selection into a real booking. On the host side, one dashboard covering their listings, their bookings, and what they’re owed. On the admin side, another dashboard covering every listing, open disputes, and the transaction history behind them. Wire each one to the tables from the last three steps rather than starting fresh. Keep the data access in typed hooks rather than scattered through components.

6. 06
   Destination

   Layer in reviews and messaging, then run the full flow in the preview

   Two more tables finish the marketplace, reviews and a booking-scoped inbox, then click through the whole flow in the live preview and fix whatever’s off before you call it done.

   PromptAdd reviews, messaging, and testCopy

   Two tables left: reviews, which shouldn’t show up until both the guest and the host have actually left one for a finished stay, and a messaging thread scoped to a single booking rather than one long inbox between two people. Add both, then run the whole flow in the live preview (search for a stay, book it, pay, message the host, leave a review after checkout), then fix whatever 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.

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.