How to build a rental property management app with Bolt
Push an empty project to GitHub, open it in Bolt, and describe your way to a working rental manager: properties, leases, a rent ledger that reconciles, maintenance requests, and a portal each tenant signs into for their own lease.
Bolt
$ Build a rental property manager: properties and units, leases with a rent amount and a due date, a ledger of charges and payments where a payment clears the oldest charge first, repair requests, and a tenant portal scoped to one lease.
- Repository imported
- Ledger and portal built
- Ready to publish
What a rental property management app actually is
It is two applications sharing one database: the side where you run properties, leases, rent, and repairs, and the side where each tenant signs in to see their own lease, their own balance, and the requests they have raised.
Most portfolios are run without one. The leases live in a folder, the rent lives in a bank statement, a spreadsheet holds who has paid, and the repairs live in text messages nobody can find in November. It works until a tenant disputes a balance, or a boiler fails while you are away, or you buy four more units and the spreadsheet stops being something one person can hold in their head.
The part that makes this genuinely hard is the money. Rent is not a payment, it is a charge that comes due on a date, sometimes paid late, sometimes paid short, sometimes paid twice, and every one of those cases has to leave a balance you can defend in front of the person who owes it. Get that right and the rest of the app is properties, screens, and a portal on top of it.
The ledger is the product
Charges on one side, payments on the other, and a balance derived from both rather than typed in anywhere. Once that holds, arrears, late fees, receipts, and the tenant’s own statement all fall out of the same records instead of being tracked separately.
Your tenant is a user of your software
That single decision is what makes this harder than an internal tool. Someone outside your organisation signs in, and they must see their own lease and nothing near anybody else’s - which is a database rule, not a screen that filters.
Rent arrives on a date, not on a click
Charges have to appear on the first, or the fifth, or whichever day each lease says, whether or not anybody opens the app. That means something running on a schedule, and it means being certain that running it twice cannot bill anyone twice.
Who actually owns the rentals
59.6%
of one-unit rental properties are owned by individual investors, against 1.8% held by REITs and real-estate corporations combined - Chandan Economics’ 2026 analysis of the Census Bureau’s 2024 Rental Housing Finance Survey.
Chandan Economics, 2026 (Census RHFS 2024 data) · checked published February 2026
The parts every rental property manager is built from
Two of these six are where the difficulty lives. Knowing which two before you start is most of the planning this build needs.
A ledger you would be happy to show a tenant
Every charge raised, every payment received, and a balance worked out from those two lists rather than stored as a number someone can edit. Decide early which open charge a part payment pays down - oldest first is the convention, and it is worth being deliberate about, because it decides which line goes overdue and which late fee gets raised.
Properties and units, with a status that means something
A property holds units, a unit holds one lease at a time, and a unit is occupied, vacant, or out for works. That status is what turns a list of addresses into an answer to “what can I let next month”.
Leases that carry the money terms
A lease is where the rent amount, the deposit, the start and end dates, the day rent falls due, the grace period, and the late fee live. Put them on the lease rather than in your settings, because two tenants in the same building routinely sit on different terms.
A rent run that goes off on its own
Something that wakes up, finds every lease due today, raises this month’s rent charge, and adds a late fee where one is owed - without anybody opening the app. Build it to check whether it has already billed a period before it bills it, so a retry, a double trigger, or a manual run cannot charge anyone twice.
Maintenance requests with a trail
A tenant reports a problem, it gets a priority, somebody takes it, and it closes. Keep the history of who changed what and when: half the value of tracking repairs at all is being able to show that a request from six weeks ago was answered.
A portal worth signing into
Their lease, their statement, their receipts, their open requests. Get this right and most of the messages you currently answer by text stop arriving, because the answer was already on a screen the tenant can reach themselves.
Own the ledger or rent it by the transaction
The subscription is rarely the interesting number here. Look at two other lines instead: what each product charges to move a single rent payment, and how many doors it expects before it will quote you at all. Those are what decide the cost in year three.
Build your own
An app you own is a one-time build. No fee rides on a rent payment, no minimum door count applies, and with an AI coding tool writing the ledger and the permission rules, the build runs in weeks rather than quarters.
- No per-transaction fee on rent, because you choose the payment rail and negotiate its rate yourself
- No unit minimum and no cap on an entry tier, so four doors and four hundred cost the same to run
- Late fees, grace periods, proration, and which charge a part payment clears all follow your rules rather than a vendor’s defaults
- Your tenants’ names, phone numbers, and payment histories sit in a database you control
- The portal carries your name rather than a vendor’s, which matters when you are asking tenants to trust it
- The records are ordinary rows, exportable the day you want them somewhere else
Rent the rails
Buildium · TenantCloud · DoorLoop · AppFolioWhat renting genuinely buys you is the money infrastructure and the compliance around it. Bank verification, returned payments, chargebacks, tenant screening through the credit bureaus and 1099 filing are all real work, and none of it is the ledger you would enjoy building.
- Rent collection works on day one, with the bank connections and failed-payment handling already solved
- Tenant screening runs through bureau relationships you cannot easily arrange on your own account
- Accounting depth arrives built rather than described: owner statements, bank reconciliation, 1099 e-filing
- Somebody else keeps up with the filing rules and the forms when they change
- Every one of them attaches a fee to moving rent, charged either to you per transaction or to your tenant per payment
- Two of the four put a floor under your portfolio, either a unit cap on the cheapest tier or a 50-unit minimum before there is a price at all
The clearest published statement of what it costs to let somebody else move your rent. The plans run “starting at $62/month”, “starting at $192/month”, and “starting at $400/month”, and each carries its own transaction rate: incoming EFT is “$2.35 per transaction” on Essential, “$1.35 per transaction” on Growth, and “First 12 months free, then $0.60” on Premium. Outgoing EFT is “$0.99 per transaction” and cards “2.99% per transaction” throughout, with “$99 per business bank account” to set up on the entry plan. Multiply the incoming rate by your doors and by twelve before you compare tiers, because on a small portfolio that line can outgrow the subscription. Above 5,000 units the page gives a phone number instead of a price.
buildium.com · checked August 2026
The cheap end, and the one that prices units differently: “Properties & Units” reads “Unlimited” on every tier, so nothing here scales with your door count. What scales is the payment, and the page is explicit about who pays it: “$ 1.95*paid by a tenant” on Starter, falling to “$1.75” on Growth and “$1.50” on Pro. Worth deciding deliberately rather than by default, because passing a per-payment charge to the person paying rent is a choice your tenants will notice. Plans run “$18.00/m” monthly against “$15.00/m” annually, “$35.00/m” against “$29.17/m”, and “$60.00/m” against “$50.00/m”, with Business “Starting at $100.00/mo”.
tenantcloud.com · checked August 2026
Included for the cap rather than the price. The entry tier shows $69 against a struck-through $99, on a basis the page states as “Per month. Billed yearly.”, and it is limited to “Max 10 units”, which is fewer doors than plenty of the individual owners in the statistic above. The higher tiers show $149 and $209 against $189 and $239, Premium carries an “Onboarding fee based on portfolio size”, and past 300 units the page routes you to a demo booking. Every tier also displays “Only $3/unit” alongside its flat monthly figure without reconciling the two, so confirm which one you would actually be billed on before you budget from either.
doorloop.com · checked August 2026
The enterprise end, and the sharpest illustration of who this class of software is sold to. Three plans are named (Core, Plus, and Max) with no dollar figure anywhere on the page; every route is “Get a Quote” or “Chat with an Expert”. The single hard number published is the floor: “Minimum spend and 50 unit minimum apply”. We quote no estimate of the cost, because the vendor publishes none. If your portfolio is smaller than fifty doors, the useful thing to take from this row is not the price but the minimum.
appfolio.com · checked August 2026
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.
Why build with Bolt
Screens are the easy part. What actually stalls a solo build is everything underneath them: somewhere real to hold the data people type in, permission checks on who can see it, and a UI that keeps working once more than one person is using it.
Bolt runs the whole thing in one browser tab, right down to the preview:
Prompt
Describe the screen or rule you want, in plain language.
Preview
Watch the running app rebuild itself in the same tab.
Try it
Click through the real app, because the preview is the actual build rather than a mockup.
Refine
Ask for the next change, or fix what’s off.
None of that needs an install or a terminal window, and the whole build happens in the tab GitHub just opened, one request at a time.
One tabruns the whole build
Bolt runs your project inside the browser itself, via StackBlitz’s WebContainers, so the preview you’re looking at is the app actually running, rather than a screenshot or a separate deploy you have to wait on.
Auto-committed to GitHub as you go
Once GitHub is connected, Bolt commits each working change on its own and pulls in anything you changed elsewhere, so the two stay in sync without you typing a git command.
Built-in database or your own Supabase
Ask for a database and Bolt wires up its own managed one with no extra account, or connects a Supabase project you already run yourself.
Pay a developer, or do it with AI
Two ways to get the same app built: pay a developer for their hours, or spend your own describing it to an AI coding tool. Here is what each one costs to build, and what it costs to keep running once it is live.
Hire a developer
Custom build, from scratch- Developer
- ~$12k-$46k
- Supabase (backend)
- Free tier · $25/mo (Pro plan)*
- Hosting
- $0 free tier
- Build time
- ~230 hrs of their work
~$12k-$46k to build, then from $25/mo after launch
Our ~230-hour estimate, costed against the rate survey linked below. Its bands run through $100-$150+/hour for senior US developers, before the 20-40% an agency adds on top, which brackets a realistic range at roughly $50/hr and $200/hr. Where those hours go is the part worth knowing: the ledger and the permission rules are close to half of it, and neither is visible in a screenshot, which is why quotes for this kind of app come back higher than owners expect.
Build it with Bolt
From scratch, with Bolt- Bolt
- Free (1M tokens/mo) to $25+/month (Pro, from 10M tokens)
- Backend (Supabase)
- Free tier · $25/month (Pro plan)*
- Hosting
- Free on Bolt’s own hosting, or Netlify
- Your time
- ~110 hrs
Free for a first look. A real build costs from ~$25/month on Pro once it outgrows the entry token rung, and climbs from there with usage
Bolt bills by tokens, and the sticker price understates what a real build costs: it reloads your whole project as context on every message, so the entry Pro rung (10 million tokens for $25/month) burns down faster than the number implies. Budget for a top-up or a higher rung on a multi-session build, not the $25 floor. Lean on Bolt’s own token-saving tools (clearing context between features, pointing a prompt at specific files) to slow that burn.
* 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 bolt.new, checked August 2026.
Decide before you build
Six answers to write down first. Every one of them is a product decision about what you are promising your tenants, and each is far cheaper now than after real balances exist in the database.
How rent actually moves
Settle this before the schema. Recording payments (you get paid by transfer or card as you do today, and the app keeps the ledger) is simpler, cheaper, and enough for a great many portfolios. Taking payments inside the app adds a provider, a per-transaction fee, failed-payment handling, and a decision about who absorbs the fee. Retrofitting the other later means rebuilding the ledger.
Whether tenants sign in at all
A landlord-only tool is a much smaller build: one kind of account, one set of access rules, no invitations, no password resets for somebody else’s family. A portal answers most of the messages you currently answer by hand, at the cost of the entire second audience - roughly a third of the work in the estimator above.
What your rent terms actually are
Write your own rules down before anybody builds them: which day rent falls due, whether that differs per lease, how many days of grace, whether a late fee is flat or a percentage or both, how a mid-month move-in is prorated, and which open charge a part payment clears first.
Whose properties these are
Managing your own portfolio and managing other people’s are different applications wearing the same clothes. The second needs owners as a third kind of account, a statement per owner, and a management fee on what you collect. Say so before the data model is written, not after.
What personal data you keep, and for how long
This app holds tenants’ names, phone numbers, addresses, and payment histories - the most sensitive material any of these builds carries. Decide what you genuinely need, what happens to it when a tenancy ends, and how long a closed lease stays queryable.
How a tenant gets their account
Somebody has to be sure the person signing in is the tenant on the lease. A one-time link that expires and cannot be reused is the straightforward answer. Then decide how it reaches them - phone, your own email, move-in day, or a mail service you wire in - because that half is easy to forget until launch.
Comparing your build options
The starting point decides how much of this build is the ledger and how much is everything else. Here is the same app three ways - by hand, on a UI kit that has no idea what a lease is, or in Bolt, working on a repository it keeps in sync as it goes. Starting from the template skips it entirely: those ~110 hours are already written.
Programming complex calculations consumes most of your time and money. Charging rent, processing partial payments, applying late fees, and balancing monthly accounts require invisible logic that can’t just be designed - it must be meticulously coded to prevent costly financial errors.
Starter kits save time on visuals by offering ready-made dashboards, tables, and settings. However, a kit knows nothing about your business rules. You still need developers to program lease logic and configure security - ensuring one tenant never sees another’s financial details.
Instead of writing code, you describe the features you need in plain language and watch the running app rebuild in the same tab. It links your screens to the database itself and sets up the permissions, so you can sign in as a tenant and verify exactly what they can see and access.
Estimate your exact build timeframe
Plenty of landlords need less than this. If your tenants will never sign in, or you would rather import your portfolio by hand once than build a CSV importer, untick those and watch the estimate drop.
Your estimate
110 hrs
start to finish
Based on the 6 of 6 features you’ve selected, plus ~31h of groundwork. Toggle any on the left to watch the number move, and open the groundwork row to untick what you have already, such as a database that is already running or going live if you are only building a mock-up for now.
A rough estimate, not a quote. Real time depends on how much you customize and how clean your data is.
Let’s set up the tools you need
Bolt runs in the browser, but it can’t open a .zip file, so the only way in is a GitHub repository. Do that first, then create a Bolt account and a plan. Everything after that is a plain description of what you want.
GitHub account
Bolt has no upload button for a folder or a .zip, and the only way to open a project is to import a repository, so a home for the code has to exist before Bolt does. Sign up and create a private repository, then push your project’s files to it.
Create a free GitHub accountBolt account
Sign up at bolt.new and connect the GitHub account from the step above. Once it’s linked, you pick a repository to import and land straight in a live preview, with nothing to install.
Sign up for BoltBolt subscription
Free gives you 300,000 tokens a day, capped at 1 million a month, which is enough to try Bolt rather than to finish a real app. Pro starts at $25/month for 10 million tokens (unused ones roll over one extra month), but Bolt reloads your whole project as context on every message, so a multi-session build tends to burn past that entry rung faster than the sticker number implies.
Compare Bolt plansSupabase (database)
Where your project keeps its data. Bolt can wire up its own managed database with no extra account, or connect a Supabase project you already run yourself, and both are Supabase underneath. Ask for one the first time a screen needs to save something real, so you have nothing to set up before you get there.
Connect Supabase to BoltThe GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.
Build your rental manager, one prompt at a time
Bolt opens a project from a GitHub repository rather than an upload, so step 01 happens on GitHub. After that everything is in one tab - and because Bolt reloads your project as context each message, this build is worth doing in the order below, clearing context between the pieces that have nothing to do with each other.
- 01
Create the repository, then import it
The way in. Keep it private from the first commit - this project is about to hold tenants’ names and payment histories.
PromptSet up the projectWith the repository imported, set this project up as React 18 + Vite + TypeScript with Tailwind and the Supabase JS client, reading the Supabase URL and publishable key from environment variables, with .env in .gitignore so neither value is ever committed. Then write a short notes file at the project root: this is a rental property manager, the vocabulary is property, unit, lease, tenant, charge, payment, and ledger entry, a lease balance is always calculated from charges and payments rather than stored, and a tenant account may only ever reach its own lease. Use Plan Mode to talk the file layout through with me before you write anything.
Make the repository private on GitHub before you import it. Bolt commits back to it automatically as you work, and a public repository for an app handling tenant data is a decision you do not want made by a default.
- 02
Plan the ledger before building it
Plan Mode earns its keep here. Talk the money model through, then let it write - and read the preview against a short payment, not a tidy one.
PromptModel the portfolio and the ledgerUse Plan Mode first and talk this through with me before writing code. Connect a database, then design six tables with me: properties, and the units inside them, each unit vacant, occupied, or under maintenance; leases, one tenant to one unit, carrying rent, deposit, term dates, the rent due day, the grace period, and both a flat and a percentage late fee; tenants; charges, typed and dated, each tagged with the period it covers; and payments. Then the arithmetic - a payment is applied to that lease’s oldest open charges first, each fully covered charge is marked paid, and a lease balance is always derived from its charges and payments. Once we agree the plan, build it, seed three leases, and show me the balance after an exact payment, a short payment, and an overpayment.
Plan Mode is worth the extra round trip on this one step even if you skip it everywhere else. Discussing an allocation rule costs a few hundred tokens; rebuilding one after a month of real payments costs considerably more than that.
- 03
Clear context, then add the monthly rent run
A self-contained piece with nothing to do with the screens. Clear the context first so the whole project is not reloaded to write one scheduled function.
PromptBuild the monthly rent runAdd a scheduled server-side function that runs once a day, finds every active lease whose rent day is today, and raises that month’s rent charge - checking first whether a rent charge already exists for that lease and that period and skipping it if so, so running it twice changes nothing. In the same pass, find charges past due by more than their lease’s grace period and add a late fee from that lease’s flat amount, its percentage, or both. Log what each run created. Then show me how to trigger it by hand, run it twice, and confirm the second run adds nothing.
Point this prompt at the database and function files rather than letting it range over the project. Narrower context is cheaper here and it is also more accurate - none of your screens are involved in this change.
- 04
Add both logins and the access rules
Two audiences share this database and one of them is your customer. Check the preview after this step by signing in as each.
PromptAdd auth, roles, and access rulesAdd authentication: email-and-password sign-up, login, logout, a session, and a profile per person, with signed-out visitors sent to the login screen. Then the two roles, landlord and tenant, held in a table of their own rather than on the user account - anything on the account is editable by whoever owns it - plus a helper the access rules can call without recursing, and a link from each tenant record to an account. Then lock the tables down: properties, units, leases, tenants, charges, and payments each get a landlord rule covering the portfolio they own and a tenant rule limited to the one lease that is theirs, with every write checked so a row cannot be filed under somebody else. Then show me how to confirm, signed in as a second tenant, that the first tenant’s statement comes back empty.
- 05
Build the tenant portal, then check it in the preview
The side your tenants see. The preview is the running app, so check it as a signed-in tenant rather than as yourself.
PromptBuild the portal and maintenanceBuild the tenant side. Behind a tenant login: the lease with its terms, a running statement of charges and payments, a form for logging a payment they have already made, and the repairs they have reported. Then the landlord’s view of repairs - the whole portfolio in one queue, with status changes, notes, and a history row per change - where a tenant reports a problem with a description, a priority, and a photo if they have one. Then message threads per tenant, and a notice that goes to a whole building. Point this prompt at the routes and components it touches rather than the whole project, and have every query here read through the access rules instead of filtering in the component.
- 06Destination
Import your portfolio, then publish from Bolt
Your real units and balances, the dashboard over them, then out to Bolt’s own hosting or to Netlify.
PromptImport the portfolio and publishTwo things left. An importer for a spreadsheet of units, tenants, leases, and opening balances: validate row by row, bring in what passes, and keep each rejection with its reason so only those rows need correcting. Then the landlord dashboard - rent roll, arrears and their age, occupancy, and the month’s collections. Then take the whole flow through the preview with me: import a small file, invite a tenant on a single-use expiring link, accept it as that tenant, read the statement, report a repair, log a payment against the oldest charge, and confirm both the balance and the ticket land on the landlord side. When that holds, walk me through publishing and setting the environment variables on the host.
Landlord control, tenant privacy
A person outside your organisation signs in to this one, and must reach exactly one lease. That privacy is enforced by the database rather than engineered by you - here is what does the work, and the part that still needs your attention.
No password handling to build
Sign-up, sign-in, sessions, and password resets all come from your database provider’s own auth service rather than from code you or your AI tool invented. Email and password is the right default for this audience: a tenant signs in a handful of times a month, and anything more elaborate is how a portal ends up unused.
Strict separation: landlord vs tenant
The template ships landlord and tenant, and the tenant role carries unusual weight: the rows it reaches are somebody’s own financial record - what they were charged, what they have paid, what they still owe. A landlord reaches their whole portfolio; a tenant reaches one lease, one statement, and their own requests. Everything else in this section exists to make that line hold.
Protection enforced at the data layer
A tenant portal that filters in the interface is one forgotten condition away from showing somebody another family’s payment history. Row-level security puts the check where the data is served from, so a query that forgets to filter comes back empty rather than embarrassing.
Pre-configured privacy for every table
The template ships 139 row-level security policies, and the count has a structural cause rather than an anxious one: nearly every table needs one rule for the landlord who owns the record and a second for the tenant it is about. Charges, payments, tickets, and messages each carry both.
Roles belong in their own table
Whether somebody is a landlord or a tenant is kept in a separate roles table rather than on the account record, because anything stored on the account is editable by the person it belongs to. A tenant who could rewrite their own role would inherit the portfolio.
Lease documents need rules of their own
A signed lease or a condition report is a file rather than a row, and file storage has its own access rules that have to be written alongside the table’s. A locked-down leases table in front of a readable bucket is the version of this that looks finished and is not.
The invitation is a credential
A tenant’s first sign-in comes from a link, which means that link is as good as their account until it is used. Keep only a hash of it in the database rather than the link itself, let it be used once, and give it an expiry - so a forwarded message or an old screenshot stops working.
Automatic daily backups on Pro
Nothing on the free tier is backed up - your leases and your ledger included. A daily backup with a week of history starts on Supabase Pro at $25/mo, and this is the template where that line is worth reading twice: losing the ledger means a dispute with every tenant at once, which is a different class of problem from losing a draft.
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.
Paste this into the chat before launch so Bolt checks nobody can see data they shouldn’t.
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.
What speeds the build, and what slows it
Speeds the build
- Using Plan Mode to talk a change through before Bolt writes any code
- Pointing a prompt at specific files or functions instead of the whole project
- Clearing Bolt’s context between unrelated features, so each prompt has less to process
- Checking the live preview after each change, since it’s the running app itself
- Reading the automatic GitHub commits later as a real history, not just a backup
Slows the build
- Asking for a whole app in one prompt instead of one screen or rule at a time
- Leaving context loaded from a finished feature while starting an unrelated one
- Editing the repository directly on GitHub and expecting Bolt to pick it up before its next 30-second check
- Approving several prompts in a row without checking the live preview after each one
GitHub: the way in, not just a backup
Bolt can’t open a .zip file, so the only way to start a project is to import a GitHub repository. Every other tool in this set treats GitHub as optional, but Bolt treats it as step one.
Why this comes before Bolt
There’s no upload button for a folder or a .zip. Opening a project in Bolt means pointing it at a repository that already exists on GitHub, so a home for the code has to exist first.
Create a free account, then a repository
Sign up, then create a new, private repository for your project and push your files to it. Keep it private, and never commit secret keys or passwords.
Create a free GitHub accountImport it into Bolt
On bolt.new, connect your GitHub account, choose the repository from the list, and click “Import repository”. The project opens straight into a live preview.
After that, it stays in sync on its own
Bolt commits each working change back to that repository automatically, and checks GitHub every 30 seconds for anything pushed from outside it. A commit is a snapshot with a short note, like “added the home page,” and Bolt writes those notes for you.
Version control and GitHub, Bolt docsIt’s also how you leave, if you ever want to
The repository Bolt is syncing is a real, ordinary codebase: clone it, hand it to someone else, or keep working on it directly on GitHub whenever you’re away from the browser tab.
Where to host your application
Hosting gives your app a home on the internet so anyone can open it via a web link. Choose a service below to make your site live. (Your database, logins, and business records are stored separately in Supabase, covered below).
| Host | Best for | Notes | Free tier |
|---|---|---|---|
| Vercel | One-click deploys | Point it at the repository once and every push publishes itself, with a Vite project needing no configuration at all. Read the plan terms before you start, though: Hobby is personal, non-commercial use only, and letting property is a business by any reading, so a live portfolio belongs on Pro at $20/user/mo. | Pro from $20/user/mo (Hobby is non-commercial) |
| Netlify | Drag-and-drop or Git | Either link the repository or drop the built folder onto the page. A deep link to a tenant’s statement needs one redirect rule, which it writes for a Vite project without being asked. | Free tier |
| Cloudflare Pages | Cheapest at scale | Serves from wherever is nearest the visitor, which is worth something when your tenants are spread across a city and half of them open the portal on a phone. | Generous free tier |
| GitHub Pages | Free Git-based hosting | Serves the site straight from your GitHub project once one routing setting is changed. The catch is specific to this build: free publishing needs a public repository, and the repository for an app holding tenants’ personal data should not be public - so this is free only in a way you would not use. | Free from a public repo only |
| Firebase Hosting | Teams already on Google | One setup, then a single command per release. Worth it mostly if Google is already where your other accounts live. | Free Spark tier |
| AWS Amplify Hosting | Teams already on AWS | Deploy from the AWS console; one rewrite rule keeps a deep link to a tenant’s statement working. Worth it mainly when AWS already handles your other bills. | Free tier (build + hosting) |
| Surge | Publish from the terminal | Publishes the built folder straight from a terminal command, with no repository involved anywhere. Useful for putting a ledger in front of a landlord for ten minutes, not for the app tenants sign into. | Free - unlimited publishing |
| DigitalOcean App Platform | DigitalOcean users | Builds and serves the project from the same account as whatever else you run there, which is the main reason to pick it. | Free - 3 static sites, 1 GB/mo transfer |
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.
Keep your data in Supabase
Leases, ledgers, accounts, and whichever documents you attach. This is also where the scheduled rent run lives, since it has to fire whether or not anybody has the app open.
| Service | Best for | Notes | Free tier |
|---|---|---|---|
| Supabase | Data, auth, functions, files | Postgres for the portfolio and the ledger, auth for both kinds of login, edge functions for the monthly rent run and the imports, and storage for lease documents. Make a free project, hand over the URL and publishable key, and it is connected. The one line to watch on the free tier is the pause after a week of inactivity - fine while you build, not once tenants rely on it. | Free tier, then usage-based |
Choosing your banking system
The application tracks balances, but an external service processes the actual payments. Today that service is whatever you already use, whether that is a transfer, a standing order or a card machine, and it costs you nothing, because nothing here takes a cut. Collecting rent inside the app means picking one of the three below, and rent is the payment shape where that choice matters most.
The cap is the whole reason to choose this: an $800 charge and a $3,000 charge both cost $5, so the fee stops growing with your rents. It pulls on a schedule you set, which is what a monthly charge needs. It also confirms slower than a card does, and a failed payment reaches you days later rather than immediately.
stripe.com · checked August 2026
Built for recurring bank debit rather than adapted to it, on Bacs in the UK and SEPA in Europe, with the same capped shape. Read the international line before you commit: a payment from abroad costs 2% + 20p and carries no cap at all, so check it against your own tenants if any of them pay from another country.
gocardless.com · checked August 2026
No cap, so this one takes a percentage of every rent payment for as long as the lease runs. On $1,500 rent that is about $44 a month, per unit, against $5 on the row above. Keep it as the fallback for a tenant who will not use anything else, rather than as the default.
stripe.com · checked August 2026
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.
Where AI genuinely helps a landlord
Each of these is one more prompt once the ledger works - copy any of them in as they stand. All four reach the model through a single server-side function, which is the only place your key ever sits.
Triage a repair request
Tenants describe problems the way people describe problems. Turning “there’s water coming through the ceiling in the back bedroom” into an urgent plumbing ticket, routed to the right trade, saves the reading and the re-typing.
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.
Draft the arrears message nobody wants to write
Chasing rent is the job landlords put off longest, and lateness costs more the later it is raised. A draft that already knows the balance and the days overdue turns it into an edit rather than a task.
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.
Read the lease and fill in the fields
Every existing tenancy arrives as a PDF or a scan with the rent, the dates, and the deposit buried in it. Typing those into a form for forty units is the single most tedious hour of moving a portfolio into any new system.
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.
Ask the portfolio a question in plain words
The reports you build cover the questions you thought of. The ones you actually ask are things like which units come up for renewal before Christmas, or who has paid late twice in a row.
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.
Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.
Get a head start with our template
The complete rental manager from this guide, already built. Point it at your own database, set your rent terms and fee rules, and start moving your portfolio in today.
Rental Property Manager
The exact property management app this guide builds, packaged so you can open it, point it at your own backend, and make it yours from there. A property management workspace where landlords handle properties, units, leases, tenants, rent, and repairs in one place, while tenants get their own portal. It replaces the spreadsheets and scattered messages that running rentals usually turns into.
The key benefits of starting with a template
The ledger already balances and the portal already keeps tenants apart. That is most of what this saves you - and behind it, the monthly rent run, the maintenance history, the messaging, and the CSV import are done too.
Building the core from scratch
~110 hrs
Opening the template, already built
~1 hr
~109 hrs of building you skip
Two different measurements, deliberately: ~110 hrs is what building the app costs you, and ~1 hr is how long the finished one takes to open, point at your own database, and get your own portfolio into. Setting your rent terms and fee rules takes the same time either way, so neither side counts it.
A ledger that already reconciles
Charges, payments, part payments, and a balance derived from the records rather than stored - with payments applied to the oldest open charge first, which is the convention most tenants and most accountants expect.
Landlord and tenant kept apart
Landlords manage the full portfolio while tenants strictly see their own lease and payment history. Privacy rules are enforced automatically by the database on every request.
All background automation, ready out of the box
Automated monthly rent charges with late-fee rules, protection against duplicate billing, repair request tracking, and tenant invitations are fully configured.
Clean structure your AI can safely customize
The template follows clean, predictable rules so you can ask your AI coding tool to add custom features without risking errors in your financial ledger or security rules.
From founders who build on our templates
I braced myself for a headache building the financial logic, but the ledger and rent runs worked right out of the box. The data structure is incredibly clean, so I could just focus on tweaking the UI and onboarding my first properties. It saved us weeks of development.
Jeevan ThomasFounder & CEO, Hado.aiCommon questions
Not on its own, and that is a deliberate position rather than a gap. The app records what is charged and what has been paid, and keeps the balance right; the money itself arrives however it does today - transfer, standing order, card, cash. If you want rent taken inside the app, that is a payment provider you connect, with its own per-transaction fee to either absorb or pass on. Deciding which way you want it before you build the ledger is the single most useful hour of planning here.
No - that is the part your AI coding tool is best at. Say what you need in plain language and it writes the tables, both kinds of login, the access rules between them, and the job that raises rent each month. The one thing left to you is opening a free Supabase project for it to point at, so your leases and ledgers sit somewhere you own rather than somewhere you rent.
By invitation rather than by signing themselves up, because you need to know the person logging in is the tenant on the lease. The pattern to build is a one-time link that expires and cannot be reused, with only a hash of it stored in your database. How the link reaches them is your call - read out on the phone, sent from your own email, or handed over at move-in.
The database, not the screen. Every table carries access rules checked on each query, so a tenant’s session can only ever return rows tied to their own lease. That is the difference that matters: a page which forgets to filter shows nothing instead of showing somebody else’s payment history.
Nothing, provided you build it to check first - and you should ask for that explicitly. The rule is that the job looks for an existing rent charge for that lease and that month before raising one, so a retry, a duplicate trigger, or a manual run you had forgotten about cannot bill anybody twice. Double-billing is the failure tenants notice fastest and forgive slowest.
Yes, and it is worth building the import rather than typing. Units, tenants, leases, and opening balances all come in from a spreadsheet, and the thing to insist on is that rejected rows are kept with the reason they failed, so a bad date in row 40 does not silently leave one unit out of your rent roll.
A database and a host, both starting free, with Supabase Pro from $25/mo once real tenants depend on it. That last part is not only about limits: free projects pause after a week of inactivity, and an app that is quiet between the 1st of one month and the 1st of the next can hit that. There is no fee on rent in either case, because the app is not the thing moving it.
Yes, with one addition worth planning for up front. Managing your own units needs two kinds of account; managing other people’s needs a third - the owner - plus a statement per owner and a management fee taken from what you collect. All of that is describable in plain words, but it shapes the data model, so decide before it is written rather than after.
Nothing here is proprietary. Leases, charges, payments, and tickets live in ordinary PostgreSQL, so a standard dump gives you the whole portfolio in a form any Postgres host accepts, and attached documents come out of storage the same way. That is worth more in this category than most: the reason portfolios stay on software they have outgrown is usually that the ledger will not come out.
Yes - all of the hosts above attach one in a few clicks, HTTPS included, and it is worth doing before the first invitation goes out. You are asking tenants to sign in somewhere and hand over their details, and a name that is recognisably yours does a lot of that persuading for you.
No. You describe what you want in the chat and Bolt writes the code and shows it running in the same tab. The one extra step Bolt asks for that other browser tools don’t is a GitHub account, since that’s how a project gets in. The setup section above covers it.
Bolt only opens projects from a GitHub repository, and it offers no upload button for a folder. Once it’s imported, Bolt keeps the two in sync automatically, so the extra step up front replaces a manual export later.
Free resets daily, and a paid plan’s monthly allotment resets on your billing cycle (unused Pro tokens also roll over one extra month). If you hit the cap mid-session, what you’ve built stays exactly as it is. You wait for the reset or buy more tokens to keep going right away.
References
Sources checked August 2026- 01Individual investors’ share of one-unit rentals (Census RHFS 2024 data), Chandan Economics. chandan.com (published February 2026)
- 022024 Rental Housing Finance Survey release, U.S. Census Bureau. census.gov (published February 2026)
- 03Pricing (plan tiers, incoming EFT per transaction), Buildium. buildium.com
- 04Pricing (monthly vs annual, tenant-paid ACH fee), TenantCloud. tenantcloud.com
- 05Pricing (entry-tier unit cap, billing basis), DoorLoop. doorloop.com
- 06Pricing (quote-only plans, 50-unit minimum), AppFolio. appfolio.com
- 07Pricing (Pro plan, storage, egress, backups, free-tier pause), Supabase. supabase.com
- 08Web developer hourly rates 2026 (freelance and agency benchmarks). developex.com
- 09Row Level Security, Supabase docs. supabase.com
- 10Storage access control, Supabase docs. supabase.com
- 11Stripe pricing. stripe.com (August 2026)
- 12GoCardless pricing. gocardless.com (August 2026)
- 13Pricing (Free, Pro, Teams), Bolt. bolt.new
- 14Version control and GitHub, Bolt docs. support.bolt.new
- 15Connect Supabase, Bolt docs. support.bolt.new
- 16What is Bolt Cloud?, Bolt docs. support.bolt.new
- 17Netlify deployment (and Bolt hosting by default), Bolt docs. support.bolt.new
- 18Maximizing token efficiency, Bolt docs. support.bolt.new
This guide is general information, not legal, tax, or accounting advice - tenancy law, notice periods, deposit handling, and what you may charge as a late fee vary by country and by state, so check your own rules before you automate anything. Third-party prices, plan limits, and market rates are quoted from the sources above and were last checked on the date shown; vendors change them without notice, so confirm before you budget. Build hours and the cost estimates derived from them are our own estimates, not quotes. Bolt is a product of StackBlitz. Verify current capabilities and pricing before relying on them.