How to build a rental property management app with OpenAI Codex

Rule of thumb: if what you want is rent collected for you, screening run for you, and 1099s filed for you, buy it, because those are the parts that are genuinely tedious to arrange alone and the per-transaction fee is what they cost. If what you want is a ledger that matches how your leases actually work, a portal with your name on it, and no floor under your door count, build it. The middle case is a small portfolio that will grow, and there the number to look at is the fee on an incoming payment multiplied by your doors and by twelve, because that is the line that grows with you whether or not the subscription does.

* One line on the free tier matters more here than on most builds. Supabase Free includes 500 MB of database space, 1 GB of file storage, and 5 GB of egress a month, and it pauses a project after a week of inactivity - which is a real risk for an app whose busiest day is the 1st and whose quietest stretch is everything between. Pro, from $25/mo, removes the pause, raises storage to 100 GB (then $0.0213 per GB) and egress to 250 GB (then $0.09 per GB), and adds a daily backup with 7 days of history. Before you have tenants signing in, Free is fine; the day you send the first invite, the pause is the reason to move.

Neither column takes a cut of rent, because the app records payments rather than moving them, so the running cost is a database and a host and nothing else. That bill does not move when rent does: ten doors and two hundred cost the same to host, and the only thing that grows is the storage under whatever lease documents you keep.

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

   Write AGENTS.md before anything is scaffolded

   Codex loads AGENTS.md at the start of every task, so the two rules that govern this whole build are in front of it before there is any code to break them.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is a rental property manager. Fix the vocabulary - property, unit, lease, tenant, charge, payment, ledger entry - and record two standing constraints: a lease balance is always computed from its charges and payments and never stored as a column, and a tenant account may only ever reach rows belonging to its own lease. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The stored-balance rule is the one worth writing down. Caching a balance is a reasonable-sounding optimisation for any assistant to propose later, and it is how a ledger and a statement start disagreeing with each other.

2. 02

   Give the ledger its own task, and read that diff closely

   The largest piece of genuinely tricky logic in the build. Keep it in one task, ask for the SQL before it runs, and test the awkward payments rather than the tidy one.

   PromptModel the portfolio and the ledgerCopy

   Write the data model as Supabase migrations, with no authentication in this task. Six tables. Properties, and the units belonging to them, each unit vacant, occupied, or under maintenance. Leases, tying one tenant to one unit and carrying the money terms: rent amount, deposit, start and end dates, which day of the month rent is due, how many days of grace follow it, and late fees as both a flat amount and a percentage. Tenants. Charges, each typed, dated, and tagged with the period it covers. Payments. Then two database functions: one allocating a payment against that lease’s oldest open charges first and marking each fully covered charge paid, and one deriving the lease balance from its charges and payments. Show me the SQL before you run it. Then seed three leases and walk through an exact payment, a short payment, and an overpayment, printing the balance after each.

   This is the task to spend a round trip on. Asking for the SQL first is cheap; finding out in November that part payments were allocated newest-first is not.

3. 03

   Schedule the rent run, and prove it is safe to repeat

   A well-specified, self-contained task with a clear test at the end - the kind that suits a cloud run if you would rather not sit through it.

   PromptBuild the monthly rent runCopy

   Add a scheduled Supabase edge function that runs daily, selects every active lease whose rent day is today, and raises that month’s rent charge - skipping any lease that already has a rent charge for that period, so repeating the run is harmless. In the same pass, look for charges that have sat past their lease’s grace period and raise a late fee on each, taking the flat amount, the percentage, or both from the lease itself. Have it log what it created. Then run it twice in a row against the seed data and show me that the second run creates nothing.

   If you hand this one to a cloud run, read the diff before merging it. The guard against double-billing is one condition, and it is invisible in a summary of what changed.

4. 04

   Narrow Codex’s permissions, then add the two logins

   This task touches authentication and writes the rules protecting other people’s data - exactly the kind of change worth scoping down for rather than leaving whatever settings you use for routine edits.

   PromptAdd auth, roles, and access rulesCopy

   This task touches authentication, so narrow your permissions to just this one. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, and a useUser hook. Add an app_role enum of 'landlord' and 'tenant' with a user_roles table kept off the account itself, since anything stored there is editable by its owner, plus a SECURITY DEFINER has_role function, and link each tenant record to an auth account. Then row-level security across properties, units, leases, tenants, charges, payments, and ledger entries, with two rules per table - a landlord reaches their own portfolio, a tenant reaches only what belongs to their lease - and an explicit WITH CHECK on every insert and update. Show me the policies as SQL before they run, and then walk me through querying as a second tenant to prove the first tenant’s rows come back empty.

   Two audiences means roughly twice the policies, and a table nobody thought about is the one that leaks. Ask for the list of tables it covered and check it against your own schema rather than assuming the set was complete.

5. 05

   Build the tenant side and maintenance

   Two features that share a boundary: everything here is read by somebody outside your organisation, so every query goes through the rules written in step 04.

   PromptBuild the portal and maintenanceCopy

   Build the tenant portal in this task, then maintenance. The portal sits behind a tenant session and shows four things: the lease with its terms, a running statement of charges and payments, a form for recording a payment already made, and the requests that tenant has raised. Maintenance spans both audiences - a tenant files a description, a priority, and optionally a photo, and the landlord works one queue across the whole portfolio, moving status and leaving notes, with every change writing a history row. Finish with a message thread per tenant and a notice the landlord can post to an entire building. No screen here may filter in the component: they all read through the policies from the previous task, and I want you to flag in the diff anywhere you were tempted to do otherwise.

6. 06
   Destination

   Hand the import to a cloud run, then test it as a tenant

   A CSV importer and a dashboard are self-contained and well specified - a reasonable pair to hand off while you do something else, provided you read the diff before it merges.

   PromptImport the portfolio and test end to endCopy

   Two remaining pieces, both self-contained. First, a CSV import for units, tenants, leases, and opening balances that validates each row, imports the valid ones, and stores every rejected row with the reason it failed so I can fix and re-upload only those. Second, the landlord dashboard: rent roll, outstanding balances with how overdue each is, occupancy, and collections this month. When they are in, run the app and take it end to end yourself - import a small CSV, invite a tenant with a single-use expiring link, accept it as that tenant, read the statement, raise a repair request, record a payment that clears the oldest charge, and confirm the balance and the ticket both show correctly on the landlord side - then fix whatever does not 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: the database service key, and any provider key you add later, never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

Any of these will serve the app. Two things to check rather than one: whether the plan permits commercial use, since Vercel’s Hobby tier does not and rent is commercial by any reading; and whether it can publish from a private repository, because the code sits next to an app holding tenants’ personal data and the repository should not be public.

Work out one number before you connect anything: the fee on a single incoming payment, times your doors, times twelve. On twenty units at $1,500, capped bank debit costs about $1,200 a year and cards about $10,500, for the same money arriving. Connecting nothing is still a real answer: the ledger is correct either way, and a landlord who is happy to be paid by transfer pays none of this.

Add a step when a tenant submits a maintenance request that sends the description and any photo caption to a server-side function calling an AI model, and returns a suggested category, a suggested priority, and a one-line summary for the ticket list. Show them as suggestions the landlord can accept or change rather than applying them silently, and never let the suggestion downgrade something the tenant marked as an emergency.

Add a "Draft a reminder" action on a lease with an outstanding balance. Send the amount owed, which charges are unpaid, how many days overdue each is, and the tenant’s payment history for the last few months to your ai function, and return a short, factual message in a tone I choose - a first friendly nudge, a firm follow-up, or a formal notice. Always show it as an editable draft, never send it automatically, and state the figures rather than describing them vaguely.

Add an upload on the lease form that sends an existing lease document to your ai function and returns the fields it can find - rent amount, start and end dates, deposit held, the day rent falls due, and any late-fee terms - as a pre-filled form for me to check before saving. Mark each field with how confident the extraction was, leave anything ambiguous blank rather than guessing, and keep the original document attached to the lease.

Add a question box on the dashboard that turns a plain-language question about my portfolio into a read-only query against my own data and shows the answer as a small table I can export. Send the schema rather than the records to the model, run only SELECT statements, apply the same access rules as the rest of the app so it can never read past what the signed-in account is allowed to see, and show me the query it ran alongside the answer.

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.