How to build a rental booking platform with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   Start a Replit app and let the Agent add a database

   Start a new Replit app and ask for the Postgres database in the same message, because Replit needs no separate account for it. Ask for a short notes file too, the same way you would on any other tool, so the Agent’s conventions carry across the rest of the build.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind, and add a Postgres database to this Repl. Use the one Replit already provisions rather than connecting an outside service. Write a short notes file at the project root describing the stack and the rental-marketplace conventions I want kept for the rest of this build, and keep the database connection details in Replit’s Secrets rather than in the code.

   The database is already part of the workspace, so asking for it here is one message, not a separate signup.

2. 02

   Add listings and availability to your new database

   Ask the Agent to add the two tables this build leans on hardest: where a listing lives, and a calendar that refuses to let two guests land on the same night. Read the migration it proposes before it touches the database.

   PromptSet up listings and availabilityCopy

   Write the SQL migration for two tables on the Postgres database already in this Repl: listings (host-owned, with title, description, location, amenities, base nightly price, and photo URLs) and availability (tracking which date ranges are already booked per listing). Add a constraint that rejects an insert whose dates overlap an existing confirmed booking for the same listing, so double-booking fails in the database itself. Show me the SQL before you run it.

   The database-level constraint is what actually stops a double-booking, not a check written only in the interface.

3. 03

   Give guests, hosts, and admins each their own role

   Add sign-up and login, then a guest/host/admin role model where one account can hold more than one role, the normal case on a real marketplace. Replit doesn’t wire an auth system straight into the database the way a Supabase project does, so the Agent builds both halves itself: sessions on the server, and a roles table the server checks against.

   PromptAdd sign-in and the roles tableCopy

   Add email-and-password sign-up, login, logout, and a server-side session for this app. Then create a roles table linking a user id to one or more of "guest", "host", or "admin". A user can hold more than one, since a host is often a guest on someone else’s listing too. Keep the role check on the server, not in the browser.

   Roles live in their own table, checked on the server. That’s the same rule that keeps a user from promoting themselves, just enforced in code instead of a database function.

4. 04

   Scope bookings and payouts to whoever owns them

   Add the booking and payout tables, then lock every row to the role that should reach it. Replit’s Postgres supports row-level security the same way any Postgres database does, but it has no Supabase auth.uid() to check against, so the Agent has the server set who’s asking before each query runs.

   PromptAdd bookings, payouts, and row-level securityCopy

   Add two tables. Bookings holds which listing, which guest, the date range being reserved, a status, and the price charged. Payouts holds what a host is owed on a given booking once the platform’s cut is set aside. Turn on row-level security on listings, bookings, and payouts. Have the server set the current user’s id and role as a session-local setting at the start of each request, then write policies that read that setting: a guest reaches only their own bookings, a host reaches only the listings and payouts tied to their own account, and an admin reaches everything. Show me how to prove a second guest can’t read the first guest’s bookings before we move on.

   Read this one closely, because it settles who can see whose bookings and whose money.

5. 05

   Bring the search, checkout, and both dashboards online

   This is the part a guest, a host, and an admin all touch by hand: search with filters, a listing page with live availability, checkout, and a dashboard for each of the other two roles. Check the live preview after each screen instead of approving several in a row.

   PromptBuild the screensCopy

   Wire these tables into the screens people actually use. A listings search with filters for location, dates, and price. A detail page that shows live availability. A Stripe-backed checkout that turns a selection into a real booking. One dashboard for a host’s own listings, bookings, and payouts. Another for an admin’s view of listings, disputes, and transactions.

6. 06
   Destination

   Add the last two tables, then publish the app

   Round out the marketplace with reviews and a booking-scoped inbox, click through the whole flow yourself, then publish. Check who the app is visible to before that first release, since that setting is part of what Publishing changes.

   PromptAdd reviews, messaging, and publishCopy

   Round out the schema with a reviews table (tied to a finished booking, hidden until both sides have left one) and a messages table scoped to a single booking rather than one long inbox. Once those are in, help me test the full flow (search, book, pay, message the host, leave a review after checkout), and when it holds up, walk me through Publishing: which deployment type fits this app, and who it should be visible to.

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.

All four are still Replit’s own hosting, not a third-party host. Autoscale or Reserved VM are the two that actually fit a rental marketplace with bookings and payouts behind it. Whichever you pick, review what Publishing changes (the domain, who can see the app, and the machine resources) before the first release.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.