How to build a rental property management app with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Generate one screen, to fix the shape

   Start with the screen you will look at most. It is faster to argue with a rendered rent roll than with a description of one.

   PromptGenerate the landlord shellCopy

   Build the landlord side of a rental property manager as a Next.js app with Tailwind: a sidebar with Properties, Leases, Accounting, Maintenance, and Tenants, and on the first screen a portfolio view listing properties with their units, each unit marked vacant, occupied, or under maintenance, and each occupied unit showing its tenant, rent amount, and current balance. Use placeholder data for now, and keep the vocabulary consistent throughout - property, unit, lease, tenant, charge, payment. We will connect a real database in the next step, before anything calculates money.

   Keep this to one screen. The point is to settle the layout and the words while changes are cheap, not to generate an app you then have to re-point at real data screen by screen.

2. 02

   Connect a database before anything counts money

   The one step not to defer. A ledger built against placeholder data is a ledger you will build twice.

   PromptConnect Supabase and model the portfolioCopy

   Add the Supabase integration to this project, then design the schema and the API routes over it. A properties table and a units table, where a unit is vacant, occupied, or under maintenance. A leases table joining one tenant to one unit, holding the rent, the deposit, the start and end dates, the day of the month rent falls due, the grace period, and late fees as a flat amount and as a percentage. A tenants table. A charges table, where each row has a type, an amount, a due date, and the period it covers. A payments table. Write server-side routes for reading and writing each of them, repoint the portfolio screen from step 01 at real data, and seed three leases so there is something to look at.

   Ask for the routes in the same message as the schema. Screens that read the database directly from the browser are the ones that get awkward later, when the same query has to be enforced for two different kinds of account.

3. 03

   Build the ledger, and the rent run behind it

   Charges, payments, a balance derived from both, and a job that raises rent on schedule without ever billing a month twice.

   PromptBuild the ledger and the rent runCopy

   Build the accounting side. A ledger per lease listing every charge and payment with a running balance, an action to record a payment received, and a server-side rule that applies a payment to that lease’s oldest open charges first and marks each fully covered charge paid. Always calculate the balance from the records rather than storing a total. Then add a scheduled job that runs daily, raises this month’s rent charge on every active lease whose rent day is today, skips any lease that already has a rent charge for that period so a repeat run is harmless, and adds late fees for charges past their grace period. Show me the ledger after an exact payment, a short payment, and an overpayment.

   Both halves belong in the same chat. The rent run creates the charges the allocation logic consumes, and splitting them across chats is how the two end up with different ideas about what a period is.

4. 04

   Add both logins, then make the routes obey them

   Two audiences, one database, and a tenant portal that is about to exist. Rules go in before the portal, not after - and the routes you already wrote have to run under them.

   PromptAdd auth, roles, and access rulesCopy

   Add Supabase Auth to this project: email-and-password sign-up, login, logout, and a session, with signed-out visitors sent to the login page. Add two roles, landlord and tenant, in their own table rather than on the user account itself, since anything stored there can be edited by its owner, plus a helper function the access rules can call without recursing, and link each tenant record to an account. Then put row-level security on all six tables, a pair of rules on each - one scoping a landlord to the portfolio they own, one scoping a tenant to the single lease that is theirs - plus a check on every write that the row belongs where it is being filed. Make every API route you wrote earlier run under the signed-in user’s session so those rules actually apply, rather than under a service key that bypasses them.

   The last sentence is the one to keep. Server-side routes are easy to write with a key that ignores every policy you just wrote, and the result looks perfect until a tenant reads somebody else’s statement.

5. 05

   Give the tenant portal its own chat

   A separate audience with a separate set of screens - a clean boundary, and a good use of one feature per chat.

   PromptBuild the portal and maintenanceCopy

   In a new chat on this project, build the tenant portal. Four screens behind a tenant session: the lease with its terms, a running statement of charges and payments, a form for logging a payment already made, and that tenant’s own reported repairs. Then the repairs side for the landlord - a single queue over the portfolio, status changes, notes, and a history row written on each change - with tenants reporting a description, a priority, and an optional photo. Add message threads per tenant and a building-wide notice. Every route in this chat runs under the signed-in tenant’s session rather than a service key, so the access rules actually apply.

   A fresh chat gives this feature its own branch and its own straight-line history, which matters more here than elsewhere: the portal is the piece you are most likely to revise after somebody outside your organisation looks at it.

6. 06
   Destination

   Import your portfolio, merge, and deploy

   The last build task, then the pull request that puts it live - and a walk through the whole thing as a tenant first.

   PromptImport the portfolio and ship itCopy

   Two things left. An importer that takes a spreadsheet of units, tenants, leases, and opening balances, validates it row by row, brings in whatever passes, and holds each failure with its reason so only those rows need fixing and resubmitting. Then the landlord dashboard: rent roll, arrears with their age, occupancy, and collections for the month. Then take me through a test run - a small file imported, an invitation issued on a single-use expiring link, that link accepted as the tenant, the statement read, a repair reported, a payment logged against the oldest charge, and the landlord side agreeing on both. When it does, tell me what to look for in the pull request before I merge.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.