Mobile apps for property management, and the two people who use them

Start by asking whether it needs to be an app

Look at what people are actually asking it to do. Pay rent. File a maintenance request. Read the notice about the water being off. Book the party room. Every one is a form or a list, and a responsive web page does all of them. A resident adds it to their home screen where it sits next to everything else.

That version is cheaper, and better in one way that matters every week: no review queue between you and a fix. You change it on a Tuesday afternoon and every resident has it that afternoon.

Three things break that argument, and they're the real reasons to pay for a native build. The first is push. Since iOS 16.4, Safari delivers a web push notification only to somebody who added your site to their Home Screen first. That's a step most residents won't take, so your reach depends on the one behaviour you can't make happen. If you're building this to tell 400 units the water goes off at six, that alone can settle it.

The second is the camera, used in volume rather than as a file picker. The third is staff working where the signal is gone, which here is a normal Tuesday.

A fourth reason gets given: a leasing agent can say "download our app" during a showing. That's marketing, and if it's your only reason, say so out loud.

Two users who share nothing except the building

A resident opens this a handful of times a year, because something is wrong or rent is due, and they've forgotten whatever they worked out last time. Nobody trains them and nobody can. They arrive at move-in and leave at the end of a lease, so by the time somebody is good at your app they've moved out.

The superintendent has it open all day. Same four actions, forty times, and what they want from your interface is fewer taps. The confirmation dialog that reassures a resident is, to them, an obstacle they hit forty times before lunch.

One product, two people with opposite needs. The apps that fail get it wrong in the same direction: they build the staff app and hand it to residents, because the staff were in the room during scoping.

Here's how we resolve it, and the shape holds whether we build it or you do.

1. 1. Split the shell, share everything underneath

   One codebase, one back end, one set of rules about what a work order is. What differs is the shell: sign-in decides which of two home screens somebody lands on, and they never see the other. Two store listings mean a second submission, a second review queue and a second install to chase.

2. 2. Let residents describe, let staff categorize

   It's tempting to put your maintenance taxonomy in front of residents so requests arrive pre-sorted. Don't. Somebody choosing between "plumbing, fixture" and "plumbing, supply" picks wrong, and your intake data is confidently wrong instead of honestly vague. Take a photo, a sentence and a room. Triage is a staff action, done by somebody who knows the riser.

3. 3. Design one path for the first time and one for the fortieth

   The resident path assumes no memory: one obvious action on the home screen, plain language, no dead end that needs knowing where to look. The staff path assumes total familiarity: a list you move down without leaving it, no confirmation dialogs, an undo instead. Apply either to the wrong surface and somebody stops opening the app.

4. 4. Decide who the phone belongs to

   Building staff often share a device, or the phone stays with the building while the person changes. That raises questions a resident app never faces. How fast you switch user at a shift change, how long a session lasts, what stays on the device between shifts, and what happens to a half-finished inspection at handover.

5. 5. Write two definitions of done

   The resident surface is done when somebody who has never seen it finishes the task without calling the office. The staff surface is done when the person doing it forty times a day stops using the paper instead. A superintendent's opinion of the resident screens is worth very little, and the reverse is worse.

Push is the point, and the easiest thing to waste

For a property manager the notification is the product. The alternative is a phone call, an email nobody opens, or somebody printing 200 notices and taping one to every door at ten at night. That's the comparison, and it's why the water shutoff notice often pays for the build.

Which is why it's worth being careful with. The permission prompt is one ask, and every message after it spends a balance you can't top up. You can't win a resident back with a campaign either. They still live in your building, they've turned you off, and the next time the water goes off at six you're back to a door notice.

So the rule worth holding is a test. If a message wouldn't have justified a piece of paper taped to a door, it doesn't justify a push. That produces tiers, and the tiers set the default state of each switch, because hardly anyone changes them.

The camera is the work order

"There's water in the bathroom" is not information. It's a dripping shut-off valve, or it's a failure in the riser about to reach four units below, and the difference decides whether somebody goes in twenty minutes or on Thursday. A photo settles that from the office without a second trip.

So the first screen of a maintenance request should be the camera, not a dropdown. The resident is standing in the bathroom looking at it, and every field ahead of the photo is a chance for them to give up and phone the office instead.

The engineering underneath is more than it looks. Photos off a modern phone are large, and a resident on one bar in a basement unit will abandon an upload that sits there spinning. Compress on the device, queue it, upload in the background, and say it's submitted the moment it's saved locally. A request that quietly failed to upload is worse than no app at all. They think you know, and you don't.

The photo that earns its keep is the one the super takes at close-out. Before and after, timestamped, attached to the work order. Eighteen months later that’s what you have when a tenant says the repair never happened, when an insurer asks, or when the same damage comes up at move-out. What weight any of it carries in a hearing is a question for your own counsel, but having it beats reconstructing the week from memory.

One caution comes with it. These are photographs of the inside of people’s homes. Decide who can see them, how long you keep them and whether they’re stored outside the country, and decide it during design. Which privacy law applies depends on where you operate, because Quebec, British Columbia and Alberta have their own private-sector statutes and the federal law covers commercial activity elsewhere. Keeping every maintenance photo forever because storage is cheap is a decision, and the wrong one.

