Here's a question that sounds simple: how does a tenant report a leaking tap?

For a long time, in a lot of buildings, the honest answer has been "a phone call, a message to someone's personal number, and hoping it gets passed on". The request lives in one person's memory. Nobody can see its status. When it's finally fixed, nobody records that either.

That gap is why Kate PMS, the property management system I lead at Kate Real Estate, has a tenant app. The system has three faces: a web portal, a staff app, and the tenant app, built with React Native and Expo. This post is about the tenant side: what tenants actually do in it, how it shares one backend with everything else, and why Expo was the right call for us.

What tenants actually do

When you design a tenant app, it's tempting to add everything. In practice, tenants open it for a small number of jobs, and those jobs need to be quick:

• Maintenance requests. Describe the problem, attach photos, submit, and follow the status instead of chasing someone by phone.
• Rent and payments. See what's due, what's been paid, and the history, without asking the accounts team for a statement.
• Contracts. View their tenancy contract and sign documents electronically, instead of arranging a visit to the office to sign paper.

That's the core. Every extra screen competes with these three for attention, so the bar for adding one is high. A tenant who can submit a request in under a minute will use the app. A tenant who has to dig through menus will go back to calling.

One API, three clients

The most important technical decision wasn't about the app at all. It was that the web portal, the staff app and the tenant app all talk to the same Laravel backend.

That sounds obvious, but the alternative is common: a mobile team builds its own endpoints with their own rules, and slowly the "real" business logic forks. A rent balance calculated one way on the web and another way on the phone is the kind of bug that destroys trust in a system.

With one backend, a maintenance request submitted from the tenant app shows up in the same place staff work from, with the same statuses and the same permissions. The rules live in one place:

• Business logic stays on the server. The app displays balances and statuses; it never calculates them.
• Role-based access is enforced by the API. The app hides buttons a user can't use, but hiding isn't security. The server decides what a tenant can see and do, every time.
• Each client gets what it needs. Shared logic doesn't mean identical responses. API resources shape the data for each screen, so the mobile app doesn't download fields it never shows.

Why React Native, and why Expo

Tenants use both iPhones and Android phones, so the choice was between building two native apps or one cross-platform app. For a product like this, where the screens are forms, lists, documents and statuses rather than 3D games, React Native is a very good fit. One codebase, one set of business screens, and the team's existing React and JavaScript knowledge carries straight over.

Expo then removes a lot of the work that makes React Native painful on its own:

• Native features without native code. Camera and image picking for maintenance photos, push notifications for status updates, and secure storage for credentials all come as well-maintained Expo modules.
• Builds in the cloud. EAS Build produces iOS and Android binaries without needing a fully configured local native setup for each platform.
• Faster iteration. Running the app on a real phone during development is quick, which matters more than people think. Mobile bugs often only appear on real devices.
• An escape hatch. If you ever need custom native code, Expo supports it through development builds and config plugins, so choosing Expo doesn't trap you.

The old argument against Expo was "you'll outgrow it". For a business app like this, the ecosystem has matured to the point where that's no longer the default outcome.

What mobile teaches a web developer

Building for phones changes how you think about your backend. A few lessons stood out.

Old versions never fully disappear

On the web, you deploy and everyone has the new version on their next page load. On mobile, some users won't update the app for weeks. That means the API has to keep supporting the previous app version for a while. Breaking changes need a transition period: add the new field, keep the old one, and remove it only when you're confident old versions are gone. You think about API compatibility very differently once you've lived with this.

Networks are unreliable

A tenant submitting a request might be in a basement parking area with one bar of signal. Requests time out, users tap again, uploads fail halfway. Clear loading states, sensible retries, and a backend that handles a repeated submission gracefully all matter much more on mobile than on desktop.

Photos are heavier than forms

Phone cameras produce large images. Resizing and compressing on the device before upload makes the experience faster for the tenant and keeps storage under control on the server.

Trust matters more than features

Payments and contract signing are sensitive. The contract-signing flow, for example, includes verification against Commercial Registration records where it applies. Tenants need to feel that the app is official, accurate and careful with their information. Consistency with what the office tells them is part of that, which loops back to having one backend as the single source of truth.

Where it sits today

Kate PMS is used by 50+ staff and manages 2,000+ tenancy contracts across a multi-property portfolio. The tenant app is the part of that system that tenants actually touch, so its job is to make the everyday things (reporting a problem, checking a payment, signing a document) feel simple, while all the complexity stays behind the API.

If you're about to build a similar app

• Start from the three or four jobs users really come for, not a feature list.
• Share one backend across web and mobile, and keep business rules on the server.
• Plan for old app versions from the first release.
• Pick Expo unless you have a specific reason not to.
• Test on real, slow, mid-range phones, not only on your own.

If you've built a mobile app on top of an existing web system, what was the hardest part to keep consistent between the two?