How to Make an App Like Compass

Building a real estate app with the depth of Compass means making hard architectural choices early. This post covers the core systems, data contracts, and trade-offs you'll face if you're serious about it.

What Does a Compass-Like App Actually Need to Do?

Compass is not just a property listing app. It combines an MLS data aggregation layer, a CRM for agents, a collaborative transaction management system, and a consumer-facing search product, all running on a shared data backbone. If you're planning to replicate that scope, you need to be clear about which of those four surfaces you're building first, because each has a different latency profile, data model, and team structure requirement.

The consumer search surface is read-heavy, tolerates eventual consistency, and needs sub-200ms response times on property queries. The agent CRM is transactional, needs real-time collaboration, and has strict audit requirements in most US states. Transaction management touches legal documents and e-signatures, which brings compliance overhead. MLS aggregation is a data pipeline problem, and a thorny one.

Build all four at once and you'll ship nothing. Pick one, get it right, and build the integration contracts that let the others attach later.

How Does MLS Data Integration Actually Work?

This is where most teams underestimate the work by a factor of three or four.

In the US, MLS data comes via RESO (Real Estate Standards Organisation) Web API, which is built on OData 4.0. Most MLSs also still support the older RETS protocol. You'll almost certainly need to handle both. There are roughly 580 MLSs in the US, and they don't all implement the RESO standard the same way. Field names diverge, required fields differ, and some MLSs enforce IP whitelisting.

A practical architecture looks like this:

• An ingestion layer that pulls delta feeds (not full refreshes) on a 15-minute cadence for active listings
• A normalisation service that maps each MLS's schema to your canonical property model
• A read store optimised for geo-queries, typically Elasticsearch with geo-point fields and a geo_distance filter
• A separate write store, PostgreSQL works well here, that holds the authoritative record and feeds the search index via a change data capture (CDC) stream using something like Debezium

If you're outside the US, the data contracts differ. In India, there's no equivalent to RESO. You're aggregating from portals like MagicBricks, 99acres, and Housing.com via scraping or unofficial APIs, or you're building direct relationships with brokers. That's a fundamentally different data problem: reliability and freshness are harder to guarantee, and deduplication becomes your biggest engineering challenge.

Canonical Property Model

Define your canonical schema before you write a single ingestion adapter. Every MLS adapter maps to this model, not to each other. Fields like listing_status, property_type, and geo_coordinates need to be normalised centrally. A property that appears in three MLSs and two portal feeds should resolve to one canonical record. Building a deterministic deduplication key (typically a hash of address components after standardisation) early saves significant pain.

What Does the Agent-Facing CRM Require?

The CRM layer is where the product gets complicated fast.

Agents need to track leads, assign listings, log calls, and collaborate with team members in real time. The data model centres on a few core entities: Contact, Opportunity (a buyer or seller intent), Listing, and Activity. The relationships between them are many-to-many in practice, because one contact can have multiple intents, and one listing can be linked to multiple opportunities.

Real-time collaboration on pipeline views means you need a WebSocket layer or server-sent events for live updates. Compass uses a shared pipeline board similar to a Kanban board. If you're building this, look at operational transformation (OT) or CRDTs if you need concurrent edits on the same record. For most CRM use cases, optimistic locking with a version field and a conflict resolution UI is sufficient and much simpler to implement.

Activity logging needs to be append-only. Don't update activity records; write new ones. This gives you a full audit trail, which is a compliance requirement in most real estate markets.

How Should You Model the Search Experience?

Consumer search has three distinct query types, and they need different handling.

The first is geo-bounded search: "show me properties within this map viewport." Use Elasticsearch's geo_bounding_box query. Index geo_point fields for the property location. Filter by listing status before applying geo filters to avoid scoring irrelevant records.

The second is faceted search: filtering by price range, bedroom count, property type, and so on. Elasticsearch handles this well with term and range aggregations. Keep your filter options consistent with what's actually in your index to avoid empty result sets.

