Real estate app development company for portals, agent tools and rental apps

Real estate apps we build

Real estate software splits into four product types with different users, data sources and revenue models. Most clients start with one and add a second later, so we design the data model so a listing, a contact and a property can be shared between them.

Features by user type

MLS data: RESO Web API, Data Dictionary and IDX rules

In the US, listing data comes from Multiple Listing Services. The RESO Web API is the current transport: a RESTful API based on OData version 4, with RESO describing the older RETS standard as deprecated and no longer supported. Field names follow the RESO Data Dictionary (version 2.0 is the current ratified release), which is what lets one ingestion pipeline serve several MLSs with mapping only at the edges.

Access is governed by your MLS and its IDX or VOW licence, not by the API. The NAR IDX policy, which most MLSs adopt, requires displays fed by an IDX download to be refreshed at least every 12 hours, and sellers can direct that their listing or address not appear online. Each MLS adds its own display rules for attribution, disclaimers and photo use, so we read the MLS agreement in discovery and turn its rules into tests.

• Ingestion: a scheduled sync using the API's modification timestamps, with full reconciliation runs to catch deletions and status changes.
• Deduplication: the same property listed by two agents or in two MLSs merged by address normalisation and parcel identifiers where available.
• Media: photos copied to your own storage and CDN where the licence allows, resized for mobile, with the originals' order and captions kept.
• Outside the US: portals in the UK and Europe usually take feeds from agents' CRMs or portal-specific formats; we map them into the same internal model.

Map search and saved-search alerts

Search is the product for a portal. We build it on PostgreSQL with PostGIS or MongoDB geospatial indexes for bounding-box and polygon queries, with OpenSearch or Algolia when text search and facets need to be fast at scale. On the map, markers cluster at low zoom and the list and map stay in sync as the user pans. Saved searches run as a job after each sync: new and changed listings are matched against stored criteria and sent as one digest per user, not one email per listing, with push notifications for instant alerts. Most portals underestimate this job; it is the feature that brings users back.

Fair Housing, e-signature and payments

In the US, the Fair Housing Act regulations at 24 CFR 100.75 make it unlawful to publish a notice, statement or advertisement for the sale or rental of a dwelling that indicates a preference, limitation or discrimination based on race, colour, religion, sex, handicap, familial status or national origin. The regulation names words, photos and symbols, and the choice of media or locations that keep groups from hearing about housing. For software that means:

• Listing copy checks: a review queue that flags phrases such as preferences about family type or neighbourhood character before a listing goes live. AI-written descriptions go through the same check.
• Ad targeting: no audience targeting by protected characteristics or obvious proxies for them when the app buys or syndicates housing ads.
• Search and recommendations: no filters or ranking based on protected characteristics or demographic data about neighbourhoods.
• Tenant screening: consistent criteria applied to every applicant, with the decision and reason recorded.

This is engineering support for your compliance, not legal advice; your broker of record or counsel signs off the rules. E-signature for offers, leases and disclosures is integrated through DocuSign or Dropbox Sign rather than built. Rent and deposits run on card and bank payments through Stripe, with Stripe Connect for marketplaces that pay out to hosts or landlords, as covered in our Stripe Connect marketplace post and on payment gateway integration.

Mistakes we see in real estate apps

• Building the portal before the data: a beautiful search screen on top of duplicated, stale listings loses users in the first week. We build ingestion, deduplication and reconciliation first and measure feed health on an admin dashboard.
• Treating the MLS agreement as paperwork: display rules on attribution, disclaimers, sold data and photos differ by MLS, and breaching them can cost the feed. We turn them into automated checks on listing pages.
• Client-rendered listing pages: a single-page app with no server-rendered HTML gets little organic traffic, and organic search is where portals find buyers. Listing and area pages are server-rendered with structured data and clean URLs.
• One email per new listing: alert fatigue makes users unsubscribe. Digests per saved search, with frequency the user controls, keep them.
• Leads with no source: agents and brokers pay for leads and want to know where each came from. Every lead records its listing, page, campaign and routing rule.
• Payments without a ledger: rent, deposits, fees and payouts need to reconcile to the bank and to owner statements. A small double-entry ledger from the start avoids rebuilding it later.

Web, mobile or both

Buyers search on phones, but agents and managers work at desks. Our usual answer is a Next.js web app for search pages that need to rank in Google and for the agent and manager back office, plus a React Native or Flutter app for buyers and tenants once alerts and push notifications matter. Listing pages must be server-rendered with structured data, or the portal will not get organic traffic. See React Native development and Flutter app development for the trade-offs.

What a real estate app costs

The portal and marketplace figures come from our app development cost calculator, so you can switch features on and off and see the range move. Team for a portal MVP: 2 senior full-stack engineers, a mobile engineer, a designer (part-time), QA and a delivery lead. The cost to build a real estate app like Zillow and cost to build an app like Airbnb posts break down each feature, and real estate CRM software development covers the agent side. MLS fees, map API usage and e-signature licences are extra.

How a real estate project runs

1. Discovery ($3k to $8k, one to two weeks): users, MLS or feed agreements, display rules, integrations and a costed backlog.
2. Data first: ingestion, deduplication and the search index built and tested against real feed data before the first screen is designed in detail.
3. Search and listing pages: map, filters, listing detail and saved searches, released to a small group of agents or users.
4. Transactions: leads, viewings, applications, e-signature and payments.
5. Launch and grow: SEO for listing pages, analytics on search and alert engagement, and the second product type if the plan includes one.

Our relevant work

We have no published real estate case study yet. These projects contain the same core problems, and their engineers would work on yours:

• CareFlair: a two-sided Australian marketplace with geospatial search on MongoDB 2dsphere indexes combined with text search, availability and service-type filters, plus real-time messaging and role-based access for four user types. That is map search and two-sided matching.
• Seek My Service: a service marketplace whose request engine matches a client's zip code against vendor subscription areas and categories, with vendors buying credits through Stripe to bid on requests. The same area matching drives agent territories and lead routing.
• AutoViz: an embeddable SDK and configurator white-labelled for several brands, with analytics on views, saves and funnel progression. Portals that syndicate listings or widgets to agent websites need the same embeddable, per-brand delivery.

For the wider PropTech picture, see the real estate and PropTech industry page, or our marketplace development work if you are building a rental marketplace.