A PropTech startup founder came to me after their first six months with a search product. They had built a beautiful property search interface - map-based, fast, well-designed. The problem was data freshness. Their listings were updated every four hours via a batch sync from the MLS feed.
In a competitive real estate market, four hours is an eternity. A listing goes active and gets ten offers the same morning. Their users were finding properties, touring them online, and then discovering the property had been under contract for three hours. The experience was frustrating enough that retention was poor.
The fix was real-time MLS sync - a webhook-based integration that updated their database within seconds of a listing status change. The architecture for this was not simple: the MLS data format is RETS or RESO Web API, the fields vary across MLS providers, and building a normalization layer that handles all the variation takes care.
We rebuilt the data ingestion pipeline over eight weeks. Retention improved significantly within sixty days of launch.
That is the pattern in PropTech: the product can look great on the surface while sitting on a data infrastructure that cannot support the user experience the product promises.
MLS Integration: The Most Important and Most Underestimated Technical Problem
Access to MLS data is the foundation of most residential real estate products. MLS (Multiple Listing Service) is a regional cooperative where real estate agents share listing data. The US has over 500 regional MLS organizations. National coverage requires either data aggregation partnerships or connections to a very large number of them.
The technical protocols for MLS data access have a history:
RETS (Real Estate Transaction Standard) is the legacy format. It is a query protocol with an XML-based response format that varies significantly across MLS implementations. Building a RETS integration for one MLS does not mean your code works for another MLS - the field names, data types, and required fields are different across providers.
RESO Web API is the modern standard based on OData and JSON. It is better designed, better documented, and more consistent across MLS providers. Most new MLS implementations use it; many legacy systems are being migrated.
The practical path for a PropTech startup that needs MLS data: do not integrate directly with MLSs at the start. Use a data aggregation provider - Estated, Spark Platform, ATTOM, CoreLogic, or Remine - that handles the MLS relationships and gives you a normalized API. The cost is real. The alternative - building and maintaining direct MLS integrations - requires relationships with each MLS (which requires being or working with a broker), legal agreements, and ongoing maintenance as MLS data formats evolve.
The aggregator cost becomes worth renegotiating when you have meaningful transaction volume and the data relationship is core to your competitive position. For the first two to three years, buy the data.
Map and Search: Where PropTech UX and Architecture Intersect
Property search is primarily a geographic problem. Buyers think in terms of neighborhoods, commute times, school districts, and walkability - not in terms of database queries. The search architecture needs to support geographic query patterns efficiently.
The key technical decisions:
Geospatial indexing. PostgreSQL with the PostGIS extension gives you geographic data types and spatial indexes that make polygon-based searches (search within this school district, search within this hand-drawn area) fast and accurate. This is not the default - you have to design for it. Property searches that use latitude/longitude bounding box queries without spatial indexing will become slow at scale.
Map tile strategy. The map layer in a property search is typically either Google Maps, Mapbox, or OpenStreetMap-based. Google Maps has the most complete data and the most familiar UX but has significant per-use pricing that becomes expensive at scale. Mapbox is more developer-friendly with better cost predictability and good customization. Mapbox is my typical recommendation for PropTech startups that expect to grow.
Clustering and performance at scale. A map showing 50,000 property pins simultaneously is unusable and slow. Clustering - grouping nearby pins into a count indicator at low zoom levels and expanding to individual pins at high zoom - is standard UX in property search. It requires server-side clustering (calculating clusters based on the current map view) or client-side clustering (sending all pins and letting the browser cluster). At scale, server-side is necessary.
Saved search and alerts. Users save searches and expect to be notified when new listings match. This requires a background job that runs each saved search periodically (or on MLS updates) and sends notifications. The architecture question is how to make this efficient when you have tens of thousands of saved searches running across millions of listings.
Property Data Pipelines: Beyond Listing Data
MLS listing data is the starting point. Competitive PropTech products enrich it with additional data that improves search quality, supports valuation, or powers analytics.
The categories of data worth thinking about architecturally:
Public records. Tax records, deed transfers, ownership history, and zoning information are public records available from county assessors and recorders. The challenge: this data is distributed across thousands of county systems with no consistent format or API. Aggregation providers like ATTOM and Estated handle this at scale, or you can build direct county connections for specific high-priority markets.
School district data. School ratings and district boundaries are a primary search filter for family buyers. GreatSchools provides an API. District boundaries are available from various GIS sources. These need to be linked to listings, which requires geocoding and a spatial join.
Walk and commute data. Walkscore, Transit Score, and commute time calculations require third-party APIs. These add cost but are frequently filtered on by buyers.
Neighborhood and amenity data. Points of interest, crime statistics, flood zone information, noise levels. Each of these is a separate data source with its own acquisition and normalization challenge.
The architecture recommendation: model your data pipeline as a property entity with a stable core (MLS listing data) and an enrichment layer (additional data attached to properties by geographic or parcel identifiers). Design the enrichment layer to be extensible - new data sources should be addable without changing the core model.
The Brokerage Relationship Problem
PropTech startups that want to do more than display listings - that want to facilitate transactions, connect buyers with agents, or receive referral fees - face the brokerage relationship question. Real estate brokerage is regulated at the state level, and many transaction-adjacent activities require a brokerage license or a licensed partner.
This is not primarily a technical problem - it is a legal and business structure problem. But it has technical implications. If you are building a referral model, how you capture and attribute leads matters for compliance. If you are building a transaction coordination product, what documents your system touches and how they are stored has legal implications. If you are building an iBuyer model, the offer generation and financial modeling is an extremely high-stakes technical function.
The guidance I give PropTech founders: understand the regulatory model for your specific product category before you design the technical architecture. The technical design should reflect the actual transaction flow that is legally permissible, not an idealized version you then have to retrofit compliance onto.
What PropTech Gets Right and Wrong With Technology Investment
The consistent pattern I see across PropTech startups: too much investment in the consumer-facing interface early, not enough in the data infrastructure.
The consumer-facing interface is visible to investors and is easy to demo. Beautiful map interface, fast search, great mobile design - these make for compelling product demos. The data pipeline is invisible but is actually the product.
A property search that returns stale data, missing listings, or listings that have already sold is broken regardless of how beautiful the map looks. The data is the product. The interface is how you present it. A proptech startup CTO who focuses on the interface before the data infrastructure is building backwards.
The recommendation I make consistently to PropTech founders: spend the first engineering dollars on the data pipeline and make sure it is reliable, fresh, and complete before you invest heavily in the consumer interface. The interface can be improved incrementally once you have users. Bad data erodes user trust in ways that are hard to recover from.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr