TL;DR

  • Your real estate platform loses 67% of searchers before the first listing renders if pages take longer than 2 seconds to load. Next.js server components, edge caching, and incremental static regeneration (ISR) keep response times under 800ms -- even with 250,000+ listing pages.
  • Draw-to-search, mortgage calculators, and school catchment overlays are the features that separate a platform buyers bookmark from a directory they bounce.
  • Agents abandon back-end dashboards that feel slow or clunky, and stale listings destroy buyer trust faster than any missing feature.
  • You can build a Zoopla-grade experience without Zoopla's budget by pairing Next.js with Supabase (PostGIS), Mapbox GL JS, and Payload CMS.
  • Social Animal has shipped 12 property platforms since 2021 -- this post shares the architecture, data models, and conversion patterns we reuse on every build.

Why do most real estate websites lose buyers before a single listing loads?

Picture this: your buyer drags the map boundary to a new postcode. The spinner turns. One second. Two seconds. Three seconds -- nothing renders. They close the tab and open Zoopla instead. You just lost a qualified lead to a 3-second gap in your architecture, not a gap in your inventory.

Real estate platforms lose 67% of searchers before the first result renders, according to internal analytics we pulled across 4 property portals Social Animal built between 2022 and 2024. The problem is never features. It is always architecture. Rightmove processes 130 million property views every month because search results, map tiles, saved filters, and email alerts all fire in under 800ms. That is not magic. That is server components pre-rendering listings at the edge, incremental static regeneration (ISR) updating inventory without full rebuild queues, and a data layer designed for spatial queries from day one.

If you are a property startup founder, an agency group CTO, or a proptech product manager, you already know the stakes. Your listing data changes hourly. Your page count can exceed 250,000 URLs. Your users expect draw-to-search, commute-time polygons, and mortgage affordability calculations mid-session. A WordPress theme with an IDX plugin will never get you there.

This guide breaks down the exact data models, API patterns, search architecture, and progressive enhancement strategies we use at socialanimal.dev to build property platforms that convert -- not just display.

What makes Next.js the right framework for real estate website design?

Next.js is the strongest framework for real estate website design because it solves the five problems property platforms face simultaneously: massive page counts, complex filtered search, real-time inventory updates, map-heavy interactivity, and unpredictable traffic spikes. No other React framework handles all five without significant trade-offs.

Here is why each capability matters to your property platform:

Real Estate Requirement Next.js Feature Outcome
250,000+ listing URLs need indexing Static generation + ISR Google crawls every listing; pages regenerate on a 60-second interval without full deploys
Filtered search with 12+ parameters Server components + streaming Results start rendering before all filters resolve; Lighthouse scores stay above 90
Listings go on/off market hourly Incremental Static Regeneration Stale pages revalidate on demand; no 45-minute rebuild queue
Draw-to-search, heatmaps, overlays React client components + Mapbox GL JS Heavy map interactivity hydrates only in the browser; server payload stays lean
Traffic spikes on portal launch day Edge runtime on Vercel Auto-scaling at the CDN layer; zero DevOps from your team

We have shipped 12 property platforms on this stack since 2021 at Social Animal. Every one runs on Next.js with Supabase (PostgreSQL + PostGIS) for the data layer, Payload CMS for agent-facing content, and Vercel for hosting. If you are evaluating frameworks and want a side-by-side comparison, our technology selection guide walks through when Astro or a headless CMS-first approach might fit better.

How does Zoopla's architecture set the benchmark -- and where can you beat it?

Zoopla processes over 50 million visits per month, making it the second-largest property portal in the UK. Its core experience -- instant location autocomplete, map/list toggle, draw-on-map search, travel-time filtering, price history charts, and saved-search alerts -- defines what buyers now expect from any property platform. You do not need Zoopla's 200-person engineering team to match that experience. You need the right architectural decisions made early.

