How to Make an App Like 99acres

Building a real estate portal at the scale of 99acres means handling millions of property listings, high-intent search queries, complex geo-filtering, and a two-sided marketplace where both buyers and agents need to find value quickly. This post walks through the architecture, feature set, and engineering decisions involved in building something comparable.

What Does a Platform Like 99acres Actually Do?

99acres is a property listing marketplace. At its core, it connects buyers, sellers, and rental seekers with real estate agents and property owners. But the product complexity runs deeper than a listings board.

The platform needs to support:

• Structured listing creation with property type, BHK configuration, floor number, furnishing status, and locality tagging
• Geo-based search with polygon and radius support
• Lead generation and routing to agents
• Subscription and pay-per-lead monetisation for agents
• Verified listings vs unverified, with fraud detection
• Saved searches and price drop alerts
• Property valuation estimates (often powered by a regression model on historical transaction data)

These are the functional requirements. The architectural decisions flow from them.

Core Architecture: How Should You Structure the Backend?

A monolith works fine at MVP stage. Once you have 50,000+ daily active users and agents running automated listing tools, you will want service boundaries. The split that makes sense for a real estate portal looks like this:

Listing Service

This owns the property data model. A listing is not a simple record. It carries structured attributes (bedrooms, bathrooms, area in sq ft, facing direction), semi-structured data (description text, amenities as tags), media (images, virtual tour links), and geo-coordinates.

Store structured attributes in PostgreSQL. Use PostGIS for all spatial queries — it handles radius search, polygon intersection, and bounding box queries natively. Do not try to replicate this in Elasticsearch; use ES for full-text search and faceted filtering, and PostGIS for spatial precision.

Index your listings in Elasticsearch 8.x with a mapping that separates keyword fields (locality slug, property type, status) from text fields (description). Use nested objects for amenities so you can filter on them without field explosion.

Search Service

Search on a platform like this is not a simple SQL WHERE clause. Buyers combine locality, budget, BHK, and property type in unpredictable combinations. They also type free-form queries like "2 BHK near Koramangala metro under 60 lakhs."

Natural language queries need an NLP pre-processing step. A fine-tuned BERT model (or a smaller distilBERT for latency reasons) can extract intent and slot-fill the structured filter fields from a free-form query. The extracted filters then go to Elasticsearch.

Ranking matters. A listing from 2021 with no contact in six months should rank below a freshly verified one. Build a scoring function that weights recency, agent responsiveness, photo count, and description completeness. You can start with a hand-tuned BM25 + field boost and graduate to a learning-to-rank model once you have enough click and contact data.

Lead and Agent Service

This is where the monetisation lives. Leads generated by buyer enquiries route to agents based on subscription tier, geography, and property type. Build this as a separate service with its own database. Leads are time-sensitive; a lead not responded to within 15 minutes has significantly lower conversion.

Use a message queue (Kafka or RabbitMQ) between the listing service and the lead service. When a buyer submits an enquiry, the event hits the queue and the lead service picks it up, scores it, and routes it. This keeps the listing service from being blocked on lead routing logic.

Media Service

Property photos are the highest-traffic asset. A listing with 10 photos will have each photo requested dozens of times per session view. Use a CDN (CloudFront or Cloudflare) in front of object storage (S3 or GCS). On upload, run an async pipeline that:

1. Validates image quality (blur detection, resolution check)
2. Strips EXIF metadata (privacy)
3. Generates responsive variants (480px, 960px, 1920px WebP)
4. Optionally runs an AI model for room type classification and auto-tagging

Room type classification is a nice-to-have but it improves search relevance when buyers filter by "listings with kitchen photos."

What Does the Mobile App Need That the Web App Doesn't?

The majority of Indian real estate traffic is mobile. Design the app experience for low-bandwidth conditions and intermittent connectivity.

A few things matter more on mobile:

Offline map caching. Buyers often browse listings while physically visiting a locality. Cache the last map tile set locally using Mapbox's offline packs or a similar mechanism. This lets the map render even when data drops out.

Push notifications for saved searches. When a new listing matches a buyer's saved filters, send a push within minutes. Use Firebase Cloud Messaging. Batch notifications for price drops to avoid notification fatigue; run a cron every 4 hours rather than triggering on every price change.

