Real Estate Portal Development: Where Property Search Breaks
A real estate portal is, above all, search. The buyer sets a district, price, area, floor, house type, and mortgage program availability, and expects results with a map in fractions of a second.
When real estate portal development starts with the storefront rather than the data model, the catalog holds up for the first thousands of properties and falls apart at real volume.
Slow property search almost always hits heavy queries: selection runs through a join of a dozen tables without covering indexes, and the counter "found 12,480" is calculated as a full scan.
Response time grows with every thousand listings, and filters fail to find properties simply because values are normalized differently — "2-room" and "2 rooms" sit in the database as different entities.
The second failure point is an outdated property database.
The "sold" status remains in the listing because the developer feed arrives as a file once a day and fails on a format error, while the price in the listing card and in the mortgage calculator is calculated from different sources.
The user sees the discrepancy and leaves for a competitor, and the agent gets calls about properties that do not exist.
The third is failure under load. Geosearch and the clustered map hit the database with a separate query for every map movement, and the weekend peak of requests brings the service down entirely.
A map tile layer based on OpenStreetMap data removes some limitations, but it does not replace a proper spatial index. Let's look at how this is solved.
What Reworked Search Delivers: Speed, Accuracy, Resilience
Geosearch is no longer a full scan: a spatial index on PostGIS and precomputed district boundaries return a "within radius from point" selection by index rather than by recalculating distances across the entire database.
Result speed stays within fractions of a second where previously the page took seconds to assemble. At the same time, the cause of empty results goes away: filters are applied consistently, and properties are not lost due to mismatched district boundaries and coordinates.
Geosearch accuracy rests on address normalization and unified geometry: house, street, district, and polygon on the map are described by the same data.
If there are no matches for a set of filters, search shows the nearest suitable properties and suggests relaxing a condition instead of showing an empty screen. The share of zero-result searches drops — and on the same queries, the number of viewing requests grows.
The mortgage calculator calculates in the browser using preloaded bank conditions: recalculation is instant as the slider moves and does not block the map with the list.
Load resilience comes from read replicas and result caching — the evening peak, when thousands of listing cards are open, passes without an increase in response time.
Property listing freshness is ensured by event-based cache invalidation: if the price or status changes, the card and its place in results update within a minute, not after a scheduled rebuild.
Geometry and index are updated in the same transaction as the property data, so search does not show a sold apartment as available.
Portal Implementation Options: Ready-Made Core, Enhancement, Custom Build
A real estate portal is built in three ways, and the choice is determined not by taste but by how much your selection logic differs from the standard one.
A ready-made platform covers the standard scenario: property catalog, filters, map, mortgage calculator based on standard conditions.
As soon as your own ranking rules, multiple data sources, or non-standard mortgage scenarios appear, the boundary between ready-made and custom shifts — this is already a different scope of work.
Comparison of Approaches
| Option | When suitable | What we do | Launch timeline and limitations |
|---|---|---|---|
| Ready-made platform | The catalog fits a standard structure, filter and calculator logic is standard | Deploy, configure reference data, migrate the catalog | Fast launch; non-standard selection scenarios are limited by platform capabilities |
| Enhancement of existing portal | The site is running, has indexing and an accumulated property database | Extend geosearch, rewrite the calculator, connect sources | Launch in iterations; maintain compatibility with old code and do not lose search positions |
| Custom build | Geosearch and calculator are the core product, the logic is unique | Design the data model, geometry search, calculation modules for your rules | Longer launch; an ongoing team is needed for development and support |
In practice, the choice is decided by three questions: the size of the catalog and how often it updates, how non-standard the selection logic is, and what is already in place.
Catalog migration is a separate risk: errors in coordinates and address fields break geosearch, so we migrate with selective data reconciliation, not as a stream.
Work Stages: From Catalog Review to Handover to Operation
We start work with a catalog audit, not with interface layout: the order of steps is arranged so that decisions rely on the customer's actual data, not on assumptions. Below is the sequence we follow on a real estate portal.
- Catalog audit. We count volume and structure: how many properties, property types, cities, and incoming sources. We find duplicates, empty fields, and address discrepancies — this determines where to clean data: during loading or already in search.
- Data schema. We design the property model, links to agencies and media, and rules for status updates. We store coordinates and district boundaries separately from text addresses so that map filters do not depend on the street spelling format.
- Setting up search and listing cards. We assemble indexing, ranking, suggestions, and results by visible map area; define price, area, and mortgage condition ranges. We separately look at behavior on broad queries where it is easy to get thousands of results.
- Scenario testing. We walk the buyer's and agent's path from search to lead, including failures: empty results, a withdrawn property, unavailable payment data. Based on the results, we fix logic, not error text.
- Handover to operation. We fix the schema, update procedure, and access levels, train the customer's team, and leave a contour for rollbacks and monitoring.
Each stage is closed with an artifact — a schema, a configuration, or a verification report — so acceptance is based on facts, not impressions.
What We Hand Over: Schemas, Procedures, Documentation
A real estate portal lives longer than the team that built it. Therefore, along with the code, we hand over documents that a new engineer or editor can use to work without us.
We keep them in the repository next to the project — this way, after each release, they do not diverge from reality.
- Architecture diagram — application layers, connections to developer feeds, the geoservice, and the mortgage calculator, as well as what is cached and for how long.
- Access rights matrix — roles from realtor to administrator: who sees a property draft, who publishes, who changes mortgage program parameters; separately, service accounts.
- Data update procedure — schedule for property synchronization, behavior when source discrepancies occur, procedure for unpublishing, and what happens to the page URL.
- Instructions for editors — required listing card fields, markup of geotags and polygons on the map, requirements for photos and floor plans, address verification before publication.
- Operations procedures — backup with recovery verification, release deployment and rollback to the previous build, cache reset after data update.
- Integration documentation — exchange formats, rate limits for external services, what to show the user when the source is unavailable.
- Decision log — why this map search method was chosen, where filters are limited, and which code areas require caution during edits.
Acceptance follows a checklist: we bring up the portal in a clean environment strictly according to the instructions and walk through key scenarios — from map search to mortgage calculation. Gaps are revealed at this step, not six months later.
Case Study: District Geosearch and Growth in Qualified Leads
An agency selling new-build housing came with a portal where search worked by address string, and districts were listed as a text list in the filter.
The user reached a listing without understanding what district was around and left: conversion from view to lead held at 1.2%, only 18% of inquiries contained the selected district, and the filter responded to a query in two to three seconds.
What We Changed in Geosearch
We built a geo index by polygons of administrative boundaries and microdistricts and added area selection directly on the map — with a frame or by clicking a district.
For each district, we pulled aggregates: travel time to the center, schools and kindergartens, housing commissioning volumes, average price per meter by apartment type.
Map layer Yandex Maps, heavy queries are precomputed by grid and served from a prepared set — the filter responds instantly even for tens of thousands of properties.
Property Listing Card
We moved the mortgage calculator inside the listing card: payment, down payment, and term are recalculated without page reload, and it immediately shows whether the property meets the conditions.
We added comparison of up to four properties and saving a selection so users can return to it from their phone.
Two months after launch, conversion from listing view to lead grew from 1.2% to 3.4%, and the share of inquiries with the selected district — from 18% to 61%.
Bounces at the selection stage almost halved, and managers began receiving leads with an already formed request: district, budget, and mortgage parameters known before the call.
How Does Geosearch by District Boundaries Differ from Radius Search?
A radius is a circle around a point on the map: the user sets the center and coverage, and the system selects everything inside it.
Such a query is fast and does not require boundary data, but the circle almost never coincides with the administrative one: a house across the road goes into results as a "neighboring district," while the far corner of the desired district falls out of it.
A radius does not distinguish barriers — a river, a railway, an industrial zone. A property is close as the crow flies, but the road to it goes around, and the buyer gets listings that are clearly unsuitable.
Boundary geosearch works with polygons of districts, microdistricts, and residential complexes. Here, result accuracy matches how the buyer thinks about the city: the district determines the school, clinic, tax, and cadastral value.
District filters give predictable results but require current contours — boundaries are revised, new microdistricts appear, and disputed areas at junctions have to be marked manually during data loading.
Engineering-wise, this is solved not by choosing one mode but by combining them.
Whether a property falls within a polygon is calculated once when the listing is published and stored as an attribute — the district filter turns into an ordinary selection condition and does not recompute geometry on every request.
The radius remains for the "near work or station" scenario and for expanding results when there are few options within exact boundaries: we show the nearest ones, gradually increasing coverage.
What to set as the primary mode depends on the buyer scenario. Someone choosing a district expects a boundary filter and gets annoyed seeing other districts in the list. Someone tied to a point expects a radius and considers travel time, not administrative lines.
Errors of both modes are visible in measurements: the share of opened listings outside the selected district and the share of bounces after viewing the map show where the mode misses.
Technical Concerns: Integrations, Load, Data Quality
External feeds from agencies and developers arrive in different formats and with varying completeness: some properties lack coordinates, some duplicate by the same address.
Data is brought to a unified schema — geocoding, deduplication by address and coordinates, validation of required fields on input.
How will the portal withstand peak load?
We build load tests according to the real profile: map with clustering, filters by district and price, mortgage calculator calculation. We look not at average response time, but at the 95th percentile on heavy queries. Geo search goes to a spatial index, and repeated queries are cached.
What to do with errors in listings from feeds?
Validation on input filters out records with price out of range, zero area, and coordinates outside city boundaries. Such properties do not get into results, but are stored in a separate list with a reason — the source sees it on the next import and fixes the feed.
How is the existing property database migrated?
One-time import: field mapping, test run on a copy, reconciliation of record count and geo completeness. The old database remains read-accessible until discrepancies reach zero, so switching is reversible.
Who supports integrations after launch?
Support includes monitoring feeds, alerts on import failure, updating reference data and calculator conditions when bank requirements change. The list of responses and the responsible engineer are fixed before project handover.
Let's Discuss the Task and Come Back with a Work Plan and Estimate
For the estimate to be concrete, not "plus or minus an order of magnitude," it is worth attaching what you already have to the conversation.
Describe the task: which scenarios the portal covers — property search, clustered map, filters, mortgage calculator, agent or developer account. We will review prototypes, data schemas, and feeds based on them — this way the work plan relies on facts, not assumptions.
What helps us come back with a work plan rather than general words:
- Roles and audience: buyer, realtor, developer, administrator — each has its own set of rights and scenarios.
- Property sources: regular feeds from developers, CRM integration, or manual content entry — storage schema and update frequency depend on this.
- Geo: coverage areas, address accuracy requirements, whether radius and polygon search are needed.
- Mortgage calculator: partner banks and programs, who updates rates and how often.
- Load and timelines: how many properties are in the database, how many requests at peak, whether there is a tie to the launch date.
- Existing portal, if any: access to the repository, documentation, known bottlenecks.
Then we study the materials, clarify what is unclear, and come back with a work plan: breakdown into stages, estimate for each stage, and team composition for your case.
We will agree on the start order and the points where your participation is needed: access, data schema approval, acceptance. Describe the task in a convenient format — we will discuss the next step.