The third is intent-based search: "3BHK near good schools in Indiranagar." This needs NLP. You're parsing a natural language query into structured filters. At minimum, you need a named entity recogniser trained on real estate vocabulary. spaCy with a custom NER model gets you partway there. For location parsing, a geocoding layer like Google Maps Platform or Mapbox Geocoding API translates neighbourhood names to coordinates.

Query Type	Primary Tool	Latency Target
Geo-bounded	Elasticsearch geo_bounding_box	< 150ms
Faceted	Elasticsearch term/range aggregations	< 200ms
Intent-based (NLP)	Custom NER + geocoding API	< 800ms

Cache aggressively at the search layer. Popular queries repeat. A Redis cache with a 5-minute TTL on geo-bounded search results will cut Elasticsearch load significantly without meaningfully degrading freshness.

Transaction Management and Document Handling

This is the part most engineering teams want to skip and build later. Don't. Transaction management is where agents spend the most time, and it's where your retention depends.

A basic transaction object tracks: parties (buyer, seller, agents, attorneys), key dates (offer date, inspection deadline, closing date), required documents, and status. Documents need version control. Every uploaded file should be immutable; new uploads create new versions.

E-signature integration is non-negotiable. DocuSign and HelloSign (now Dropbox Sign) both have APIs. DocuSign's eSignature API is more mature and widely trusted in US real estate. Integrate at the envelope level, not the template level, so agents can compose custom document packages per transaction.

Notifications for date-triggered events (three days before inspection deadline, for example) need a reliable scheduler. AWS EventBridge Scheduler or a simple cron-based job with a Postgres scheduled_events table works. Don't rely on application-level timers for anything compliance-critical.

Conclusion

Start with the MLS ingestion pipeline and the canonical property model. Those two decisions constrain everything else. Once your data is clean and queryable, the consumer search layer is relatively straightforward. The CRM and transaction management surfaces require more product thinking than engineering invention, but the compliance requirements mean you can't cut corners on audit trails and document handling.

If you're deciding between building this in-house or with an external team, the honest answer is that the MLS integration work is genuinely specialised. The normalisation and deduplication logic takes time to stabilise regardless of team quality. Budget six months before that layer is reliable in production.

The next concrete step: write your canonical property schema and your deduplication strategy before you write any ingestion code. Everything else depends on getting those right.

---

FAQ

How long does it take to build a real estate app like Compass? A full-featured product with MLS integration, consumer search, and an agent CRM realistically takes 12 to 18 months for a team of six to eight engineers. A focused MVP covering just consumer search on one or two MLS feeds can ship in four to six months. Scope is the primary variable.

What technology stack is best for a real estate search app? PostgreSQL for the authoritative data store, Elasticsearch for geo and faceted search, Redis for query caching, and Node.js or Python for the API layer are a common and well-tested combination. The MLS ingestion pipeline works well as a separate Python service using asyncio for concurrent feed polling.

How do you handle duplicate listings from multiple MLS sources? Build a deterministic deduplication key from normalised address components: street number, street name, city, and postcode. Hash that key after standardisation (lowercased, whitespace-stripped, common abbreviations expanded). Records sharing a hash are candidates for deduplication, then apply a confidence score using additional attributes like price and bedroom count.

Do you need a real estate licence to access MLS data? In the US, most MLSs require your firm or a partnered brokerage to hold an active real estate licence to receive a data feed. You'll also need to sign a data licence agreement with each MLS. Aggregators like Spark API or Bridge Interactive can reduce the per-MLS negotiation burden, though they add cost and a dependency layer.

What's the biggest technical mistake teams make building these apps? Trying to build the ingestion layer and the product surfaces simultaneously without a stable canonical schema in between. When the schema changes, every consumer breaks. Treat the canonical property model as an internal API contract, version it, and enforce it strictly before any product layer depends on it.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.