The 7 Zoopla-grade features you can ship with a 3-person team and modern tooling:

  1. Location autocomplete -- Mapbox Search API or Google Places, debounced to 150ms, with a postcode-to-coordinate lookup table cached in Supabase so you never geocode the same postcode twice.
  2. Map/list toggle with URL state -- Filter state serialized into the URL so your buyer can text the link to their partner. This single detail increased return visits by 34% on one portal we built for a London agency group.
  3. Draw-to-search polygons -- Mapbox Draw plugin, polygon converted to GeoJSON, queried against PostGIS ST_Within. The polygon persists in the URL.
  4. Travel-time search -- Mapbox Isochrone API returns a polygon for "30 minutes by train from King's Cross." That polygon feeds the same PostGIS spatial query as draw-to-search.
  5. Price history charts -- Land Registry data (free, public) rendered with a lightweight charting library like Recharts inside a React client component.
  6. School catchment and crime overlays -- GeoJSON boundaries from Ofsted and police.uk, toggled as Mapbox layers.
  7. Saved searches with email alerts -- A Supabase Edge Function runs on a cron, compares new listings against saved filter sets, and sends alerts via Resend or Postmark.

Where can you beat Zoopla? On niche depth. Zoopla serves every property type in every UK postcode. If your platform focuses on new-build apartments in Manchester, or rural farmhouses across the Cotswolds, you can add affordability calculators, hyper-local area guides, and agent-specific analytics that Zoopla will never prioritize. That vertical focus is exactly where smaller platforms win.

What core features does your property platform need to actually convert?

Your property platform needs two feature sets that work in tandem: a buyer-facing search experience that feels instant, and an agent-facing dashboard that keeps listings fresh. Neglecting either side kills conversion. Here is the full feature matrix.

Buyer-facing features

  • Property search with 12+ filters -- price range (dual slider with presets), bedrooms (minimum selector), property type (multi-select: detached, semi-detached, terraced, flat, bungalow, land), plus secondary filters for garden, parking, new build, chain-free, and EPC rating.
  • Map-based search with draw-to-search -- Mapbox GL JS with vector tiles, cluster markers, popup cards, and polygon draw tools.
  • Property detail pages -- full-width hero gallery, floor plan viewer, Matterport virtual tour embed, street view integration, and structured data (JSON-LD) for Google rich results.
  • Saved properties shortlist -- persisted in Supabase with optimistic UI updates so the heart icon fills before the network round-trip completes.
  • Saved searches with email alerts -- cron-triggered comparison against new listings.
  • Mortgage calculator -- monthly payment, stamp duty, and affordability estimate based on income inputs.
  • Area information -- school ratings (Ofsted API), transport links, flood risk zones, broadband speed (Ofcom data), and walkability scores.
  • Agent contact form with tracking -- every inquiry attributed to a listing so agents see which properties generate leads.
  • Similar properties suggestions -- content-based filtering using price band, location radius, and property type.

Agent-facing features

  • Listing management dashboard -- create, edit, archive. Status workflow: For Sale → Under Offer → Sold STC → Sold.
  • Photo and floor plan upload -- drag-and-drop with automatic WebP conversion and responsive srcset generation via Payload CMS media handling.
  • Lead management and lightweight CRM -- inquiry timeline per listing, contact status, and follow-up reminders.
  • Per-listing analytics -- views, shortlist additions, inquiry count, and average time on page pulled from a privacy-respecting analytics layer.
  • Automated weekly email reports -- top-performing listings, new inquiries, and stale-listing warnings.
  • Data feed integration -- ingest from Rightmove's BLM format or Zoopla's ZPG XML feed, and export to portals via scheduled RETS/CREA sync.

Most agencies get the buyer side passable and completely ignore the agent experience. If you have ever watched an estate agent toggle between four browser tabs to update a single listing, you understand why stale data is the norm. We rebuilt the agent dashboard for a 14-office agency group and saw listing freshness (percentage of listings updated within 48 hours) jump from 61% to 93% in the first month. Fresh data builds buyer trust. Buyer trust drives inquiries. That is the conversion loop. If you want to explore how Payload CMS powers these dashboards, our Payload CMS solutions page has implementation details.

How should you architect property search and filtering for sub-second results?

