Web platforms for real estate businesses

Most real estate web projects do not fail because the code is hard. They fail because nobody agreed on what "search" means, where the listings come from, and who keeps the photos up to date. If you are a founder or product owner about to hire an agency, the most useful thing you can do is understand the moving parts before you sign anything.

This is a plain look at what goes into a real estate web platform, what it tends to cost, how long it really takes, and the things that bite people six months in.

What "a real estate platform" actually means

That phrase covers at least four very different products, and they cost very different amounts.

• A brochure site for an agency. Listings, agent profiles, a contact form. Mostly marketing.
• A listings portal. Search, filters, map, saved searches, lead capture. Think a regional version of a big property site.
• A transaction or management platform. Tenant portals, rent payments, document signing, maintenance requests, owner dashboards.
• An internal tool with a public face. A CRM for agents that also publishes listings to the web.

When an agency quotes you wildly different numbers, this is usually why. Pin down which one you are buying first. A lot of pain comes from a client who asked for a brochure site but described a portal in the kickoff meeting.

Where the data comes from (this is the whole ballgame)

The hardest part of a real estate platform is almost never the front end. It is the listing data: where it lives, how fresh it is, and who owns the truth.

A few common scenarios:

• You enter listings by hand. Fine for a small agency. You need a clean admin area and good image handling, nothing exotic.
• You sync from an MLS or a national feed (RESO, RETS, IDX in the US, or a local equivalent). This is where timelines balloon. Feeds are inconsistent, fields are named differently across providers, photos arrive late or broken, and access often requires paperwork and approval that takes weeks before a line of code runs.
• You aggregate from multiple sources. Now you have deduplication, conflicting prices, and stale listings to reconcile. This is a real engineering problem, not a weekend job.

If your platform depends on an external feed, ask the agency directly: have they integrated this specific provider before, and what is the approval timeline on the data side. The answer changes your launch date more than any design decision.

The features that look small but are not

A few things consistently get underestimated:

Search and filters. "Show me 3-bed houses under 400k within 5km of this point, sorted by newest" is a genuine search problem. Naive database queries get slow fast once you add map bounds and free-text. You usually want a dedicated search index (Postgres full-text and PostGIS can carry you a long way, or something like Typesense or Elastic when you outgrow it). Plan for this early.

Maps. Maps are easy to add and expensive to scale. Google Maps and Mapbox both bill per load, and a busy listings page reloads the map constantly. Clustering hundreds of pins without jank takes real work. Budget for the API bill, not just the build.

Images. Real estate is a photo business. Agents upload 40 huge images per listing, shot on a phone, in the wrong orientation. You need automatic resizing, a CDN, lazy loading, and sensible fallbacks. Skip this and your "fast" site crawls on the exact pages that sell.

Lead routing. A contact form is trivial. Making sure the right agent gets the lead within seconds, with no duplicates, and that it lands in their CRM, is the part that actually makes money. Treat it as a core feature.

A sensible stack (and why)

We build these on Next.js with a Postgres database, and that combination handles the large majority of real estate platforms comfortably. Postgres gives you full-text search and PostGIS for the geospatial queries in one place, which keeps the early architecture simple. Next.js renders listing pages on the server so they load fast and rank well in search, which matters a lot when buyers find you through Google.

You do not need microservices, a separate search cluster, or a Kubernetes setup on day one. Those are answers to scale problems you may never have. Starting simple and adding pieces when the traffic justifies them is the good kind of lazy: less to build, less to break, less to pay for.

-- The kind of query a listings portal lives on:
-- 3-bed homes under 400k within 5km of a point, newest first.
SELECT id, title, price
FROM listings
WHERE bedrooms >= 3
  AND price <= 400000
  AND status = 'active'
  AND ST_DWithin(location, ST_MakePoint(:lng, :lat)::geography, 5000)
ORDER BY published_at DESC
LIMIT 24;

If a query like that is fast and correct, you have the hard half of the platform working.

Rough costs and timelines

These are ranges, not quotes. Real numbers depend on data sources, design ambition, and how many edge cases you insist on at launch. Treat them as planning anchors.

• Brochure site for an agency: roughly 3 to 6 weeks, low five figures. The risk here is scope creep into portal territory.
• Listings portal with search, maps, and manual data entry: roughly 2 to 4 months, mid five figures and up. Most of the cost is search, maps, and image handling done properly.
• Portal with an external MLS or feed integration: add 4 to 8 weeks and meaningful budget, mostly because of the data wrangling and approval delays described above.
• Transaction or management platform with payments and documents: several months and into six figures, because payments, e-signatures, and compliance each carry their own weight.

The expensive part is rarely the visible part. A polished homepage is cheap. Correct, fast, always-fresh data is where the money goes.

What to watch out for

A short checklist before you commit:

• Ask who owns the data integration risk. If the feed is late or broken, is that the agency's problem or yours.
• Insist on a real staging environment with real-looking listing volumes. Everything is fast with 12 listings. Ask to see it with 10,000.
• Get the admin experience demoed, not just the public site. The people entering listings will use the back office every day. If it is clumsy, your data quality dies and the whole platform with it.
• Clarify ongoing costs up front. Maps, image CDN, hosting, and search all bill monthly. A cheap build with a surprising running cost is not a bargain.
• Avoid a rebuild-from-scratch quote if a phased launch would prove the idea faster. You can launch with manual data entry and add the feed later.

Takeaway

Buy the platform you actually need, not the one that sounds impressive. Decide which of the four product types you are building, nail down where the listing data comes from and who owns the risk of it breaking, and assume search, maps, and images will cost more than the pretty homepage. Get those right and the rest is ordinary web work.

If you want a second opinion on a quote or a scope before you sign, we are happy to look.