How to build a rental property management app with Claude Code

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 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 and the vocabulary

   An empty app running against your own database, plus a notes file that fixes what your words mean before anything is written twice.

   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 neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a rental property manager - property, unit, lease, tenant, charge, payment, ledger entry - and recording two standing rules: a balance is always derived from charges and payments rather than stored, and a tenant account may only ever reach its own lease.

   Both rules belong in CLAUDE.md rather than in this one message. They are the assumptions every later step depends on, and a stored balance is exactly the shortcut an assistant will reach for when a screen needs to load faster.

2. 02

   Build the ledger against fake leases, before any login exists

   Properties, units, leases, charges, payments, and a balance - with three invented tenancies to test it. Get a part payment and an overpayment behaving correctly here and the rest of the build is screens.

   PromptModel the portfolio and the ledgerCopy

   Write the data model as Supabase migrations, with no authentication yet. Properties, each holding units; units with a status of vacant, occupied, or under maintenance; leases joining a tenant to a unit with a rent amount, a deposit, start and end dates, the day of the month rent falls due, a grace period, and flat and percentage late-fee terms; tenants; charges, each with a type, an amount, a due date, and the month it belongs to; and payments. Then the arithmetic: a function that applies a payment to that lease’s oldest open charges first and marks each one paid when it is fully covered, and a function that derives a lease’s balance from its charges and payments rather than reading a stored figure. Seed three leases and walk me through paying one in full, one short, and one twice, showing what the balance is after each.

   Ask for the three payment cases explicitly. A ledger that handles the exact-amount case is easy; the short payment and the overpayment are where the design either holds or quietly starts lying.

3. 03

   Automate the monthly rent run

   Something that raises this month’s rent on each lease’s own due date and adds late fees where they are owed, without anybody opening the app - and cannot bill the same month twice.

   PromptBuild the monthly rent runCopy

   Add a scheduled Supabase edge function that runs daily, finds every active lease whose rent day matches today, and raises that month’s rent charge. Before raising one, check whether a rent charge already exists for that lease and that period, and skip it if so, so a retry or a manual run cannot double-bill anyone. In the same pass, look for charges that are past due by more than the lease’s grace period and add a late fee using that lease’s own flat amount, its percentage of the charge, or both. Log what it created each run. Then show me how to trigger it by hand twice in a row and prove the second run changes nothing.

   The double-run proof is the point of this step. Ask for it as a demonstration rather than a promise - it is the one bug in this build that reaches every tenant at once.

4. 04

   Add both kinds of login, then the rules that separate them

   Now there is something worth protecting. Two audiences share this database, and one of them is your customer.

   PromptAdd auth, roles, and access rulesCopy

   Add Supabase Auth with 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 out of the user's own metadata so nobody can promote themselves, and a SECURITY DEFINER has_role function. Link each tenant record to an auth account. Then enable row-level security across properties, units, leases, tenants, charges, payments, and ledger entries, with two rules per table: a landlord reaches everything in their own portfolio, and a tenant reaches only rows tied to their own lease. Put explicit WITH CHECK clauses on every insert and update. Then sign in as a second tenant and show me that the first tenant’s charges, payments, and unit come back empty.

   Ask for the proof as a signed-in query, not a description of the policy. Reading a policy and believing it is how a portal ships showing one family another family’s payment history.

5. 05

   Open the tenant portal, and add maintenance

   The side your tenants see, plus the repair requests that are the other half of why they would sign in.

   PromptBuild the portal and maintenanceCopy

   Build the tenant side as its own routes behind a tenant session: their lease and its terms, a statement listing every charge and payment with a running balance, a form to record a payment they have made, and their own maintenance requests. Then maintenance on both sides: a tenant raises a request with a description, a priority, and an optional photo; the landlord sees every request across the portfolio, changes its status, and adds notes - with a history row for each change so who did what and when survives. Add a message thread per tenant and an announcement the landlord can send to everyone in one property. Keep every one of these screens reading through the access rules from step 04 rather than filtering in the component.

6. 06
   Destination

   Import your real portfolio, then use it as a tenant would

   Get your own units and balances in, then open the portal in a private window and look at your own app the way the person paying you will.

   PromptImport the portfolio and test end to endCopy

   Add a CSV import for units, tenants, leases, and opening balances that validates each row, imports the good ones, and keeps every rejected row with the reason it failed so I can fix and re-upload just those. Then add the landlord dashboard: rent roll, what is outstanding and how overdue, occupancy, and what came in this month. Then run the app and take me through the whole thing - import a small CSV, invite a tenant with a single-use expiring link, accept it in a private window, view the statement as that tenant, raise a repair request, record a payment against the oldest charge, and confirm the balance and the ticket both appear correctly on the landlord side - and fix whatever breaks on the way.

   Do the private-window part yourself rather than reading a summary of it. Signing in as your own tenant is the fastest way to find a screen that shows more than it should.

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 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.