Fifteen years building and scaling distributed systems, across the industry's move from bare-metal servers and monoliths to cloud-native, Kubernetes and GitOps. I take on the work teams postpone: paying down technical debt, building deployment from nothing, and keeping systems running.
A portal of that size is read mostly on a phone, often on a connection that cannot afford a heavy page — and the filters are the part people actually use.
What was done
Built the map search, the catalogue filters and the property card behind them, then made them hold up at that size: long result lists render only what is on screen, filters wait for you to stop typing before they search, and a changed filter updates the list instead of rebuilding the page.
What was built
Geo search: locality, radius and map-bounded queries
Multi-criteria filters over the listing catalogue
The property card those filters open
Result rendering tuned for low-bandwidth devices
In numbers
Filter response over the catalogue: 1.5-2.0 s → <200 ms — Thousands of listings, on a phone
Long lists: virtualised, filters debounced — Scrolling stays smooth on a weak device
What changed
Filter response went from 1.5-2.0 seconds to under 200 ms across a catalogue of thousands, and scrolling stays smooth on a weak phone rather than only on a developer laptop.
Why it was hard
Long lists virtualised and filters debounced: a catalogue of thousands cannot be rendered whole, and a filter that refetches on every keystroke spends the visitor’s bandwidth and battery.
Filters are the part of a portal people actually use, and they compose: every added criterion multiplies the states the interface has to stay coherent in.
The audience browses on phones over connections that cannot afford a heavy page, so the budget was set by the slowest realistic device rather than by a developer laptop.
Evidence
Delivered under contract. The source and the internal measurements stay with the client, and the figure above is theirs rather than a public benchmark.