Web app development · Property management
Rent day, work orders and owner statements: web app development for property management
The short answer
A property management web app is usually a portal for residents or owners built on top of the back-office system you already run, not a replacement for it. The hard parts aren't the resident screens. They're the money surface, the integration to your system of record, and load that arrives on one day a month.
You've got a back-office system that runs the accounting, and a portal module bolted onto it that residents complain about and you pay for by the seat. The question isn't whether you could build something better. It's which pieces are worth building, and which ones you'd be rebuilding for no reason.
What you're actually building, surface by surface
A property management web app is almost never one product. It's five or six surfaces with different users, different risk profiles and very different build costs, all of which arrive inside the same sentence when somebody says they want a portal.
The resident screens are the ones everyone pictures and the cheapest part of the work. Pay rent, report a problem, find the lease. They're worth designing properly because they decide whether anyone uses the thing at all, but they're not where a project goes wrong.
What goes wrong sits behind them: anything touching money, and anything that has to agree with the system your accounting already lives in.
| Surface | Who it's for | Where the real difficulty is |
|---|---|---|
| Resident portal | Tenants, and whoever else is named on the lease | Access. Two adults on one lease both need in, one moves out mid-term, and neither should see the other's payment method. |
| Payments and ledger view | Residents paying, staff chasing | Agreement with the general ledger. The balance on the screen and the balance in your accounting have to be the same number, or nobody trusts either one. |
| Work orders and maintenance | Residents reporting, site staff and vendors resolving | Evidence. The photo, the date and who sent it matter years later, and they get captured on a phone in a basement with one bar of signal. |
| Owner portal and statements | The owners of the assets you manage | Reporting. An owner asks why an expense hit their statement, and the answer has to come out of the accounting system rather than be recomputed by your app. |
| Document access | Residents, owners, board members, former tenants | Entitlement. Different people see different slices of the same building, and some of them no longer have an active tenancy. |
| Internal admin view | Your own property managers and site staff | Attribution. Every change your staff makes to somebody's money or tenancy has to be traceable to a named person. |
The integration is the project
You already run a system of record. It holds the chart of accounts, the rent roll, the charges, the receipts and the reports your accountant signs off on. It's probably older than anything else in the business and it's probably the reason the business runs at all.
The instinct, when that system's portal is disappointing, is to replace the whole thing. That's almost always the wrong call. Rebuilding property accounting is a long project with nothing visible to show for most of it, and at the end you own the maintenance of something you used to rent.
The right shape is nearly always the opposite. Keep the system of record where it is, build the surface people actually touch on top of it, and treat the boundary between the two as the main engineering problem rather than a line in the estimate.
Vendors publish these terms, and they're worth reading before anyone scopes anything. Yardi's own interface partner page states that to qualify for its Standard Interface Partnership a company must be two years old and have at least three active Voyager clients, that participation requires an annual licence fee per interface which varies by interface type and in some cases is based on a per-transactional model, and that a separate data exchange agreement has to be signed for each interface type requested. Notice the shape of that eligibility bar. It gates on already having three of the vendor's clients, which is a commercial question rather than a technical one, and it is the kind of thing that decides a project before the first line of code.
Two answers decide how hard that boundary is, and you can get both in an afternoon. First, what your system of record actually exposes: a documented API, a partner programme you have to be admitted to, a nightly file drop, or a screen somebody copies numbers out of. Second, which direction data is allowed to move, because reading a balance out is a very different project from writing a payment back in. What each vendor exposes, and at what contract tier, differs enough that the answer has to come from your own agreement in writing rather than from a product page.
If the honest answer is a nightly file, that isn't a blocker. It's a constraint that reaches all the way to the words on the screen, and it costs almost nothing to find out now.
The money surface is the one that bites
Every property management product has one number that matters more than the rest of the interface put together, and it's the balance a resident sees when they log in.
Get it wrong in either direction and you've made work for yourself. Show a balance that's too high and your phones ring. Show one that's too low and somebody underpays in good faith and gets a notice for it. Neither of those gets reported to you as a display bug.
The failure is usually the same one. The app computes its own balance. Once two systems can each work out what somebody owes, they will eventually disagree, normally over a credit, a partial payment, or a fee applied in a different order. The rule worth holding to is that the accounting system owns the number and the app displays it, even when displaying it is slower and less convenient than calculating it locally.
That gets harder when the sync isn't live. If the ledger updates overnight, a resident who paid at nine in the evening sees yesterday's figure until the morning, and the honest fix isn't to fake the arithmetic. Show what actually happened: a payment submitted this evening, not yet applied. A truthful screen with a pending state beats a confident one that turns out to be wrong.
There's a second category of money in this business that behaves nothing like rent. A property manager holds funds that aren't theirs: deposits, owner distributions, reserve contributions. Those carry rules about where they sit and what they earn, and they're not a display problem. In Ontario the interest a landlord owes a tenant on a last month's rent deposit is set by the Residential Tenancies Act at the annual rent increase guideline in effect when the payment becomes due. If your app reports on deposits, that calculation should come from wherever it's already being done rather than be reimplemented by a developer reading a statute.
Taking rent online without taking on the whole compliance question
The most useful decision you'll make on a build like this is that card data never touches a system you run.
Use your payment provider's hosted payment page, or their hosted fields, so the card number goes from the resident's browser to the provider and your servers never see it. That isn't a security nicety, it's what keeps the compliance work on this project proportionate to the project. The less card data your systems could possibly touch, the smaller the question you have to answer about them.
How you embed it matters, though not the way it is usually described. Under PCI DSS v4.0.1, a redirect to the provider hosted page and a payment form embedded as an iframe served by the provider both fall under SAQ A, the shortest self assessment, because every element of the form comes straight from the provider. What widens your scope to SAQ A-EP is hosting the payment fields on your own page, a direct post or a provider script that builds the form inside your markup, because then your page affects how the card data is transmitted even though it never receives any of it. Either way your site is not fully out of scope, and since 31 March 2025 requirements 6.4.3 and 11.6.1 have required payment page scripts to be inventoried, authorised, integrity checked and monitored for tampering.
Card is also usually the minority rail here. Since October 6, 2022 a property manager in Canada can pass the credit card cost on as a surcharge, capped at the lesser of their own merchant discount rate and 2.4 percent per transaction, disclosed before the payment goes through and shown on the receipt. It cannot be applied to debit or prepaid cards, and it is prohibited in Quebec under the Consumer Protection Act. The card networks call this a surcharge rather than a convenience fee, and convenience fees are not permitted in Canada at all. Bank debit avoids the question, which is part of why it tends to carry the bulk of rent. That changes the product rather than just the checkout, because a bank debit fails days later and quietly, so the retry, the notice and the reconciliation matter more than the payment screen does.
Your load has a date on it, not a curve
Traffic here doesn't build gradually. Rent is due on the same day for every resident you have, so the payment and portal surfaces do most of a month's work inside a few hours on the first, then go quiet.
Growing the portfolio doesn't smooth that out. It makes the same morning taller.
Two practical things follow. Testing has to happen at the spike rather than at the average, because a system that's comfortable at your mean load can be nowhere near ready for the one hour that actually matters. And scaling can be scheduled rather than reactive, because you know the dates a year in advance. Reactive scaling responds after the queue has formed, which on rent day is after your residents have already noticed.
The second and third spikes are worth naming while you're at it. Statement day for owners, and the start of heating season for maintenance requests, which lands on a date set by local by-law rather than by the weather.
A work order is evidence, and ticket software doesn't know that
A maintenance request looks like a support ticket and behaves like a record somebody may have to rely on later.
The photo a resident attaches to a report about a leak is not decoration. It is dated evidence of what the unit looked like on the day it was reported, and it stays relevant well after the repair. For an ongoing maintenance problem the Landlord and Tenant Board treats the breach as continuing until it is fixed, so the one year window to apply runs from the date the repair is completed rather than from the date the problem started. A one off breach is different, and there the year runs from the day it happened. A work order left open for eight months keeps its evidence live a long time after it closes.
So the capture path deserves more attention than it normally gets. Somebody photographs a problem in a basement, on a phone, with almost no signal. The record has to be creatable before the image finishes uploading, the upload has to survive being interrupted, and the file has to carry when it was taken and who sent it rather than only when your server happened to receive it.
The same is true of your own staff, and their side usually gets designed last. A superintendent updating a work order from a stairwell has exactly the connection the resident had, and a form that loses what they typed is how you end up with a maintenance history that lives in text messages instead.
The six answers to get before anyone designs a screen
Most of the expensive corrections on a build like this trace back to a question that was answerable in week one and got answered in month six instead. These are the six, in the order the answers narrow each other. None of them needs a designer, and your own portfolio already holds most of the answers.
1. Decide what the durable object is
In almost every case it's the unit, not the person. A unit outlasts its leases, a lease outlasts the people named on it, and the same person can be a resident in one building and an owner in another. Model the resident as the centre of the system and you can answer this month's questions and none of the ones about what happened in a single unit over five years.
2. Get the real access map out of your own portfolio
Not the roles in a specification, the situations that already exist in your buildings. Two adults on one lease. A guarantor. A resident who moved out last month and still needs a receipt. An owner who owns three units in a building where they also live. A board member entitled to corporation records and not to anyone's ledger. That list is your permission model, and permissions are the piece that can't be retrofitted cheaply.
3. Find out exactly what your system of record will give you
In writing, from the vendor, with a real payload rather than a page from their marketing site. What's readable, what's writable, how often, what it costs you in contract terms, and what your app does on the morning it's unavailable. If the honest answer is a nightly export, design for a nightly export instead of hoping a better one appears.
4. Write the retention schedule before the schema
One row per record type: leases, rent receipts, work orders and their photos, notices served, screening data, applicants who never became residents. Mark which clock starts at creation and which starts at an event like move-out or repair completion. In Ontario a former tenant can ask for a rent receipt for up to a year after the tenancy ends, which means part of your document surface has to serve people who no longer have a login.
5. Name the jurisdictions before you name the features
A portfolio that crosses a provincial line can't hold one lease object. Ontario requires a standard form of lease for most tenancies first entered into on or after April 30, 2018, with care homes, mobile home and land lease sites, most social and supportive housing and co-operative housing outside it, and other provinces either mandate their own form or let you write one that carries prescribed terms. Store the jurisdiction, the form version and the effective date beside every executed agreement, or you'll be opening PDFs one at a time the next time a form is reissued.
6. Decide what happens on the day the sync stops
Not whether it will. Who finds out and how quickly, whether payments taken in the meantime can be replayed into the ledger without creating a second copy of everything, and whether one of your own people can put it right without a data cleanup and a week of apologies. An estimate that priced only the working path is the most common reason the second half of a build looks nothing like the first.
When you shouldn't build this at all
Most property management companies shouldn't build a web app, and it's worth saying that plainly on a page that exists to sell one.
The category is mature. If your requirements list is online rent payment, maintenance requests, document storage and owner statements, that list is the product description of software you can already rent, and building it means paying to rebuild something that works. You'd also be picking up a compliance surface a vendor currently carries for you.
Three situations make building genuinely worth it, and they share a shape: the thing you need isn't on anyone's roadmap, because you aren't the average customer.
1. An asset class the category treats as an edge case
Student housing with per-bed leases and a fixed turnover week. Co-ops with member approval built into the tenancy. One building holding commercial and residential tenants on different statutes. Subsidized housing where rent is calculated from income rather than set. These get handled in spreadsheets running alongside the platform, and the spreadsheet is usually the product worth building.
2. A cost curve pointed the wrong way
A portal charged per seat grows every time you hire, and a portal charged per unit grows on units that may not produce proportional fee income. Either way the cost tracks something other than your revenue, and it keeps climbing after the software stops improving. Yardi states the mechanic plainly for Breeze: billing is based on the number of units you managed during the previous month or the minimum monthly charge for your portfolio type, whichever is greater. AppFolio's entry tier carries a minimum spend and a fifty unit minimum. Check your own agreement against your own growth before you treat any of that as a reason to build.
3. The software is the new revenue line
You've spotted something the category doesn't do and you intend to sell it to other managers rather than only use it. That's a different project with a higher bar: it needs multi-tenancy, a support model and someone accountable for a roadmap. Scope it as a product with customers, not as an internal tool you'll open up later.
Worth knowing before you start
Log in to your current portal as a resident, on your own phone, on the first of the month. Not a demo account on a laptop in a quiet week. Most portal complaints are about the one hour a month nobody on the vendor side is testing.
Ask your back-office vendor in writing what their integration lets you read and what it lets you write, and get the answer before anyone scopes anything. Read-only access changes which product you can build, and finding that out in month three is the expensive version.
Pull your last hundred maintenance requests and count how many arrived by phone, text or a knock at the office door rather than through the system you already pay for. That number is your real adoption rate, and it's the number a new portal has to beat.
Take the ten questions your staff answer on the phone most often and check which ones a resident could answer themselves in under thirty seconds. That's your build list in priority order, and it's usually shorter than the feature list you were handed.
Further reading
Common questions
The system of record, first and usually last. Your platform holds the accounting, the rent roll and the reporting, and the app on top has to read balances and lease data out and write payments and requests back. That boundary is the project. Establish what your vendor exposes, in which direction, and on what contract terms before anything gets designed, because a nightly file drop and a documented two-way API produce very different builds.
That's the first thing to establish, and the answer comes from your vendor rather than from us. Some expose a documented API, some gate it behind a partner programme or a contract tier, and some offer a scheduled file export and nothing else. Reading data out is normally easier to arrange than writing payments back in. Whatever the answer is, it shapes the product, so it belongs at the start of scoping rather than in the middle of the build.
Three things, roughly in order. How your system of record can be integrated with, since a live API and a nightly file produce different products. How many distinct people have to see different slices of the same building, because the permission model is most of the invisible work. And how many jurisdictions your portfolio spans, since each one can bring its own lease form, notice rules and clocks. Feature count matters far less than any of those.
Some, and the amount depends heavily on how you integrate. The approach that keeps it smallest is to let your payment provider host the card entry, through their own page or their hosted fields, so the card number never reaches a server you run. Even then your own page is part of the picture when the form is embedded in it, because it affects how the data is transmitted. Confirm the current requirements against the PCI Security Standards Council's own text, and get your provider to state in writing which ones they satisfy for you.
Eventually, often. First, rarely. Most resident jobs are short and happen away from a desk, which sounds phone-shaped, but a web app that genuinely works in a phone browser covers most of them without an app store in the loop. The stronger case is usually your own site staff, because photo capture on a work order in a basement is the job a browser handles worst. The useful question is which jobs need to leave the browser, not whether every screen should exist twice.
Yes, and mostly in the data model rather than the interface. The lease is a different object in different places: Ontario mandates a standard form for most tenancies first entered into on or after April 30, 2018, Quebec has required its own form for far longer, and some provinces let a landlord write their own as long as prescribed terms are included. Notice periods, deposit rules and record clocks vary alongside it. Store the jurisdiction, form version and effective date with every agreement, and treat anything time-based as configuration rather than a constant in the code.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.