How to build a rental property management app with Replit

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 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 the app, ask for the database, and set the rules

   The database comes free with the workspace, so it goes in the opening message - along with the two rules the rest of the build depends on.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind and a server, and add a Postgres database to this Repl - the one Replit provisions, not anything outside. Write a short notes file at the project root recording three things: that this is a rental property manager; that the words throughout are property, unit, lease, tenant, charge, payment, and ledger entry; and two standing rules - a lease balance is derived from its charges and payments and never stored, and a tenant account reaches nothing outside its own lease. Keep the database connection details in Replit's Secrets rather than in the code.

   Write both rules into the notes file rather than only into this message. A stored balance is the shortcut any assistant will reach for when a dashboard feels slow, and it is the one that makes a statement and a ledger disagree.

2. 02

   Build the ledger, and check it at a checkpoint

   The money model, against three invented leases. Take the awkward payments seriously here - this is the part that is expensive to fix once real rent has been recorded.

   PromptModel the portfolio and the ledgerCopy

   Design the schema and the server routes over it. Start with properties and the units they contain, where a unit reads as vacant, occupied, or under maintenance. Then leases: one tenant, one unit, and the money terms - rent, deposit, term dates, the day rent falls due, the grace period, and a late fee expressed both as a flat amount and as a percentage. Then tenants, then charges carrying a type, an amount, a due date, and the period they cover, then payments. Then the arithmetic: a payment clears that lease’s oldest open charges first and marks each fully covered charge paid, and a lease balance is always derived from its charges and payments. Seed three leases, then show me in the preview what the balance is after an exact payment, a short payment, and an overpayment.

   This is the step where checkpoints earn their keep. A rollback here also offers to take the database with it, which is exactly what you want while the only rows are seeds - and exactly what to think twice about later.

3. 03

   Add the rent run as a scheduled job

   Rent has to be raised on the 1st whether or not anybody has the app open. Replit has a deployment type for precisely this shape of work.

   PromptBuild the monthly rent runCopy

   Write a task that raises this month’s rent on every active lease whose rent day is today. Before it writes a charge, have it look for one already covering that lease and that period and skip if it finds one, so a repeat run is harmless. In the same pass, add late fees to anything sitting past its lease’s grace period, taking the flat amount, the percentage, or both from the lease itself. Have it log what it created. Then tell me how to run it as a Scheduled deployment once a day, and how to trigger it by hand so I can run it twice and confirm the second run adds nothing.

   Ask which deployment type this belongs on, and expect the answer to be a separate one from the app itself. A daily task and a web app want different shapes, and Replit publishes both from the same workspace.

4. 04

   Add sign-in, then scope every row to the account asking

   Replit’s Postgres is a plain database with no login wired into it, so the Agent writes both halves: sessions on the server, and policies the server’s identity feeds.

   PromptAdd sign-in, roles, and access rulesCopy

   Add email-and-password sign-up, login, logout, and a server-side session, with a profile row per account. Add a roles table giving each account either landlord or tenant - in its own table, never on the account record, since anything there is editable by that user - and link each tenant record to an account. Then turn on row-level security across properties, units, leases, tenants, charges, and payments: have the server declare the current account and its role as a session-local setting at the start of every request, and write two policies per table that read it - a landlord reaches their own portfolio, a tenant reaches only rows tied to their own lease. Then show me how to prove, as a second tenant, that the first tenant’s statement comes back empty.

   There is no ready-made login handing the database an account id here, so the server is what knows who is asking. Build that first and the policies have something to read.

5. 05

   Build the tenant portal and maintenance

   The side your tenants use, and the repair requests that give them a reason to come back to it.

   PromptBuild the portal and maintenanceCopy

   Build the tenant side. Behind a tenant session, four things: their lease and what it commits them to, a statement running charges against payments, a way to log a payment they have already sent, and the repairs they have reported. Then repairs for the landlord - the portfolio in one queue, with status changes, notes, and a history row on every change - where a tenant reports a description, a priority, and optionally a photo. Then a message thread per tenant, and a notice for a whole building. Every route here has to set the session-local account and role before it queries anything, or the step 04 policies pass everything and the portal is wide open.

6. 06
   Destination

   Import your portfolio, then publish twice

   Your real units and balances, the dashboard over them, then Publishing - the app on one deployment and the daily rent run on another, with a careful look at who the app is visible to before the first invitation goes out.

   PromptImport the portfolio and publishCopy

   Two things left. An importer taking a spreadsheet of units, tenants, leases, and opening balances - each row validated, the passing ones brought in, and every rejection kept with its reason so only those need fixing. Then the landlord dashboard: rent roll, arrears with their age, occupancy, and collections this month. Then help me test it end to end - a small file imported, a tenant invited on a single-use expiring link and accepted as that tenant, the statement read, a repair reported, a payment logged against the oldest charge, and the landlord side showing both the new balance and the new ticket. When it holds up, walk me through Publishing: which deployment type fits the app, which fits the daily rent run, and who the app 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: the database connection, the invitation signing secret, and any AI 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.

For this build that means Autoscale for the app and Scheduled for the daily rent run. Review who the app is visible to before that first release, since Publishing is what sets it, and remember that the moment you send a tenant an invitation, the app is something somebody outside your organisation depends on.

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.

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.