How to Build a White-Label Property Portal for Estate Agencies

A white-label property portal is one multi-tenant platform that gives each agency its own branded site, domain and admin, while listings, leads and documents stay isolated per agency in a shared database. In the UK and UAE, it also has to hold market data such as Part A material information or a Dubai ad permit. BlockEstate, the multi-tenant listing platform RAITHub built, reached MVP in 6 weeks.

This guide is for agency groups, franchise networks and PropTech founders who want to give many agencies their own portal without building many portals. It covers the architecture, the UK and UAE listing rules the data model has to carry, and the part people most often get wrong: sending listings to the big portals. RAITHub is a software studio in Dhaka, Bangladesh. It has no UK or UAE office, and it has not built a portal feed or MLS integration, so where this guide touches those it says so. Anything about permits, advertising rules or agency regulation is general information, not legal advice; confirm the current rule with your adviser.

What is a white-label property portal, and who is it for?

It is a listings platform you run once and rent out many times, each time under a different agency's brand. Every agency gets its own website, logo, colours and domain, its own agents and its own leads. Underneath, one codebase and one database serve all of them.

Three kinds of buyer ask for one:

• Agency groups and franchise networks that want every branch or franchisee on the same system, with head office able to see across them.
• PropTech founders selling a portal-in-a-box to independent agencies on a monthly plan.
• Developers or brokerage networks that want a shared search across partners, plus a branded site for each.

What they have in common is that the agency, not the platform, is the brand the buyer sees. That single fact drives most of the design.

Should each agency get its own portal, or one shared platform?

One shared, multi-tenant platform, unless a contract forces separation. A tenant here means one agency: its settings, users, listings, leads and documents. Running a separate copy per agency looks simpler on day one and becomes the expensive option by agency twenty, because every fix and feature has to be deployed twenty times.

Approach	How it works	Fits when	Main cost
Shared schema, row-level isolation	All agencies in one database; every row carries an agency_id; the database enforces who sees what	Most white-label portals, from 5 to hundreds of agencies	Isolation must be designed in and tested on every table
Schema or database per agency	Each agency gets its own schema or database; one codebase	A few large agencies with contractual separation	Migrations and reporting across tenants get harder
Separate deployment per agency	A full copy of the app per agency	Almost never for a portal product	Every release multiplied by the number of agencies

The trade-offs are covered in depth in database-per-tenant vs shared schema and multi-tenant vs single-tenant SaaS. For a portal, the shared schema usually wins, because a network-wide search across agencies is a single query instead of a federation problem.

What features does a white-label property portal need?

Two sets: what each agency's buyers and agents see, and what the platform owner needs to run many agencies. A first release should cover the loop from listing to answered inquiry, and nothing more.

Area	First release	Later
Branding	Logo, colours, agency name, custom domain or subdomain	Custom page layouts, per-agency content pages
Listings	Agent-entered listings with validation, photos, a moderation step, publish and unpublish	Bulk import from an agency's existing system, with its written permission
Search	Filters and map search per agency site	Network-wide search across agencies, saved searches and alerts
Leads	Inquiry form, routing to the right agent, agent dashboard	SLA reminders, reassignment rules, reporting
Roles	Platform admin, agency admin, agent	Moderators, branch managers, read-only head office
Market data	The fields your market requires on a listing (see below)	Automated checks against a regulator's API, where you are eligible
Billing	Manual invoicing per agency	Self-serve plans, usage-based limits

Lead handling and moderation are where portals differ most from a normal website. The listing lifecycle and inquiry flow are covered in how to build a real estate marketplace, and the agent-side tooling in building a real estate CRM for agents.

How do you keep one agency's listings and leads away from another's?

Put the agency on every row and make the database enforce it, not just the application code. A missing where agency_id = ... in one query is the classic way a multi-tenant portal leaks another agency's leads, and leads are exactly what agencies pay to keep private.

PostgreSQL's row-level security lets tables "have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted" (PostgreSQL: row security policies). The same page notes that table owners normally bypass those policies unless the table uses FORCE ROW LEVEL SECURITY, which is why the example below sets it. A minimal listing schema:

create table agencies (
  id         uuid primary key default gen_random_uuid(),
  slug       text unique not null,          -- acme.yourportal.com
  name       text not null,
  theme      jsonb not null default '{}'     -- logo URL, colours
);

create table agency_domains (
  host        text primary key,             -- www.acme-homes.co.uk
  agency_id   uuid not null references agencies(id),
  verified_at timestamptz                   -- null until DNS is proven
);

create table listings (
  id          uuid primary key default gen_random_uuid(),
  agency_id   uuid not null references agencies(id),
  agent_id    uuid not null,
  status      text not null default 'draft',
  price_minor bigint,                       -- pence or fils, never floats
  market      text not null check (market in ('uk', 'dubai')),
  permit_ref  text,                         -- Dubai ad permit reference
  council_tax_band text,                    -- UK Part A field
  tenure      text                          -- UK Part A field, for sales
);
create index on listings (agency_id, status);

