Reserving a new home with a verified identity.

Discovery ran as a short, structured phase before any design. We benchmarked the local portals, the regional and international marketplaces and the regulator’s platforms, and wrote up what each did well and where each stopped. The client brought its knowledge of developers and of how sales actually close in the Kingdom. Our job was to translate that into something a team could build.

The output was a feature definition for each of the three audiences, written as user journeys rather than as a list of screens. A buyer’s journey ran from a search to a reserved unit and, if needed, to a refund. A developer’s ran from registration through approval to a published listing and a received deposit. The company’s ran from a registration request to an approved developer and a moderated catalogue.

Several rules were settled here that would have been expensive to change later, which is the reason to settle them early. The deposit would be a fixed amount rather than a percentage, so the buyer always knows the number before they start. A deposit could be cancelled within a day of being received, with the deadline shown to the buyer. Every listing would carry Arabic and English names and descriptions as separate fields, so the product is bilingual at the data level rather than translated after the fact. And the transaction tax would be calculated and stored with each listing, so a change in the rate never rewrites the past.

By the end of discovery the client had a documented product, and we had a backlog we could estimate.

Design started with mockups of the buyer’s core path, search, listing and reservation, reviewed with the client until the shape was right. Agreeing on a handful of screens before designing dozens kept the later work from being revisited.

From there, every application was designed in Figma. The buyer app on iOS and Android, the developer portal, the back office and the landing site all came out of one file structure and one design system, so a button in the portal and a button in the app are recognisably the same product. The system was designed for two directions from the start. Every layout was drawn for Arabic reading right to left and for English reading left to right, with mirrored navigation, mirrored icons and text styles for IBM Plex Sans in both scripts.

Some of the details were specific to the market. Prices are displayed with the new Saudi Riyal symbol, which needed its own glyph rather than a text abbreviation. An icon set was drawn for the amenities a Saudi buyer looks for, prayer rooms among them. Brand assets for the launch, including the store listings and the landing site, came out of the same work.

Design ran alongside engineering rather than months ahead of it, and the whole engagement ran in two-week sprints, each ending in a demo of the working product. Decisions were taken with the client looking at real screens, on a shared board both sides could see, so the build never waited on a finished file and the design never drifted from what was shipped.

The buyer app opens on a map. Projects appear as price markers that group by province when the map is zoomed out and separate into individual projects as it zooms in. A buyer can type a neighbourhood and land on it, drag the map to a street and see everything for sale within it, and narrow the results with filters for price, area, rooms, building type, facade, use and amenities. The same filters work whether the buyer is looking at whole projects or at the units inside them.

A listing carries everything the developer has published. A gallery, a brochure and floor plan, a 360 tour where one exists, nearby places with distances, the amenities, the price with its tax and deposit broken out, and the payment plan as a timeline of instalments. A buyer who wants to talk first opens WhatsApp from the listing with a message already written in their language, and the developer receives a link straight back to the unit.

Arabic is the default language, and the whole interface mirrors for right to left reading down to the smallest control. Browsing, filtering and reading a listing need no account. A phone number is asked for at the point a buyer bookmarks, saves a search or starts a reservation, and never before.

The result is an app that does its work before asking for anything.

Two identities matter in a reservation, the developer’s and the buyer’s, and the product checks both before money moves.

A developer registers, completes a profile in Arabic and English, verifies through Nafath and then creates their company with its FAL license number and a copy of the license. The registration lands in a queue in the back office, where the company’s team opens the document and approves or rejects the developer. Until approval, nothing can be published. Every listing then carries its publication license number and mediation contract number, checked as the developer enters them.

A buyer verifies through Nafath at the moment they start a reservation. They enter their national ID, the Nafath app on their phone shows a set of numbers, and they choose the one that matches the number shown in Hawyia Units. Nafath confirms the result to the platform, the buyer’s record is marked verified, a notification confirms it, and the reservation continues. It happens once, and every later reservation skips it.

Where that confirmation lands mattered. Identity data about Saudi citizens and residents belongs in the Kingdom, so the service that receives it is deployed in Google Cloud’s Saudi region, separate from the rest of the platform.

Licensing and identity became something the product does on the buyer’s behalf rather than paperwork exchanged afterwards.

A reservation is a deposit of 500 Saudi riyals, the same on every listing, so a buyer knows the number before they start. They pay with a mada card or, on iPhone, with Apple Pay, without leaving the app, and land on a success screen or on a failure screen that says why.

The deposit is confirmed twice. Moyasar tells the platform a payment went through, and the platform checks that directly with Moyasar before it holds the unit. A notification that has been tampered with or delayed cannot reserve an apartment, and two buyers reaching for the same unit in the same second cannot both get it.

Refunds follow the rule settled in discovery. For 24 hours after the deposit is received, the buyer’s reservation screen shows the deadline and a cancel button. A cancellation is a refund request. The developer sees it in their deposits inbox, the refund is issued through Moyasar, and the buyer is notified in their language when it completes, as they are when a payment succeeds or fails.

Developers work at a desk, on inventory measured in hundreds of units, and the portal is designed for that. A listing is created step by step, details, configuration, gallery, virtual tour and review, with a draft saved at any point and a warning before leaving with unsaved changes. Addresses run from province to city to neighbourhood and finish with a pin on a map. Amenities, nearby places, brochures and floor plans are attached in place.

A project with many units does not have to be entered by hand. The developer fills a spreadsheet and drops it in the portal. Every row is checked against the same rules as the form, errors are listed by row before anything is saved, and images embedded in the spreadsheet are attached to the right unit. Units can then be published, hidden, marked sold or deleted in bulk.

Payment plans are structured rather than free text. A developer defines instalments as amounts and days, and the portal will not accept a plan that does not add up to the price less the deposit, so what a buyer sees as a timeline is always true.

The portal also closes the loop. Each listing shows its views and bookmarks, and a deposits page lists every reservation with the buyer’s name and phone, the amount, the method and the date, with totals received and refunded. A developer’s first verified lead arrives with money attached.

The back office belongs to the company’s team. It holds the queue of developers waiting for approval with their FAL documents, every listing across every developer, the WhatsApp accounts that inquiries are routed to, the banks shown to buyers for financing, and a form for notifications to every user.

Hawyia Units is live on the App Store and Google Play, and the landing site introduces it to buyers in Arabic and English.

Behind the six applications is one TypeScript codebase. The buyer app is built with Expo and React Native, the developer portal, the back office and the landing site with Next.js, and they share one API, one Postgres database, one design system and one set of Arabic and English translations. A change made once reaches every application, and a mistake in one place is caught before it reaches any of them.

It is a platform the client can keep building on, and one where the next government integration already has a place to go.