How we built OIS an Arabic property portal that stays fast

OIS is a property portal, which is a different problem from a property website. A developer site presents a handful of projects.

A portal has to stay usable when the listing count runs into the thousands. The person browsing already has a specific shape of home in their head, and they want to reach it in four moves.

The 2023 brief had two halves. First, a search that reflects how Egyptian buyers actually narrow: city, then property type, then bedrooms, then area, then price band.

Second, a browse that does not degrade as inventory grows. A portal that gets slower the more successful it becomes is a portal with a shelf life.

Those two halves are really one requirement. Speed is what makes a filter feel like a tool rather than a form.

The listings engine is the product, so we built it first and designed around it. Every listing is a record with real fields, and every filter maps to one of them.

Narrowing to three bedroom apartments in a given city inside a price band is a query. It is not a text search that half works and quietly drops the listings with a different spelling.

Filters combine freely and update the result set together. A buyer can loosen the price band without losing the four choices already made, which is the single thing that keeps somebody exploring.

The interface is Arabic and right to left throughout. Filter controls, result cards, pagination and the property detail pages all read in the correct direction, with the layout designed for it rather than mirrored after the fact.

Our website and app development team built the engine, and graphic design and brand identity set the interface language.

Result cards carry enough information to shortlist without opening anything. Location, type, size, bedrooms and price, in a scannable order.

That single decision does more for a portal experience than any amount of animation. It lets a buyer reject nine listings and open the tenth.

We built listings management for the people who run the portal daily. Adding, editing and retiring a property is a content operation, and the filters pick up new records automatically.

Inventory volume never becomes a build task. That is the difference between a portal that grows and a portal that needs a developer every week.

On the browse side the page weight stays disciplined. Image sizes match the card grid, results arrive in pages rather than one request, and templates stay quick on a phone. High listing volume was the assumption from day one, which is why the portal browses the same way with a full catalog as it did at launch. More builds sit on our success stories page.