Real estate · 2025 · iOS + Android

Alsaud

Tenant-facing Flutter app for a leading Sharjah real-estate company — contracts, maintenance, documents, listings, and visit booking for 5,000+ tenants.

Technical Product Owner + Mobile Engineer

5,000+

Tenants

50%+

Fewer manual processes

iOS + Android

Both stores

FlutteriOSAndroidMapsMaintenance

Click any screen to zoom

Context

Al Saud Company Ltd needed a single mobile product for tenants and prospects across Sharjah and Dubai — not a brochure, a working property system. The catalogue covers flats, shops, and warehouses. Once someone is in a unit, the same app has to support documents, visits, and maintenance — the operational side of tenancy, not just discovery.

My role

I owned

Product requirements and MVP scope
Prioritization of discovery vs. tenant operations
Mobile information architecture and core flows
Flutter implementation for iOS and Android
API integration for listings, maps, and maintenance

The team owned

Backend and property data
Visual design direction
Infrastructure and store publishing support

The problem

Tenants and prospects were split across phone calls, site visits, and fragmented listing channels. Maintenance lived in a different process entirely. The business could not give 5,000+ tenants one place to find a unit, understand it, and raise a request when something broke.

Discovery

We mapped two users who share an app but not a job: a guest searching by area (Sharjah, Dubai) and type (flat, shop, warehouse), and a signed-in tenant who needs documents, properties, and a maintenance trail. The existing workflow was analogue and slow. The constraint was a credible first release — search and listing quality first, then the operational loop — without pretending the app was a full PMS on day one.

Product decisions

One app, two jobs

The decision: Ship guest discovery and authenticated tenancy in the same product, with a guest home that still feels useful before login.
Why: Most people meet Alsaud as a searcher. Forcing an account before they can browse would kill the top of the funnel.
The trade-off: The information architecture is more complex than a pure listing app or a pure tenant portal.
The result: Home, explore, favourites, and a central property action sit together; account and maintenance appear once the user is actually a tenant.

Maintenance as a visible lifecycle

The decision: Treat a maintenance ticket as a timeline — created, in progress, completed, closed — with attachments and supervisor, not a dead-end form.
Why: The pain after move-in is not finding a unit. It is not knowing what happened to a request.
The trade-off: We delayed richer scheduling and technician routing in the first cut.
The result: Tenants can follow a request to close-out and leave feedback history, which is the trust loop the business actually needed.

Listing cards that answer the visit question

The decision: Lead with photo, unit code, building, beds, area, baths, and floor — then map, video tour, and contact / book.
Why: A Sharjah tenant does not need a marketing essay. They need to decide whether a visit is worth it.
The trade-off: Copy is shorter; some storytelling sits in video and photography instead of long descriptions.
The result: The property screen is a decision tool: media, location (Hamriya West, maps), specs, then a call or an appointment.

UX / user flow

The home is a search surface: hero, categories with live counts, popular areas, then property cards. Detail pages stack media, a video tour, an embedded map with Open in Maps, and two clear actions — contact or book. Tenant account is a short list: personal information, documents, properties, maintenance. The bottom bar keeps Home, Explore, Account, and Settings around a central property action.

Technical architecture

Flutter on iOS and Android, talking to the company’s property APIs. Listings, media, maps, and maintenance status are server-driven so counts and ticket state stay true. Auth is optional for browse, required for tenant records. Dark mode, help, and policy screens sit in settings so the product can be maintained without a redesign.

What I built

Guest home with search, filters, and area browsing
Property listing and detail with video, map, and appointment CTAs
Favourites and share on listing cards
Tenant account: documents, properties, password recovery
Maintenance request detail with status timeline, attachments, and feedback
iOS and Android delivery

Trade-offs

We did not try to replace the full back-office property system in v1. Technician dispatch, payments, and deep analytics waited. The first release had to make search trustworthy and maintenance visible. Anything that increased complexity without helping those two jobs was cut.

Launch

Released for iOS and Android as the Alsaud tenant-facing product. Guest browse works immediately; tenancy features sit behind sign-in. The operational bet was that one store listing could serve both discovery and aftercare.

Outcome

The application serves 5,000+ tenants. Discovery, unit detail, and maintenance now live in one mobile surface instead of a split between calls and disconnected tools. Exact commercial figures stay with the client.

What I learned

I would have validated the maintenance timeline with a small tenant group even earlier. Search quality is what gets the download; the request lifecycle is what keeps the app on the home screen. Those are two products sharing a shell, and they need to be scoped that way from week one.