Case study · PropTech · Marketplace

ANT — PropTech marketplace and admin console

Published Apr 18, 2026 · Updated Apr 18, 2026 · By YuSMP Group Engineering

How we built a custom real-estate marketplace web platform — an apartment-level inventory grid, a faceted search experience, a listing CMS, and a multi-role admin console — for residential developers and brokers operating across the United States and the European Union.

IndustryPropTech · Marketplace

Project year2023

EngagementDedicated team

ANT PropTech marketplace — apartment-level inventory grid and faceted search on web

The brief — a real-estate marketplace that respects apartment-level inventory

The ANT product team wanted a PropTech marketplace that went beyond a flat list of listings. The core insight: residential developers in the United States and the European Union sell hundreds of units inside a single building, and buyers expect to see that inventory as a navigable apartment-level grid — not a scroll of cards. Off-the-shelf real-estate SaaS like Salesforce Real Estate Cloud and Bitrix24 covers brokerage CRM workflows, but none of it supports an apartment-grid public surface, a developer-controlled listing CMS, and a multi-role admin in one product. We built ANT from first principles as a Next.js marketplace backed by an Elasticsearch search tier, a Node.js / NestJS API, and a PostgreSQL system of record — a real-estate platform that ships as a single web product for buyers, developers, brokers, and city-level operators across US and EU markets.

Project highlights

Apartment-level inventory grid Faceted search on Elasticsearch Listing CMS with media library MapboxGL map search Multi-role admin console Developer + broker workflows Lead-capture pipeline US + EU data residency

By the numbers

A snapshot of what the ANT build delivered as a single web marketplace and admin platform in its first production cycle.

3distinct front-end surfaces — public marketplace, developer listing CMS, and multi-role admin console

15+facet dimensions in the search index — price, rooms, area, floor, orientation, status, finishes, district

<100mstypical p95 search response time on warm Elasticsearch cluster with Redis facet cache

4admin roles — system admin, developer back-office, broker, and read-only city operator

100%typed code base — TypeScript end-to-end across Next.js front end and NestJS back end

14–22 wktypical delivery window for a comparable PropTech marketplace MVP with admin console

ANT multi-role admin console — developer back-office and broker workflows on web

Why a custom marketplace stack over off-the-shelf real-estate SaaS

No off-the-shelf PropTech SaaS — Salesforce Real Estate Cloud, Bitrix24, or similar brokerage CRMs — combines an apartment-level inventory grid, developer-controlled listing CMS, faceted Elasticsearch search, and a multi-role admin in a single web product. These platforms are optimized for broker pipelines and per-seat licensing, not for a public-facing marketplace where ranking, SEO, and the inventory grid have to be owned end-to-end. Building ANT on top of one of them would have meant forking and overriding so much of the vendor schema that the SaaS gives no leverage — every assumption becomes a liability. We chose a custom Next.js build because the apartment grid, the facet UX, and the developer back-office all needed first-class data models that no off-the-shelf product exposes.

The inventory model alone is a custom commitment: a residential development decomposes into building → entrance → floor → unit, and each unit carries its own price, status, orientation, floor plan reference, and media bundle. Salesforce's standard real-estate object model treats a listing as a single record; expressing 240 apartments in a 30-floor tower as 240 such records and then asking the platform to render them as a clickable chessboard is not what it was built for. Our event-sourced indexer mirrors the PostgreSQL inventory into Elasticsearch on every state transition, so the public grid, the search facets, and the developer back-office never see a stale unit.

Custom Next.js marketplace vs Salesforce Real Estate Cloud vs Bitrix24 — at a glance
Dimension	Custom build (ANT)	Salesforce Real Estate Cloud	Bitrix24
Apartment-level inventory grid	Native — building → floor → unit chessboard with live status	Not available — listing is a flat record	Not available — CRM-style deal pipeline only
Faceted search performance	Elasticsearch + Redis facet cache, p95 <100 ms	SOQL on standard objects — limited facet UX	SQL filter on entity list — no live facet counts
Public SEO surface	Server-rendered Next.js — full control of routes, schema, sitemap	Experience Cloud — themed, limited route control	Site builder — limited schema and route control
Listing CMS for developers	Custom — media library, draft / publish, bulk unit edit	Standard Files object — no real-estate-specific media UX	Generic CMS bolt-on — no apartment-grid editor
Multi-role admin (developer / broker / operator)	Native RBAC with audit log per role	Strong RBAC, per-seat licensing scales with traffic	Role plans capped; admin UX is sales-team-shaped
Cost model at marketplace scale	One-time build + hosting; no per-seat penalty for public users	Per-seat enterprise license — costly for public marketplace teams	Tier-based pricing; advanced features behind higher plans
US and EU data residency control	Direct — separate partitions, independent key hierarchies	Available via Hyperforce, additional license required	Limited regional control on lower tiers

PropTech references: schema.org/Residence, Elasticsearch aggregations, Next.js documentation.

ANT marketplace — apartment inventory grid with live status colors and unit drill-in

Web marketplace build — Next.js, apartment-grid inventory, MapboxGL search