alter table listings enable row level security;
alter table listings force row level security;

-- Agency staff see and write only their own agency's rows.
create policy agency_isolation on listings
  using (agency_id = current_setting('app.agency_id', true)::uuid)
  with check (agency_id = current_setting('app.agency_id', true)::uuid);

The application sets the agency once per transaction, from the signed-in user's session, never from anything the browser sends:

await client.query('begin')
// true = local to this transaction, so a pooled connection cannot leak it
await client.query("select set_config('app.agency_id', $1, true)", [session.agencyId])
const { rows } = await client.query("select * from listings where status = 'active'")
await client.query('commit')

If app.agency_id is not set, current_setting(..., true) returns null and the policy matches no rows; on a reused connection it can return an empty string, which fails the uuid cast with an error. Either way a forgotten setting fails closed. The public search pages need a separate, read-only database role with a policy that allows only published listings. The full pattern, including testing it in CI, is in the Postgres row-level security guide; the symptoms of getting it wrong are in users can see other tenants' data.

How do custom domains and branding work on a white-label portal?

The platform works out which agency a request belongs to from the host name, then loads that agency's theme. Two patterns cover nearly every case: a subdomain you control (acme.yourportal.com) and the agency's own domain pointed at your platform.

interface Db {
  oneOrNone<T>(sql: string, params: unknown[]): Promise<T | null>
}
type Agency = { id: string; slug: string; name: string; theme: Record<string, string> }

const PLATFORM_SUFFIX = '.yourportal.com'

export async function agencyForHost(host: string, db: Db): Promise<Agency | null> {
  const hostname = host.toLowerCase().split(':')[0]
  if (hostname.endsWith(PLATFORM_SUFFIX)) {
    const slug = hostname.slice(0, -PLATFORM_SUFFIX.length)
    return db.oneOrNone<Agency>('select * from agencies where slug = $1', [slug])
  }
  // Custom domains only resolve once DNS ownership has been verified.
  return db.oneOrNone<Agency>(
    'select a.* from agency_domains d join agencies a on a.id = d.agency_id where d.host = $1 and d.verified_at is not null',
    [hostname],
  )
}

Three details save pain later. Verify that an agency controls a domain before it resolves, or anyone can point a domain at your platform and borrow its content. Issue TLS certificates automatically through your host's custom-domain feature rather than by hand. And cache the host lookup, because it runs on every request.

Search engines also treat each agency site separately. Each one needs its own sitemap, canonical URLs and robots.txt generated from its host, or agency sites end up competing with each other and with your network-wide search for the same listing.

What listing data do UK and UAE agency portals have to carry?

Whatever the market's rules require on an advert, stored as real fields so the platform can block publishing when they are missing. The rules belong to regulators, not to the software, so the platform's job is to hold the data and enforce the gate your adviser specifies.

Market	What applies to listings	What the portal should do
Dubai	DLD's Real Estate Ad Permit, applied for through Trakheesi; brokers need a marketing contract with the owner for most permit types; listed at AED 1,000 plus a AED 20 knowledge fee for most permits (DLD: Real Estate Ad Permit)	Store the permit reference per listing; block publishing without one; show it where your adviser says it must appear
Dubai	DLD's Trakheesi API offers a Listing Validation API that "validates property listings and associated advertisement permits", and a Delisting API (DLD API Gateway)	If a licensed UAE entity subscribes, validate on submit and unpublish delisted properties
UK	National Trading Standards' Part A material information: price or rent, council tax band, and tenure for sales (NTSELAT: Part A guidance)	Make these required fields; flag listings that lack them
UK	Further material information (Parts B and C) and agency redress rules, such as membership of a scheme like The Property Ombudsman	Confirm the current rule with your adviser, then model it as fields and checks

NTSELAT notes that the major UK portals, including Rightmove, Zoopla, OnTheMarket and PropertyPal, added Part A fields and flag listings where agents leave them empty. A white-label portal that agencies use alongside those portals should hold at least the same fields, or agencies will keep their real data somewhere else. The DLD API subscription belongs to a licensed UAE entity, not to an offshore developer; the detail is in building a UAE real estate platform.

Can a white-label portal push listings to Rightmove, Bayut or Property Finder?

Only through each portal's own data feed programme, on the portal's terms. Those feeds are licensed and controlled by the portals, and each decides who may send listings, in what format and at what price. RAITHub has not built a Rightmove, Bayut or Property Finder feed, and has not built an MLS or IDX integration; BlockEstate's listings come through agent intake.

What that means in practice:

• Ask the portal first. Rightmove, for example, sells memberships to agents and asks them to get in touch to discuss options (Rightmove: advertise with us). Whether your platform can send listings on an agency's behalf is the portal's decision, made in writing.
• Design an export boundary anyway. Keep listings in a clean, normalised model with an outbox table of changes, so a feed can be added later without reshaping the data.
• Never scrape portals to fill your own. It usually breaches their terms of use, and it puts the agencies on your platform at risk too.

In the US the equivalent question is MLS access, which works the same way: the MLS licenses the data. The MLS and IDX integration guide explains that route.

How much does a white-label property portal cost to build?

Published 2026 market guides put a basic listing portal at $20,000–$40,000 and a mid-range one with map search and agent tools at $40,000–$80,000, as summarised in the cost to build a real estate platform. Those are market figures, not RAITHub quotes. White-labelling adds a specific set of work on top of a single-brand portal:

Component	What drives the effort	Running cost to plan for
Tenant isolation	Number of tables, and testing every policy	None beyond the database
Branding and custom domains	Theme depth; domain verification and certificates	Per-domain fees on some hosts
Listing intake and moderation	Validation rules per market; number of states	Image storage and CDN bandwidth
Map search	One region or many; filters	Map and geocoding API usage
Lead routing	Routing rules and reassignment	Email and SMS sending
Regulator checks	Which APIs your licensed entity subscribes to	DLD lists each API at AED 30,000 plus VAT a year
Portal feeds	Only after a portal approves you	Set by each portal

RAITHub publishes no rates: a free 15-minute technical audit is followed by a fixed written quote. The MVP cost estimator gives a quick range for your own scope.

Why RAITHub for this?

Because the hard part of a white-label portal, many agencies on one platform with nothing leaking between them, is what RAITHub's PropTech proof is built on.

• BlockEstate is a multi-tenant listing and inquiry platform for agents and brokerages, with each brokerage isolated as a tenant. It has validated listing intake with normalisation, geocoding and deduplication, an 11-state moderation lifecycle, agent dashboards, lead routing and a document workflow, 4 roles (admin, moderator, agent, user), and white-label capability in its partner plans. The MVP shipped in 6 weeks with 2 engineers, 1 designer and 1 QA. See the BlockEstate case study.
• Isolation enforced by the database. Sundor Skin, a B2B wholesale platform RAITHub built, runs 146 PostgreSQL tables with row-level security, and its CI fails if a buyer-scoped table lacks a policy.
• Working hours. Dhaka is UTC+6, so there are about 3 to 4 shared working hours with the UK (3 in winter, 4 in summer) and about 7 with Dubai. The working week is agreed per client, with written daily handoffs.
• Fixed scope. Portals are built under SaaS development as fixed-scope work or with a monthly dedicated team. You own the code, and an NDA is standard.

When you don't need us

• You are one agency that wants a website. A portal membership plus a website product from your CRM vendor is quicker and cheaper than a platform.
• Your plan depends on a portal feed from day one. Get the portal's written approval first, and if you want a vendor that has already shipped that feed, RAITHub cannot cite one.
• You need Arabic content written, or a team in London or Dubai. RAITHub builds and tests right-to-left interfaces but delivers in English only, and has no local office.
• You need native mobile apps at launch. RAITHub builds web applications.
• You need advice on advertising or agency rules. That is for a qualified adviser in your market.

The real estate industry page covers what RAITHub builds for PropTech. If a white-label portal is your plan, book the free 15-minute technical audit and bring your market, how many agencies you expect in year one, and where listings will come from.

DLD, NTSELAT, The Property Ombudsman, Rightmove and PostgreSQL sources checked on 30 September 2026.

Frequently asked questions

What is a white-label property portal?

A single listings platform that each agency uses under its own brand, domain and admin. Listings, agents, leads and documents are kept separate per agency, while one codebase and one database serve all of them.

Is it better to give each agency its own database?

Usually not. A shared schema with row-level security suits most white-label portals and makes network-wide search simple. A database or schema per agency fits a few large agencies with contractual separation requirements.

Can my white-label portal send listings to Rightmove or Bayut?

Only if the portal approves it, through its own data feed programme and terms. Those feeds are licensed by the portals. RAITHub has not built a Rightmove, Bayut or Property Finder feed, so plan the platform to work without one.

Do Dubai listings on my portal need a permit number?

DLD issues a Real Estate Ad Permit through Trakheesi, and its API gateway offers listing and permit validation. Store the permit reference per listing and block publishing without it. Confirm the current rule with a UAE-qualified adviser.

What must a UK property listing show?

National Trading Standards' Part A material information covers price or rent, council tax band, and tenure for sales. Further material information applies too; confirm the current requirements with your adviser before you design the listing form.

How long does it take to build a white-label property portal?

A focused first release, with agency tenants, branding, listing intake, search and lead routing, is a matter of weeks at fixed scope. BlockEstate, RAITHub's multi-tenant listing platform, reached MVP in 6 weeks.