How to build a rental booking platform with OpenAI Codex

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 learn.chatgpt.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 Codex runs the commands.

1. 01

   Bootstrap the project behind an AGENTS.md file

   Wire up an empty app that talks to your database, and hand Codex an AGENTS.md file so its conventions carry forward without you repeating them. One task covers the whole setup.

   PromptSet up the projectCopy

   Before you scaffold anything, write an AGENTS.md at the project root covering the stack (React 18, Vite, TypeScript, Tailwind, the Supabase JS client) and whatever conventions you want kept from here on. You’ll load that file automatically at the start of every task after this one, so nothing in it needs repeating by hand. Then build the project itself: wire up a typed Supabase client under src/lib, pulling VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, and confirm .env is already listed in .gitignore so neither value can reach GitHub. Start the dev server once to prove it boots clean before you stop.

   Writing AGENTS.md before the scaffold means every later task opens already knowing your stack and conventions, with nothing to remind Codex of by hand.

2. 02

   Write the listings and availability migrations

   Hand Codex the two things a marketplace can’t work without: a listing, and a calendar that can never double-book it. Have it show you the migration before anything touches your database.

   PromptSet up listings and availabilityCopy

   Write the Supabase migrations for the two tables this marketplace can’t run without. A listings table, owned by a host, holding a title, description, location, amenities, a base nightly price, and photos stored in Supabase Storage. And an availability table recording which date ranges are already booked on each listing, with a constraint or trigger that blocks any insert whose dates overlap a confirmed booking already on file, so two guests can never land on the same night. Print the SQL for me before it runs, and once it’s applied, regenerate the TypeScript types.

   Enforce the overlap check as a database constraint, not application logic. Only the database sees every write, no matter which screen or script made it.

3. 03

   Wire up sign-in and the role model

   Layer sign-up and login on top, followed by a guest/host/admin role model that lets one account carry more than one role. Auth is exactly the kind of sensitive change worth narrowing Codex’s permissions for, so scope it down to just this task first.

   PromptAdd auth and rolesCopy

   This task touches authentication, so scope your permissions down to just this one rather than leaving the broader session settings you’d use for routine edits. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, and a useUser hook. On top of that, build out the role model: an app_role enum covering 'guest', 'host', and 'admin', and a user_roles table that links a user_id to a role rather than storing it on the account itself. An account should be able to carry more than one, since a host is often a guest on someone else’s listing too. Add has_role(_user_id uuid, _role app_role), a SECURITY DEFINER function reading from user_roles, so the policies coming in the next task can call it without recursing into itself. One migration for all of it, and walk me through what changed before it runs.

   A role kept in the user’s own metadata is editable by that same user, so has_role reads from a separate table instead.

4. 04

   Review the diff that locks bookings and payouts

   Layer in the booking and payout tables next, then have the database enforce who can reach which rows. Read this diff closely before you approve it. It’s the one that decides who can see whose money.

   PromptAdd bookings, payouts, and RLSCopy

   Add two tables: bookings (a listing plus a guest, with check-in and check-out dates, a status, and the total price) and payouts (a host plus a booking, with the platform’s cut split out from the host’s share). Turn on row-level security across listings, bookings, and payouts, and write the policies so a guest only reaches bookings they created, a host only reaches the listings and payouts tied to their own account (test ownership with has_role), and an admin, also verified through has_role, can reach every row for moderation. Every insert and update needs its own WITH CHECK clause naming exactly who is allowed to own the new row, so nobody can insert a booking or payout under someone else’s name. Once it’s applied, walk me through proving it: a second guest reading the first guest’s bookings should fail, a host reading another host’s payouts should fail, and an admin reading either should succeed.

   Without this, one guest could browse another guest’s bookings, or one host could see what another host is earning.

5. 05

   Wire up each screen from the files it actually needs

   Point Codex at the frontend now: search with filters, a listing page with live availability, checkout, and dashboards for hosts and admins. It only needs the handful of files each screen actually touches, not the whole project.

   PromptBuild the screensCopy

   Wire up the screens on top of what you’ve built so far: listings need a search page with location/date/price filters, a detail page that shows live availability, and a checkout flow that creates the booking and takes payment through Stripe. Hosts need a dashboard covering their listings, bookings, and payouts. Admin needs a dashboard covering listings, disputes, and transactions. Keep the data access itself in typed hooks rather than scattered through the components.

6. 06
   Destination

   Round out reviews and messaging, then verify it

   Add the last pieces, reviews and a booking-scoped inbox, then run the app yourself and walk the whole flow end to end, fixing whatever’s off as you go.

   PromptAdd reviews, messaging, and testCopy

   Add the last two tables: reviews (tied to a completed booking, released once both sides have left one) and messages (a booking-scoped inbox between guest and host). Once that’s in, run the app yourself and take it end to end (search for a stay, book it, pay, send the host a message, leave a review after checkout), then fix whatever doesn’t hold up.

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 should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.