Engineering RealFoyer: Building a Multi-Tenant Real Estate SaaS Platform

Our own product, not a client project. RealFoyer is owned and operated by Peregrine IT Solutions LLP, as the footer of realfoyer.com states. This page contains no client data and no customer metrics. For what the product does today, see our RealFoyer product page; for plans and MLS coverage, see realfoyer.com. The agent-website platform in our real estate SaaS scaling case study is a different client's product, and nothing on this page comes from it.

The Product Problem

RealFoyer is for real estate agents, teams and brokerages in the United States and Canada. Its premise is stated on its about page: “Agents shouldn't need five different platforms just to run one digital real estate business.” When the website, the IDX search, the CRM and the marketing tools are separate subscriptions, each holds its own copy of the lead and none knows what the others saw.

The engineering goal followed from that: one data model shared by the agent's website, the listing search and the CRM, so that an inquiry arrives, in the words of the IDX websites page, “with the property and the search that produced it attached.” Everything below is a consequence of serving that model to many agents, in more than one market, from one platform.

What Shaped the Design

Four constraints came before any technology choice. None of them is specific to RealFoyer; any platform that serves agent websites from MLS data runs into them.

How the Platform Is Put Together

The layers below are described by role, not by product name: we do not publish RealFoyer's stack or hosting. Each layer links to the guide in which we explain that part of the engineering in general terms.

Tenancy: One Database, a Key per Site, Resolved by Hostname

Every RealFoyer site is a tenant in one shared database. Each site has a tenant key, and the platform works out which tenant a request belongs to from the hostname it arrives on, whether that is the agent's own domain or a RealFoyer subdomain. Custom domains are, as the CMS page puts it, “validated and issued an SSL certificate by the platform”.

A shared database fits a product whose tenants are many sites running the same code: there is one schema to migrate and no per-customer database to provision. The trade-off is that isolation is not given by separate databases; the tenant key has to be applied to everything that reads or writes tenant data. Branding, themes, menus and SEO fields are tenant data as well, so a new site is not a fork of the code.

We do not describe here how RealFoyer enforces that isolation inside the database. Our guide to building a multi-tenant real estate SaaS platform compares the three tenancy models and covers enforcing isolation in the database, tenant resolution and custom-domain TLS, and a pre-launch isolation checklist.

MLS Feeds: Integrated per Board, Activated per Agent

RealFoyer's first board integrations are the Toronto Regional Real Estate Board (TRREB), through PropTx, and MLS PIN. For TRREB, RealFoyer “connects there rather than through a third-party aggregator”; MLS PIN's data route is listed as “Direct / approved feed”. Other boards are on RealFoyer's roadmap, not live.

Having an integration with a board does not mean every agent in that market sees its listings. A feed is activated for an agent only after that agent's board has approved it. That puts the entitlement on the agent, not on the market or the platform: two agents in the same city can be at different stages, and the site of an agent without approval shows no feed from that board. RealFoyer says the same from the agent's side: its connection follows the board's entitlement, and its board pages state that it “implements what that agreement permits without widening it.”

On the wire, RealFoyer uses the RESO Web API “over OData as the primary route; the method depends on the MLS”. Its help center names “Trestle, MLS Grid, CREA DDF and PropTx” as the common routes, so each board's route is built and tested on its own. Our guides on getting MLS data access and the MLS data pipeline architecture cover the approval process and the feed routes in general.

Scheduled Sync, One Normalized Model, Reconciled Removals

Sync on a schedule, by design

RealFoyer does not stream listing changes. On its MLS integration page: “Listings, media and geocoding sync on cron rather than streaming, so a change on the board appears after the next run, not the same second.” Because boards publish at different cadences, the product “reports the actual sync status for your connection” rather than promising one refresh rate for every market. A scheduled pull is simpler to retry and to reason about than a stream, and the board's own publishing cadence limits freshness either way. Our guides on building an MLS synchronization engine and designing reliable background jobs cover checkpoints, incremental sync, retries and failure recovery in general terms.

Normalize before anything reads the data

Each board's feed is mapped into one model before search, listing pages or the map see it. RealFoyer lists what is imported: “Identifiers, status, price, address, details, photos, rooms, open houses, coordinates, price history and, where the board permits, sold history, with attribution and timestamps.” Attribution is carried with each listing because the board's display rules depend on it. Our guide to MLS data normalization across multiple boards covers identifiers, property types, units, media and rules that travel with the data.

Removals are part of the sync

A listing that leaves the feed must leave the site. RealFoyer states that “Status changes carry through; listings that leave the feed stop showing”, and that “listings removed at the source are reconciled rather than left behind.” Our guide to handling deleted, expired and sold listings covers the ways a removal reaches you and the reconciliation job.

Search: a Separate Index, Ungated Listing Pages

Normalized listings go to both the database and a search index, and search, property pages and map results are served from that path. Keeping the index separate means the store of record is not answering every filter change and map move.

Listing pages are open to everyone. RealFoyer's help center says listing pages are ungated by default, because “Gated listings are not indexed listings.” Registration is instead earned by saved searches: a visitor saves a search and chooses instant, daily or weekly alerts, and that opt-in is, as RealFoyer's board page puts it, “how an anonymous visitor becomes someone you can talk to.” Our guides cover designing a real estate search engine and reliable saved searches and listing alerts.

CRM: the Website Writes to the Lead

Because the website and the CRM share one data model, what a visitor does on the site lands on the same lead record the agent works from. The lead then moves through stages “from new and contacted through qualified, viewing booked, closed won and lost”, with tasks, assignment and routing for teams and brokerages.

Where a rule is enough, RealFoyer uses a rule. Its lead health score combines five factors (budget, activity, engagement, response and timeline fit), and the lead automation page says plainly: “No AI produces this score.” A rule-based score can be explained to the agent who has to act on it. Our guide to real estate CRM architecture covers capture, the contact timeline, property interactions, and assignment and routing in general terms.

Narrow Integrations and a Configurable CMS

Integrations are deliberately narrow and say what they do not do. New leads can be sent out to Zoho CRM, GoHighLevel or Zapier, and the integrations help page calls this “a one-time push outward, not an ongoing sync.” In the other direction, RealFoyer issues an inbound webhook URL and a token that another system can post leads to. A one-way push and a token-protected inbound endpoint are easy to secure and easy to explain. Our guide to reliable webhook and event-driven integrations covers signatures, idempotency keys, retries and reconciliation.

The site CMS follows the same restraint. It offers “Configurable sections and page controls, not a freeform canvas”: pages, menus, homepage sections, themes and per-page SEO fields, stored as tenant data. Saves publish to the live site with “no separate deploy”: a site is configuration on the shared platform, not its own codebase.

No outcomes published

This case study states no user counts, customer numbers, listing volumes, performance figures, uptime or business results for RealFoyer, because none has been published with a measurement we can stand behind. It also leaves out what we have not approved for publication:

• the names of the frameworks, databases, search engine and queue in RealFoyer's stack;
• hosting, environments and monitoring;
• development dates, team size and who built which part;
• how tenant isolation is enforced and tested inside the database.

If we publish any of these, it will be with how and when it was measured. Until then, the guides linked above explain how we approach each topic, and the MLS and IDX integration service describes how we would approach yours.

Written by Mukesh Swami, Founder & CEO