The public marketplace is built in Next.js with React and TypeScript, server-rendered for SEO and hydrated for interactive search. The apartment-grid component is the centerpiece: each residential development page renders a chessboard of units, colored by status (available, reserved, sold), grouped by floor and entrance. Buyers can filter the grid by room count, price band, area, floor range, and orientation; selecting a cell opens a drawer with the unit's floor plan, finishes, view direction, and lead-capture form. The grid and the global search share a single Elasticsearch index — there is no separate data path for the development page and the marketplace listing page.

Map search is implemented on MapboxGL with a custom clustering layer for the United States, the European Union, and other markets. Listings outside the visible viewport are dropped from the response payload; clusters expand to per-building markers below a configured zoom level. The map and the result list are bound to the same Elasticsearch query, so pinning a price filter on the list updates the map markers in the same paint. Internal links from the marketplace flow into our web application development service surface for teams planning similar PropTech builds.

ANT listing CMS — developer back-office for unit editing, media library, and publish workflow

Listing CMS — developer back-office, media library, bulk unit editor

The listing CMS is the surface residential developers and brokers actually live in. It is built on the same Next.js front end with a NestJS API tier, so the schema the CMS edits is the schema the public marketplace renders — no export/import step, no nightly sync. Developers can author a building, define its floors and entrances, then either enter units one at a time or bulk-edit a CSV-style table with column-level validation. Each unit has its own price, status, area, room count, orientation, view direction, finish package, and a media bundle of floor plan, renders, and photographs.

The media library uses S3 for storage and a derivative pipeline that produces optimized WebP variants at the resolutions the public grid and unit drawer actually request. A draft / publish workflow means a developer can stage a price change or a status flip overnight and publish it atomically the next morning — the marketplace and the search index update in lockstep via the event-sourced indexer. Role-based access lets a broker edit only the units assigned to them, while a developer back-office user can edit the whole development. This pattern is the same one we use across our custom software development engagements.

ANT content CMS and admin — marketing pages, district guides, and lead pipeline view

Content CMS, admin console, and the security posture behind both

Beyond unit-level inventory, ANT ships with a content CMS for marketing pages — district guides, mortgage explainers, developer brand pages — and an admin console for the operations team. The content CMS uses a block-based editor with constrained content types, so a marketing manager cannot accidentally break the page schema that the SEO surface depends on. The admin console layers four roles on top: system admin, developer back-office, broker, and read-only city operator. Each role has its own audit log; permission changes themselves are audit-logged. Lead capture, saved searches, and analytics opt-ins are processed through a region-aware consent flow aligned with GDPR in the European Union and with CCPA / CPRA in California and the other US state-privacy regimes.

Application security follows the OWASP Top 10 as a baseline. Authentication runs on rotating short-lived tokens with refresh; sensitive admin actions require step-up confirmation; all server-side input is validated with typed schemas at the controller boundary; uploads are streamed through a virus-scanning gate before they reach S3. US and EU user data is partitioned into independent PostgreSQL clusters with separate encryption key hierarchies, so a future data-residency commitment in either region is a configuration change, not a schema migration.

Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.

Delivery methodology

A five-phase build that took ANT from product brief to a production PropTech marketplace with listing CMS and multi-role admin console.

Phase 1

Discovery & data model

Inventory taxonomy (building → floor → unit), facet inventory, role and permission map, US and EU privacy posture, public-route and SEO schema design.

Phase 2

Marketplace front end

Next.js public marketplace, apartment-grid component, MapboxGL map search, faceted result list bound to a shared Elasticsearch query.

Phase 3

Listing CMS & indexer

Developer back-office, media library, draft/publish workflow, event-sourced indexer keeping PostgreSQL and Elasticsearch in lockstep.

Phase 4

Admin console & security

Multi-role RBAC, audit logs per role, OWASP-aligned hardening, region-aware consent, lead-capture pipeline, broker workflows.

Phase 5

Launch & iteration

US and EU rollout, Kubernetes-based deploy on Terraform-provisioned infra, observability stack, search-quality A/B framework, on-call rotation.

The lead pipeline, broker workflows, and CRM bridge

ANT's monetization surface lives in the lead pipeline. Every unit drawer, district page, and developer profile carries a typed lead-capture form; submissions land in a NestJS service that deduplicates by phone and email, scores by source and recency, and routes to the right broker based on the unit's building and floor. Brokers see their queue inside the admin console, with one-click status transitions (new → contacted → tour booked → reserved → sold) and a free-text note field that becomes the audit trail. A webhook layer pushes lead events outbound to the developer's CRM of choice — Salesforce, HubSpot, or Bitrix24 — so the marketplace never becomes the system of record for the developer's deal pipeline. Saved searches push email digests to buyers when new units matching their facet combination enter the index; the digest cadence respects the user's consent state and is suppressed for users in the European Union who have not opted in to marketing communications. Across United States markets, the same digest engine respects the CCPA / CPRA "Do Not Sell or Share" preference. The whole pipeline was built so that adding a new lead source, a new broker role, or a new CRM target is a configuration change, not a code release.

Launching across the US and EU — privacy law, data residency, and SEO