Camera-first listing creation for agents. Agents creating listings on mobile need a fast photo upload flow. Upload photos in the background as they are selected, before the agent submits the form. This eliminates the wait at submission.

On the tech stack, Flutter gives you a single codebase for Android and iOS with near-native performance for this kind of data-heavy app. React Native is a reasonable alternative if your team is JS-heavy, but Flutter's rendering engine handles map-heavy views and image-heavy lists more smoothly.

How Do You Handle Fraud and Fake Listings?

Fake listings are the biggest trust problem in Indian real estate portals. There are a few common fraud patterns: duplicate listings across agents, listings for properties that are not actually available, and contact detail spoofing.

Deduplication runs at ingest time. Compute a locality + BHK + area + approximate price hash and flag listings that fall within a configurable similarity threshold. Use image perceptual hashing (pHash) to catch cases where the same photos are reused across different fake listings.

Phone number verification via OTP is table stakes. Beyond that, implement a trust score for agents based on listing accuracy, response rate, and reported disputes. Agents with low trust scores get their listings ranked lower and their new submissions held for manual review.

Property title verification is harder. Some portals integrate with government property databases where APIs exist. This is worth building if you are targeting Tier 1 cities where such data is available, but do not block listing creation on it or you will kill supply.

Monetisation and Subscription Tiers

99acres makes money through agent subscriptions, featured listing upgrades, and developer project pages. Build the subscription logic as a separate billing service.

Agent subscriptions typically gate:

• Number of active listings
• Lead credits per month
• Listing visibility (standard vs featured vs premium placement)
• Response analytics

Use Stripe or Razorpay for payment processing. Razorpay is the better default for India given UPI, netbanking, and EMI support. Model the subscription in your database as a plan with feature flags rather than hard-coding tier logic in the listing service. This lets you change plan features without a deployment.

Pay-per-lead is an alternative monetisation model. Some platforms combine both. If you go per-lead, you need strict lead quality controls or agents will churn fast when they receive junk enquiries.

Conclusion

Building a 99acres-scale real estate portal is a systems problem as much as a product problem. The core decisions that matter most are: PostGIS for spatial queries rather than trying to bolt geo onto a general-purpose database, Elasticsearch for search with a proper ranking function, Kafka for lead routing decoupled from the listing service, and a CDN-first media pipeline. Fraud detection needs to be designed in from day one, not added later.

If you are scoping this project, start with the search and listing services. Everything else can be added incrementally. The search experience determines whether buyers come back; everything else determines whether you can monetise them.

Reach out to the team at Sodio if you want to walk through the architecture in more detail or get an estimate on a specific component.

FAQ

How long does it take to build a real estate portal like 99acres? An MVP with listing creation, search, and basic lead routing takes 4 to 6 months with a team of 6 to 8 engineers. A production-grade platform with fraud detection, subscriptions, mobile apps, and a recommendation engine is closer to 12 to 18 months of iterative development.

What is the estimated cost to build a real estate app like 99acres? A functional MVP built by an experienced team in India costs roughly ₹40 to ₹80 lakhs depending on scope. A full-featured platform with native mobile apps, ML-based search ranking, and agent dashboards can run ₹1.5 to ₹3 crore over 18 months. These numbers shift significantly based on team location and whether you are building in-house or outsourcing.

Which database is best for property listing platforms? PostgreSQL with the PostGIS extension handles spatial queries better than most alternatives for property search. Pair it with Elasticsearch for full-text and faceted search. Do not try to run geo queries through Elasticsearch alone — PostGIS is more accurate and performant for polygon and radius search at scale.

Do you need a separate mobile app or is a PWA sufficient? For an Indian real estate audience, a native or near-native mobile app converts significantly better than a PWA. Map interactions, image loading, and push notification reliability are all noticeably better in a Flutter or React Native app. Build a PWA first only if budget is a hard constraint at MVP stage.

How do you prevent fake listings on a real estate platform? Combine OTP-verified phone numbers, perceptual image hashing to detect reused photos, locality-level listing deduplication, and an agent trust score that affects listing visibility. Manual review queues for new agents and flagged listings add a human check without slowing down the majority of legitimate listings.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.