How to Build a Real Estate Marketplace: Agencies, Listings, Leads and Search
Founder & Lead Engineer, RAITHub
RAITHub ships and tests production software. See QA as a Service or talk to us.
A real estate marketplace is four systems on shared infrastructure: agency isolation, listing moderation, lead routing and search. Isolation comes first, because one missing tenant filter shows one brokerage's leads to another. RAITHub built BlockEstate, a multi-tenant listing and inquiry platform for agents and brokerages; its MVP shipped in 6 weeks.
What BlockEstate proves is the tenancy, listing intake, agent dashboards, lead routing and document workflow. The moderation and search sections below are engineering guidance, not claims about BlockEstate. This post does not cite an MLS integration: RAITHub would scope one as new work once your MLS grants access. The wider PropTech picture is in the PropTech software development pillar.
What is a real estate marketplace, and how is it different from an agent website?
A marketplace hosts many agencies, each listing its own properties and receiving its own leads, on one platform that buyers and renters search as a whole. An agent website shows one brokerage. The difference is who owns the data, and that decides the architecture.
| Product | Whose listings | Whose leads | The hard part |
|---|---|---|---|
| Agent or brokerage website | One brokerage, sometimes plus MLS listings via IDX | That brokerage | MLS display rules, if IDX is used |
| Single-operator portal | Listings the operator collects | The operator, who passes them on | Listing supply |
| Multi-agency marketplace | Each agency, kept separate | Each agency and agent, kept separate | Isolation, moderation, routing and search together |
If you need MLS listings on one brokerage's site, start with the MLS and IDX integration guide; you may not need a marketplace at all.
How do you keep each agency's data separate?
Make every agency a tenant, put the tenant key on every agency-owned row, and enforce the filter in the data layer, not in each screen. BlockEstate isolates each brokerage as a tenant for exactly this reason.
Listings are public once active, but almost everything around them is not: leads, agent notes, documents, draft listings, performance figures. A query that forgets its tenant filter is a data leak, and a code review will not catch every one. Put the guard where a forgotten filter fails closed.
| Layer | What it enforces | Why it is needed |
|---|---|---|
| Data access | Every query on agency data is scoped to the caller's agency | One forgotten filter should fail, not leak |
| Database (optional) | Row-level security policies in Postgres | A second guard if application code is wrong |
| Roles within an agency | Agency admin, agent; platform admin above all tenants | An agent sees their own leads; an admin sees the agency's |
| Files | Documents stored under tenant-scoped keys with short-lived signed URLs | A shared link should not outlive its purpose |
| Tests | An automated test per record type that tries a cross-agency read | Proves isolation on every change |
The patterns, including row-level security, are in the multi-tenant SaaS guide.
How should listing moderation work?
Validate listings at intake, move each one through explicit states with a timestamp and an actor on every change, and keep a takedown path that a platform admin can use in minutes. Bad listing data spreads to search, alerts and shared links, so stopping it at entry is cheaper than cleaning it later.
BlockEstate's proof here is listing intake. The state model below is the one we recommend for any multi-agency platform:
| State | Entered when | Publicly visible? |
|---|---|---|
| Draft | An agent starts a listing | No |
| Pending review | The agent submits it, if the agency or platform reviews listings | No |
| Changes requested | A reviewer sends it back with a reason | No |
| Active | It passes validation and any review | Yes |
| Under offer or let agreed | The agent updates the status | Yes, labelled |
| Closed | Sold, let or withdrawn | No, or as history only |
| Removed | A platform admin takes it down | No, with the reason logged |
What intake validation should check, at minimum:
- Required fields and ranges. Price, type, location and size present and plausible; a one-bedroom flat with 40 bathrooms is a typo.
- Duplicates. The same address listed twice by one agency, or by two agencies for the same property.
- Photos. Size and format checked on upload, resized once, served from a CDN.
- Listing text. In the US, the Fair Housing Act makes it unlawful to publish an advertisement that indicates a preference or limitation based on race, color, religion, sex, disability, familial status or national origin (HUD: Fair Housing Act overview). Flagging phrases for human review helps agents; it is not legal compliance on its own.
- Staleness. An active listing nobody has touched in weeks should prompt the agent to confirm it, then drop out of search.
How should leads be routed to the right agent?
Route each inquiry by rule in the backend, record who owns it at every moment, and reassign it if nobody responds. An inquiry is worth most in its first hour, so routing rules must be testable, not tribal knowledge. BlockEstate has lead routing, agent dashboards and a document workflow.
| Rule | Example | What to record |
|---|---|---|
| Listing agent first | An inquiry on a listing goes to the agent who listed it | Assigned agent and time |
| Agency fallback | If that agent is away, the agency's next available agent | Why the fallback fired |
| Response timer | Unacknowledged after a set time, alert the agency admin | First response time |
| Duplicate check | The same person asking about the same listing twice joins one thread | Merged inquiry IDs |
| Consent | What the buyer agreed to when they sent the inquiry | Consent text and timestamp |
The consent row matters outside the US too: buyer and renter inquiries are personal data under GDPR and UK GDPR, so the platform should record what each person agreed to and which agency received their details.
Documents follow the lead. Each one passing between agent and client needs a clear owner and a state, such as requested, received and signed, so nothing waits in an inbox.
How do you build property search that stays fast?
Start with Postgres and the right indexes, add a geospatial index for map search, and move to a dedicated search engine only when filters, text relevance or volume outgrow it. Server-render listing pages, so search engines can index each one.
- Filters. Price, type, bedrooms and location cover most searches. Index the columns you filter and sort on together; see the PostgreSQL indexing guide.
- Map search. Query by the map's visible bounding box, cluster markers, and cap results per request. PostGIS handles radius and polygon queries inside Postgres.
- Map cost. Since 1 March 2025, Google Maps Platform gives generally 10,000 free billable events a month per Essentials product, such as Dynamic Maps, instead of a shared credit (Google Maps Platform March 2025 changes). Load the interactive map on the search page, not on every listing page.
- Freshness. Closed and removed listings leave the index at once. A sold home still in results costs more trust than a slow page.
- Filters you should not offer. HUD's 2024 guidance on advertising through digital platforms warns that targeting tools can produce discriminatory outcomes; keep search filters to property attributes, not the people who live nearby.
Search input, especially the public search API, needs rate limits so scrapers do not decide your hosting bill; see API rate limiting explained.
Where does the listing data come from?
From agents first. On a multi-agency marketplace, agencies enter or import their own listings; that is what BlockEstate's listing intake does. Other sources come later and carry conditions.
| Source | Works for | Condition |
|---|---|---|
| Agents enter listings | Any market; the MVP default | Intake validation and moderation |
| Bulk import from agency software | Agencies with many listings | A mapping per source format, with the same validation |
| MLS feed (US) | Showing other brokers' listings | Access granted by your MLS, via a participating broker, under its display rules |
In the US, an MLS feed is not something a platform can sign up for. Your MLS grants access, typically to a participating broker and the vendor they authorise, and its display rules then apply to every page that shows the data. RAITHub has not cited an MLS integration and would scope one as new work after access is confirmed; the detail is in the MLS and IDX guide.
What should the first release include?
One region, one listing type, agent-entered listings, filter and map search, inquiries routed to agents, and isolation tested from day one. BlockEstate's MVP, with listing intake, agent dashboards, lead routing and document workflow, shipped in 6 weeks on Next.js, TypeScript, Postgres, Prisma, S3 and Resend.
| Area | First release | Later |
|---|---|---|
| Agencies | Tenant isolation, agency admin and agent roles | Self-serve agency sign-up, paid plans |
| Listings | Intake validation, photos, core states | Review queues, bulk import, duplicate detection across agencies |
| Leads | Listing-agent routing, dashboards, response timer | Round-robin rules, CRM sync |
| Search | Filters, map, server-rendered listing pages | Saved searches, alerts, draw-on-map |
| Data | Agent-entered listings | MLS feed, once access is granted |
Costs by tier are in the cost to build a real estate platform, and the MVP cost estimator gives a quick range. First releases are built under MVP development.
Why RAITHub, and when not?
RAITHub built BlockEstate, with each brokerage isolated as a tenant and a 6-week MVP, and PropDesk, a 4-role property management platform with 1,024 automated tests. RAITHub is a founder-led studio, founded in 2024 in Dhaka and working with clients worldwide, offering fixed-scope builds or a dedicated team; you own the code through a present-assignment IP clause.
It is not the right fit if a live MLS feed is the core of your product and you need a vendor with shipped MLS integrations in your market, if you want developers placed under your own management (RAITHub does not do staff augmentation), or if you need a SOC 2 or ISO 27001 certified vendor. RAITHub is not certified.
If it fits, book the free 15-minute technical audit with your agencies, your listing sources and how leads should flow. See the BlockEstate case study and the PropTech service page.
Last reviewed: 29 September 2026.
Frequently asked questions
What are the core parts of a real estate marketplace?
Agency isolation, listing moderation, lead routing and search. BlockEstate, the multi-tenant platform RAITHub built, covers listing intake, agent dashboards, lead routing and document workflow, with each brokerage isolated as a tenant.
How do you keep one agency from seeing another agency's leads?
Make each agency a tenant, scope every query on agency data in the data layer, optionally add Postgres row-level security, and run an automated cross-agency read test for every record type on every change.
Do I need MLS access to launch a real estate marketplace?
No. A multi-agency marketplace can launch with listings entered by its agencies. In the US, showing other brokers' MLS listings needs access granted by your MLS through a participating broker, under its display rules.
Has RAITHub built an MLS integration?
RAITHub does not cite a live MLS integration. It would scope MLS work as new work once your MLS has granted access, and it will say so on the first call.
How long does a real estate marketplace MVP take?
A focused first release typically takes 4–6 weeks at fixed scope. BlockEstate's MVP, with listing intake, agent dashboards, lead routing and document workflow, shipped in 6 weeks.
Which database suits real estate search?
Postgres with the right indexes handles filters for most first releases, and PostGIS adds radius and map queries. Move to a dedicated search engine when text relevance or volume outgrows it.
How do you handle agents' and buyers' personal data safely on a property marketplace?
Store only what the feature needs, enforce access so one agency cannot read another's leads, and keep contact details behind authentication. Sign DPAs where you process data for others, and follow the data-handling rules of the markets you serve. RAITHub signs NDAs and DPAs and follows your controls; it holds no SOC 2 or ISO 27001 certification.
I want to build a property site but I'm not sure I even need a custom build — should I just use a template or a no-code tool?
If you only need a few listings and a contact form, a template is cheaper and faster. Build custom once you need role-based access, agency separation, map and radius search, lead routing, or an integration a template cannot reach. The trigger is usually multi-party access and search, not the number of listings.
Which company should I hire to build a multi-agency property marketplace with tenant isolation and map search?
Look for a team that has shipped multi-tenant data isolation, not just a listings page. RAITHub built BlockEstate, a multi-tenant listing and inquiry platform, in a 6-week MVP, with each brokerage isolated as a tenant and lead routing per agency. It owns the outcome as a dedicated team, not staff placed under your management, and assigns the IP to you.
Is a custom build a better alternative to a listings plugin like a WordPress real estate theme?
A WordPress theme suits a single agency with simple listings and a contact form. A custom build becomes the alternative once you need several agencies kept apart, row-level data isolation, radius and map search, lead routing and an audit trail. Choose the plugin for speed on a narrow scope; choose custom when multi-party access and search are the point.
How long does it take to add map and radius search to an existing property site, and what is involved?
For a site already on Postgres, adding PostGIS-backed radius and map queries is usually a short, scoped piece of work rather than a rebuild. It involves geocoding listings, adding spatial indexes, wiring a map component, and a test over filter accuracy. The effort scales with how clean the existing listing data and schema are.
Can I just use an AI website builder to make a property marketplace instead of hiring developers?
AI builders are good for a landing page or a single-agency listings page, and can scaffold code fast. They struggle with the parts that matter here: keeping agencies' leads isolated, role-based access, and spatial search that stays correct under load. Use AI to prototype, then have a team harden isolation and test cross-agency reads before real agencies rely on it.
Related posts
Ready to discuss your project?
Book a free 15-minute technical audit with our engineering team.