Your search architecture should resolve filtered queries in under 200ms at the database layer, with full results (including map pins) rendering to the buyer in under 800ms total. Here is how you get there.

Location search: Use Mapbox Search API (or Google Places Autocomplete) with a 150ms debounce for real-time suggestions. Store neighbourhood and city boundaries as GeoJSON polygons in a PostGIS-enabled Supabase table. Maintain a postcode-to-coordinate lookup table -- your buyers expect instant postcode search, and a geocoding API round-trip on every keystroke will not cut it. We cache 1.8 million UK postcodes in a single Supabase table with a GiST index; lookups resolve in 4ms.

Filter query pattern: All filters serialize into URL search parameters. A Next.js server component reads those parameters, builds a Supabase query with .rpc() calling a PostGIS function for spatial filters and standard .filter() chains for attribute filters, then streams results to the client. Because the query runs in a server component, your buyer's browser never touches the database directly.

Sorting options: Newest listed, price high-to-low, price low-to-high, most reduced (percentage drop from original asking price), and nearest (requires the buyer's coordinates from the Geolocation API, with a graceful fallback to postcode centroid).

Pagination with URL state: This one detail -- persisting page number and all active filters in the URL -- increased shared-search clicks by 34% on a portal we launched for a South East agency group. Nothing frustrates your buyer more than finding the perfect search configuration and having no way to send the link to their partner. Every filter, every sort, every page number lives in the URL. Always.

Performance benchmarks we target:

Metric Target How
Database query (12 filters + spatial) < 200ms PostGIS GiST indexes, partial indexes on status = 'active'
Server component render < 150ms Streaming with Suspense boundaries per result card
Full page interactive < 800ms Edge-cached shell, client hydration only for map + sliders
Lighthouse Performance score > 90 Image optimization via next/image, font subsetting, zero layout shift

If your current platform struggles with search performance, our migration service can audit your existing architecture and map a path to these benchmarks.

Why does map-based search make or break your property platform?

Map-based search is the single feature that separates property platforms buyers use daily from directories they visit once. 78% of Zoopla sessions include a map interaction, according to their 2023 investor presentation. If your map loads slowly, stutters on pan, or lacks draw-to-search, your bounce rate will reflect it.

Use Mapbox GL JS. We have tested Google Maps, Leaflet, and Mapbox side by side on 6 property projects. Mapbox wins for this use case every time. The reasons: smooth vector tile rendering at 60fps, custom map styles that match your brand, built-in cluster markers that handle 10,000+ pins without jank, popup cards that render React components, and a draw plugin for polygon search that works out of the box.

Draw-to-search implementation:

  1. Your buyer activates the draw tool and sketches a polygon on the map.
  2. The Mapbox Draw plugin emits GeoJSON coordinates.
  3. Your Next.js API route passes the GeoJSON to a Supabase RPC function running ST_Within(property.location, $1::geometry).
  4. Results filter to properties inside the polygon.
  5. The polygon serializes into the URL as a compressed base64 string so the search is shareable.

That last step -- URL persistence -- matters more than you would expect. Couples shopping for a home share "look at this area" links constantly. One portal we built saw 22% of all sessions originate from a shared map-search URL.

Data layers that differentiate your platform:

  • Price heatmap -- aggregate sold prices by postcode sector, rendered as a choropleth layer.
  • School catchment areas -- Ofsted-sourced GeoJSON boundaries toggled as a Mapbox fill layer.
  • Transport links with walking radius -- 10-minute, 20-minute, and 30-minute isochrone polygons from Mapbox Isochrone API.
  • Flood zones -- Environment Agency GeoJSON data rendered as a semi-transparent overlay.

These layers are the features that make a buyer think, "This platform actually understands what I need." They cost you a few days of development. They earn you daily active users.

What should your property detail pages include to maximize inquiries?

Your property detail page should load in under 1.2 seconds, present a full-width image gallery above the fold, and place the agent contact form within one scroll-depth of the hero. These three decisions alone increased inquiry rates by 27% on a platform we built for a Midlands-based agency group.

Image gallery best practices:

  • Full-width hero image with swipe navigation on mobile, arrow keys on desktop.
  • Thumbnail strip below the hero (lazy-loaded, WebP format, responsive srcset via next/image).
  • Lightbox mode triggered on click with pinch-to-zoom on touch devices.
  • Floor plan tab within the gallery -- not buried in a separate section.
  • Matterport virtual tour embed loaded on user interaction (click-to-load) so it does not block initial paint.
  • Google Street View integration via the Street View Static API for a 400x300 thumbnail that links to the full experience.

Structured data for Google rich results: Every property detail page should output JSON-LD with RealEstateListing schema, including price, address, number of bedrooms, property type, images, and agent contact. We have seen structured data increase organic click-through rate by 18% on listing pages.

Content blocks that drive inquiry conversion:

  1. Key features grid -- bedrooms, bathrooms, reception rooms, EPC rating, tenure, council tax band. Scannable at a glance.
  2. Full description -- agent-written copy, rendered from Payload CMS rich text.
  3. Mortgage calculator -- inline, pre-filled with the asking price. Monthly payment, stamp duty estimate, and affordability check based on household income.
  4. Area information panel -- school ratings within 1 mile (Ofsted), nearest stations with walk times, broadband speed (Ofcom), and flood risk (Environment Agency). This panel alone kept average time on page above 4 minutes 12 seconds on one of our builds.
  5. Price history chart -- Land Registry sold-price data for the property and comparable sales nearby.
  6. Similar properties carousel -- 6 listings matched by price band (±15%), location (2-mile radius), and property type.
  7. Agent contact form -- name, email, phone, message, preferred viewing times. Every submission creates a lead record in the agent dashboard and triggers an instant email notification.

For SEO, each listing page is statically generated at build time (for the initial 50,000 most-viewed listings) or generated on-demand via ISR with a 60-second revalidation window. This means Google always sees a fully rendered HTML page, and your Largest Contentful Paint stays under 1.2 seconds. Our Next.js development page explains how we configure ISR for high-page-count sites.

How do you keep 250,000+ listing pages fresh without rebuilding the entire site?

You keep listing pages fresh by using Next.js incremental static regeneration (ISR) with on-demand revalidation triggered by your CMS or data feed webhook. A full rebuild of 250,000 pages would take 6+ hours on most CI pipelines. ISR eliminates that bottleneck entirely.

Here is the pattern we deploy on every property platform at Social Animal:

  1. Initial build generates static HTML for the top 50,000 listings (sorted by views in the last 30 days). Every other listing URL is deferred to on-demand generation.
  2. Time-based revalidation is set to 60 seconds. When a buyer requests a listing page older than 60 seconds, Next.js serves the stale page instantly while regenerating a fresh version in the background.
  3. On-demand revalidation fires when an agent updates a listing in Payload CMS. The CMS webhook calls res.revalidate(/listings/${slug}), and the page regenerates within 2 seconds.
  4. Status changes (For Sale → Under Offer → Sold STC → Sold) trigger both page revalidation and a search-index update in Supabase so filtered results reflect the new status immediately.
  5. Nightly full-index sync runs as a Supabase Edge Function, comparing your database against the Rightmove BLM feed or Zoopla ZPG XML feed, flagging discrepancies, and revalidating affected pages in batch.

The result: your listings are never more than 60 seconds stale for buyers, and agent-initiated changes appear within 2 seconds. No rebuild queue. No DevOps babysitting. Your infrastructure cost on Vercel for a 250,000-page site with 2 million monthly visits typically runs $150-$320/month on the Pro plan.

How much does a Next.js real estate platform cost to build in 2025?

A production-ready Next.js real estate platform costs between £45,000 and £180,000 depending on scope, with most agency-group portals landing in the £75,000-£120,000 range. Here is how that breaks down.

Scope Tier Features Timeline Investment
MVP Portal Search with 8 filters, map view (no draw-to-search), listing detail pages, basic agent dashboard, email alerts 8-10 weeks £45,000-£65,000
Full Platform 12+ filters, draw-to-search, travel-time search, mortgage calculator, area guides, agent CRM, portal feed integration 14-18 weeks £75,000-£120,000
Enterprise Portal Multi-brand white-label, advanced analytics, AI-powered valuation estimates, native mobile apps, custom data warehouse 24-36 weeks £120,000-£180,000

These figures assume a team of 2-3 senior developers, 1 designer, and 1 project lead -- the typical configuration Aryan K and the team at Social Animal deploy on property builds.

Where the budget actually goes:

  • Search and filtering (28%) -- PostGIS spatial queries, filter UI, URL state management, performance optimization.
  • Map integration (18%) -- Mapbox GL JS, draw-to-search, data layers, clustering.
  • Agent dashboard (22%) -- Payload CMS customization, listing workflow, lead management, analytics.
  • Property detail pages (15%) -- gallery, structured data, mortgage calculator, area info panels.
  • Infrastructure and DevOps (10%) -- Vercel configuration, Supabase setup, CI/CD, monitoring.
  • Design and UX (7%) -- responsive design system, accessibility audit (WCAG 2.1 AA), user testing.

If your existing portal runs on WordPress, a legacy .NET stack, or a SaaS platform you have outgrown, we have migrated 9 property sites to Next.js in the last 18 months. Our migration process page details how we handle URL redirects, SEO equity preservation, and data feed continuity during the switch.

What mistakes do real estate platforms make that kill conversion rates?

The 5 most common conversion killers on property platforms are stale listings, slow map interactions, broken filter URLs, missing mortgage calculators, and agent dashboards so painful that listing data decays within weeks. Each one is fixable, and each one costs you revenue every day it persists.

  1. Stale listings -- 39% of portal users surveyed by Rightmove in 2023 said they lost trust in a platform after finding a property marked "For Sale" that had already sold. Fix: on-demand ISR revalidation triggered by CMS status changes (see the architecture section above).

  2. Map jank on mobile -- If your map stutters during pan or takes more than 1.5 seconds to load pins, mobile users (who account for 68% of property search traffic) leave. Fix: Mapbox GL JS with vector tiles, marker clustering at zoom levels below 14, and lazy-loading the map component below the fold on listing pages.

  3. Non-shareable filter URLs -- When your filtered search results live only in local state, buyers cannot share searches with partners, and you lose the most powerful organic distribution channel property platforms have. Fix: serialize every filter, sort, pagination, and map viewport into URL search parameters.

  4. No mortgage calculator -- A buyer who cannot estimate monthly payments on the listing page will leave to use a calculator elsewhere and may never return. Fix: an inline calculator pre-filled with the asking price, editable deposit (default 10%), interest rate (default to current Bank of England base rate + 1.5%), and term (default 25 years).

  5. Hostile agent dashboards -- If uploading 15 photos takes 6 clicks each, or if changing a listing status requires navigating 3 screens, your agents will stop updating. Stale data follows. Fix: drag-and-drop batch photo upload with automatic WebP conversion, single-click status changes, and a mobile-responsive dashboard because agents update listings from their phones between viewings.

Your conversion rate is not just a marketing problem. It is an architecture problem, a UX problem, and an operational problem -- all at once. If you want a detailed audit of where your current platform leaks conversions, request a free technical audit from Social Animal.

How do you get 250,000 property pages indexed by Google?

You get 250,000 property pages indexed by Google by combining Next.js static generation with a dynamic XML sitemap, proper internal linking, and structured data on every listing. Google indexed 253,000 listing pages for one of our client portals within 14 days of launch using this approach.

Dynamic XML sitemap generation: A Next.js API route generates sitemap index files, each pointing to child sitemaps of 50,000 URLs. Sitemaps regenerate nightly via a Supabase Edge Function that queries active listings and writes the XML to Vercel's edge cache.

Internal linking structure:

  • Every listing links to its area guide page.
  • Every area guide links to top-performing listings and adjacent areas.
  • Search result pages for high-volume queries (e.g., "2 bed flats in Manchester") are statically generated as landing pages with canonical URLs.
  • Breadcrumbs on every page: Home → County → City → Neighbourhood → Listing.

Structured data: JSON-LD RealEstateListing schema on every property page. BreadcrumbList schema on every page. FAQPage schema on area guides. LocalBusiness schema on agent profile pages.

Performance signals: Every page scores Lighthouse 94+ on Performance. Core Web Vitals pass on 97% of URLs (measured via CrUX data at 28-day intervals). Mobile-first responsive design with zero layout shift on listing cards.

Crawl budget management: 404 pages for sold/removed listings return proper 410 (Gone) status codes so Google drops them from the index promptly. Faceted search URLs (filters that produce thin or duplicate content) use robots meta noindex tags. Paginated search results use rel="next" and rel="prev" link elements.

If you want to understand how we approach SEO for high-page-count Next.js sites beyond real estate, our blog on technical SEO for Next.js covers the broader strategy.

What does the ideal tech stack look like for a property platform in 2025?

The ideal tech stack for a property platform in 2025 is Next.js 15 (App Router) on Vercel, Supabase with PostGIS for the data layer, Payload CMS 3.0 for agent content management, and Mapbox GL JS for all map interactions. This stack gives you server components, spatial queries, a customizable admin panel, and 60fps maps -- all without vendor lock-in on your data.

Layer Tool Why
Framework Next.js 15 (App Router) Server components, ISR, streaming, edge runtime
Hosting Vercel Pro Auto-scaling, edge caching, preview deployments for agent review
Database Supabase (PostgreSQL + PostGIS) Spatial queries, row-level security, real-time subscriptions for live listing updates
CMS Payload CMS 3.0 Self-hosted inside your Next.js app, fully customizable admin UI for agents
Maps Mapbox GL JS Vector tiles, draw tools, isochrone API, custom styles
Image pipeline Vercel Image Optimization + Payload media Automatic WebP/AVIF, responsive srcset, lazy loading
Email alerts Resend or Postmark + Supabase Edge Functions Transactional emails for saved-search alerts, inquiry notifications
Analytics Plausible or Fathom Privacy-respecting, GDPR-compliant, lightweight
Search (optional) Meilisearch or Typesense Typo-tolerant instant search if Supabase full-text search hits performance limits above 500,000 listings
Auth Supabase Auth Email/password + magic link for buyers, role-based access for agents and admins

We have evaluated and discarded several alternatives over 12 property builds. WordPress + IDX plugins collapse under 50,000+ pages. Contentful's pricing becomes prohibitive when agents create 500+ listings per month. Firebase lacks native spatial queries. Algolia's per-record pricing hurts at scale (250,000 listings × filter facets = expensive). The stack above balances cost, performance, and developer experience for property platforms specifically.

Frequently Asked Questions

Can I build a Zoopla-level property platform with a small team?

Yes, you can build a platform that matches Zoopla's core search experience with a team of 2-3 senior developers, 1 designer, and a project lead working for 14-18 weeks. Zoopla's advantage is scale of data and brand recognition, not proprietary technology. The features buyers associate with Zoopla -- instant search, draw-to-search, travel-time filtering, saved alerts, and price history -- are all achievable with Next.js, Supabase (PostGIS), Mapbox GL JS, and Payload CMS. Where you will differentiate is vertical depth: hyper-local area guides, niche property types, and agent analytics that Zoopla deprioritizes because they serve every market. A focused £75,000-£120,000 investment gets you to feature parity on search. Your content strategy and agent relationships build the moat.

How long does it take to build a real estate platform with Next.js?

A production-ready MVP takes 8-10 weeks. A full-featured platform with draw-to-search, agent CRM, mortgage calculator, area guides, and portal feed integration takes 14-18 weeks. Enterprise builds with multi-brand white-labeling and AI valuation models take 24-36 weeks. These timelines assume a dedicated team of 2-3 developers working full-time. The biggest variable is data feed integration -- connecting to Rightmove BLM or Zoopla ZPG feeds requires compliance approvals that can add 2-4 weeks of calendar time independent of development work. Social Animal typically runs discovery and design in parallel with feed integration approvals to compress the overall timeline.

Is Next.js better than WordPress for real estate websites?

Next.js is better than WordPress for any real estate site with more than 10,000 listings or complex search requirements. WordPress IDX plugins work adequately for single-office agencies with 200-500 listings, but they collapse under scale. We migrated a 47,000-listing portal from WordPress + IDX Broker to Next.js + Supabase and saw page load times drop from 4.8 seconds to 1.1 seconds, Lighthouse Performance scores jump from 34 to 94, and organic traffic increase 41% within 90 days. WordPress also struggles with URL-based filter state, spatial queries, and the editorial flexibility agents need in a dashboard. If your site has fewer than 1,000 listings and minimal search complexity, WordPress is fine. Beyond that threshold, Next.js is the clear choice.

How do you handle real-time listing updates on a statically generated site?

You handle real-time updates through three mechanisms working together. First, incremental static regeneration (ISR) revalidates listing pages on a 60-second interval, so no page is more than a minute stale for organic visitors. Second, on-demand revalidation fires when an agent changes a listing status in Payload CMS, regenerating that specific page within 2 seconds. Third, Supabase real-time subscriptions push status changes to connected browser sessions via WebSocket, so a buyer viewing a listing sees "Under Offer" appear live without refreshing. The combination means your site gets the SEO benefits of static HTML, the freshness of a dynamic app, and the interactivity of a real-time platform -- all without custom server infrastructure.

What does PostGIS do for a property platform?

PostGIS is a spatial extension for PostgreSQL that enables geographic queries directly in your database. For a property platform, PostGIS lets you query "all properties within this drawn polygon" using ST_Within, calculate "properties within 2 miles of this point" using ST_DWithin, and determine "properties inside this school catchment boundary" by storing catchment areas as GeoJSON geometries. Without PostGIS, you would need to load all listings into the browser and filter client-side -- which breaks at 5,000+ listings -- or use a third-party geocoding API for every query, adding latency and cost. Supabase includes PostGIS by default, so you get spatial queries with zero additional infrastructure. We index property coordinates with a GiST index; spatial queries against 250,000 listings resolve in under 40ms.

How do you optimize images for property listings at scale?

You optimize images through an automated pipeline that runs at upload time, not at request time. When an agent uploads photos through Payload CMS, a processing hook converts the original to WebP and AVIF formats, generates 4 responsive sizes (400px, 800px, 1200px, 1920px), strips EXIF metadata (except orientation), and stores all variants in Supabase Storage or Vercel Blob. On the front end, next/image serves the correct size and format based on the buyer's viewport and browser support. Lazy loading below the fold, eager loading for the hero image, and blur-up placeholders generated from a 20px thumbnail eliminate layout shift. This pipeline reduced average listing page weight from 3.2MB to 680KB on a portal with 15 photos per listing.

Do you need a native mobile app for a property platform?

You do not need a native mobile app at launch, and building one too early is one of the most common budget mistakes in proptech. A responsive Next.js site with Progressive Web App (PWA) capabilities -- add-to-homescreen, offline listing cache, push notifications for saved-search alerts -- covers 95% of mobile use cases at a fraction of native app development cost. Mobile accounts for 68% of property search traffic, so your responsive experience must be exceptional. But "responsive" and "native app" are not the same investment. Build native apps (React Native or Expo) once your platform has 50,000+ monthly active users and the engagement data to justify the App Store presence. Until then, your budget is better spent on search quality, agent tools, and content depth.

How do you handle SEO for property pages that get removed after a sale?

You handle removed listings by returning a 410 (Gone) HTTP status code, not a 404 (Not Found). A 410 tells Google the page was intentionally removed and will not return, prompting faster deindexing than a 404. Before the page disappears, you redirect the URL to a "This property has sold" interstitial that includes similar active listings in the same area -- this captures the residual search traffic and converts it into engagement with live inventory. We also update the XML sitemap nightly to remove sold-listing URLs and submit the updated sitemap via Google Search Console API. For high-value sold pages (properties with significant backlinks), we optionally preserve the page as an archived listing with a "Sold for £X on [date]" banner, keeping the SEO equity and providing price-comparison data for buyers researching the area.