ANT launched as a single web product serving buyers and developers across the United States and the European Union. Users in California, New York, Texas, and Florida in the US, and users in Germany, the Netherlands, France, Sweden, and Ireland in the EU, hit the same Next.js application with region-aware content negotiation. Consent flows are region-aware: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for analytics and marketing; users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure. Data-handling practices are aligned with GDPR for European Union users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA.

The back end separates EU and US user data into independent PostgreSQL partitions with separate encryption key hierarchies, enabling a future data-residency commitment in either region without a schema migration. The Elasticsearch indexer runs stateless workers that can be pinned to EU or US regions independently. Public SEO is built on a JSON-LD schema with Residence and Offer types so that residential developments appear correctly in Google's rich-result surfaces; sitemap generation is automatic and respects the listing CMS's publish workflow. EU data-protection compliance and California CCPA obligations are documented in the in-app privacy policy and a data-processing agreement template provided to the client for their DPA with EU sub-processors. The whole platform is operated on a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, demos, and incident response.

Tech stack and roadmap

TypeScript Next.js React Node.js NestJS PostgreSQL Elasticsearch Redis MapboxGL S3 Docker Kubernetes Terraform Event-sourced indexer OWASP-aligned hardening JSON-LD (Residence, Offer)

The active custom software development roadmap for ANT includes a mortgage-affordability calculator embedded in the unit drawer, a saved-search email digest with per-facet alerting, an offline-friendly broker workspace for on-site tours, and a public partner API so city planners across the European Union can pull anonymized listing-density data for housing-policy research. Infrastructure plans cover moving the Elasticsearch cluster to a dedicated tier with sub-50 ms search SLO, expanding the cloud & DevOps footprint to multi-region active-active, and rolling out a per-tenant analytics dashboard that surfaces lead quality by broker, building, and acquisition channel.

Frequently asked questions

How much does it cost to build a custom real-estate marketplace?

A focused PropTech marketplace MVP covering public listings, search and filters, a developer-facing listing CMS, and a basic admin console typically costs $140k–$320k. Adding an apartment-level inventory grid, MapboxGL map search, lead-capture with CRM integration, and a multi-role admin with audit logs brings a full platform to $320k–$750k. The dominant cost drivers are the search infrastructure (Elasticsearch tuning, facet UX), the inventory data model (building → floor → unit), and the role and permission system required for developers, brokers, and city-level operators across US and EU markets.

Why build a custom PropTech marketplace instead of using Salesforce Real Estate Cloud or Bitrix24?

Off-the-shelf real-estate SaaS — Salesforce Real Estate Cloud, Bitrix24, and similar — is optimized for brokerage CRM workflows, not for a public-facing marketplace with apartment-level inventory grids and developer-controlled listing CMS. They impose fixed data schemas, per-seat pricing that scales poorly with public traffic, and template-based UI that cannot host the chessboard-style apartment grid buyers expect on a residential-development page. A custom Next.js build on Elasticsearch gives full control of the search ranking, the inventory model, and the public SEO surface — none of which is configurable inside Salesforce or Bitrix24 at the level a serious PropTech operator needs.

What does an apartment-level inventory grid look like, and why does it matter?

An apartment-level inventory grid renders a residential development as a chessboard: each building, floor, and unit is a clickable cell colored by status (available, reserved, sold). Buyers can filter the grid by room count, price band, floor range, and orientation, then drill into a specific unit's floor plan, finishes, and price. It matters because, in the United States and the European Union, residential developers list hundreds of units at once — without a grid view, a buyer has to scroll through a flat list and the conversion rate collapses. The grid also doubles as the developer's internal inventory dashboard, so the listing CMS and the public marketplace share a single source of truth.

How do you handle faceted search at marketplace scale?

Production-grade faceted search for real estate runs on Elasticsearch with carefully tuned mappings: geo_point for map search, nested objects for unit attributes, and aggregations for facet counts on every query. Each facet panel (price, rooms, area, floor, orientation, status) shows live counts that update as filters are applied, which requires a single query returning both hits and aggregations. Caching the hot filter combinations in Redis cuts response time to under 100 ms for the common cases. PostgreSQL remains the system of record; Elasticsearch is rebuilt from the database via an event-sourced indexer so the search index never drifts from the inventory truth.

How do US and EU data-residency rules affect a PropTech marketplace build?

In the European Union, GDPR requires that personal data of EU residents — leads, saved searches, contact details — be processed in a documented way with a clear lawful basis and a data-processing agreement with sub-processors. In the United States, CCPA and CPRA in California, VCDPA in Virginia, CPA in Colorado, CTDPA in Connecticut, UCPA in Utah, TDPSA in Texas, and Oregon CPA each require a "Do Not Sell or Share" disclosure and opt-out mechanism. ANT was built with US and EU user data in separate database partitions with independent encryption key hierarchies, so a future residency commitment in either region does not require a schema migration.

Build a PropTech marketplace like this — talk to us

If you are planning a real-estate marketplace, a listing platform with apartment-grid inventory, or a multi-role admin for residential developers and brokers in the United States and the European Union, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The engineering team behind ANT sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.

Talk to us about a similar build See web development services

Related services