In a building, offline is the normal case

The places building work happens are the places where the signal dies. The lower parking levels. The boiler room. The elevator machine room. The roof access stair, and whatever mechanical space sits furthest below grade. That isn't the exception here, it's where a superintendent spends a good part of the day.

The building's own wifi doesn't rescue you. It's in the lobby and the amenity rooms because that's where residents asked for it, and it stops at the top of the parking ramp.

So the staff surface is offline-first rather than offline-tolerant, which is architectural, not a setting. The day's work list is on the device before they leave the office. Everything captured writes locally first and syncs when there's signal. The screen stays honest about which state each record is in, because a super who believes a job is closed isn't going back to check.

Three questions get skipped and all three come back. What happens when the day super and the night super edited the same work order from two queues, since the default resolution is rarely the one your operation wants. What happens to a queued photo when the phone is wiped, replaced or handed on. And what happens to an item that sat in the queue for a week. A queue with no answer loses work quietly, and once is enough to send staff back to the clipboard.

A fix isn't live when you merge

On the web you fix it and it's fixed. On mobile there's a review queue between you and your buildings, and behind it every resident who hasn't updated anything since they moved in. Review itself is usually quick. What costs you calendar time is a rejection, because the fix goes back to the end of the line.

The first consequence is specific to this business. Your busiest weeks are known a year in advance, because leases turn over on the first of the month and most portfolios have a turnover season they can name without looking it up. So freeze the release before turnover week, because that’s when the app matters most and when you least want to be waiting on a reviewer.

The second is that anything you'd want to change on a Tuesday has to be changeable without a release. That's a design requirement, not a preference. The after-hours emergency number. The maintenance categories. The amenity rules. If your emergency line is compiled into the app because it never changes, the week it changes costs you a submission and a wait while residents call a number nobody answers.

Old versions stay installed a long time here, because a resident who set the app up at move-in and opens it twice a year is running last year's build. Decide up front which screens may force an update. Paying rent probably should. The notice board shouldn't, because a resident locked out of it rings the office, which is the exact cost the app existed to remove.

Settle these before anybody writes code

None of this needs an agency. It's a week of your own time, and it moves the scope enough to be worth doing whether or not you build anything.

1. 1. Count a week of what actually reaches the office

   Every call, email and walk-in for five working days, tallied by what it was about and who took it. Most managers guess maintenance and are surprised by how much is "when is the elevator back" and "can I book the room". That tally is your feature list, already ranked.

2. 2. Read the module list on the software you already pay for

   Property management platforms price per unit and sell the resident portal in the package or as an add-on, so plenty of managers pay for one they never switched on. Find out what it does before building a second. If it works but it's ugly and it's in somebody else's name, that's a real reason to build.

3. 3. Find out what devices people actually carry

   Ask a super what phone the building has. Ask a leasing agent what residents pull out at signing. The oldest operating system you support decides how many residents can install the app at all, and every one who can't will phone the office. That's a business decision wearing a technical costume.

4. 4. Name who answers what the app collects, on Monday morning

   An app that makes it easy to file a request that then sits for a week is worse than the phone, because the phone at least told them nobody had picked it up. Requests arriving faster is only a gain if somebody's day changes to meet them. Otherwise you've built a backlog with a timestamp on every item.

5. 5. Put the store accounts in your own name

   The Apple and Google developer accounts, the signing certificates and the push credentials belong to the management company, not to whoever builds the app. Boring until you change developers, when it's the difference between a handover and a new store listing every resident has to reinstall.

6. 6. Pick one building to launch in

   Not a pilot programme, one building, chosen because the super will tell you the truth. Adoption is decided by operations rather than software: it goes in the move-in package, the super hands it over with the keys, the code is in the elevator and the mail room, and the office stops taking that request any other way.

When an app is the wrong answer

We'll tell you not to build one. This is the list we run first.

If maintenance intake is a few requests a week per building, an app can't save enough staff time to cover what it costs to keep alive. If your residents mostly reach a person who picks up and they like that, an app adds an intake channel rather than replacing one. And if the portal you already pay for does the job and your real objection is the branding, that's a fair complaint and rarely worth a build on its own.

If nobody internally will own it, don’t. An app is a permanent commitment even if you never change a feature, because Google Play sets a target API level requirement and Apple sets a minimum SDK requirement, and both tighten every year. They bite differently. Google blocks new submissions and updates that miss the bar, and an app that falls far enough behind stops reaching new users on newer Android versions, though people who already installed it keep it. Apple’s is an upload gate: you cannot submit anything unless it was built with the current SDK, but an app already on the store is not removed. Either way there’s a floor of maintenance whether or not you ship a feature.

When it is the right answer, it tends to look like this. The surface residents and site staff touch gets replaced, and the system the accounting runs on stays where it is. That split is the part worth copying. Replacing what people touch is a different project from replacing what your ledger runs on, and doing only the first is usually the safer build.