How We Scaled an Estate Agency Lead Platform to 10,000+ Leads a Month on Django

In 2014 we started a 6-month MVP for a UK startup that wanted its own lead-generation platform instead of renting someone else’s. Eleven years later, that platform routes 10,000+ leads a month across 1,000+ estate agencies and 600+ agents, at 99% uptime — and we still run it.

This post is the engineering story: the three or four decisions that let a Django monolith built by one developer scale to the UK’s leading estate-agency live-chat operation, and the ones we’d make again on any lead platform.

The problem: leads die in seconds

Yomdel provides managed live chat for estate agencies. A property seeker lands on an agency’s site at 9pm, opens a chat, and asks about a listing. That conversation is worth real money to the agency — but only if it reaches the right agent while the visitor is still typing.

That single fact shaped every technical requirement:

• Routing had to complete in under 3 seconds. Not page load — the full decision: which agency, which agent, is the agent available, what’s their territory and historical performance.
• One agency’s problem could never become 999 agencies’ problem. Multi-tenant with real data isolation, not a tenant_id column and good intentions.
• The platform could never go down for deploys. Chat is 24/7; “maintenance window” isn’t a concept estate agents accept.
• GDPR from day one. Property enquiries are personal data spread across 1,000+ independent data controllers.

Yomdel had already tried local UK engineers. Developers left mid-project or dragged timelines. They needed proprietary IP built on a startup budget — which is how a Kharkiv Django team ended up powering UK estate-agency chat.

Decision 1: a boring, optimizable stack

The stack is deliberately unexciting: Django + Django REST Framework + Celery, PostgreSQL, React for the portals, AWS multi-region. No microservices, no exotic databases.

Our guiding principle for the whole build has been keep it simple. The exciting version of this platform — event-sourced, service-per-domain — would have been unbuildable by the actual team that built it: one Django developer for the 6-month MVP, four people at peak (2 backend, 1 frontend, 1 QA), one dedicated backend engineer today now that the platform has matured.

That last number is the part most architecture posts skip. A system’s real test is not whether it scales to the traffic — it’s whether it scales down to a maintenance team of one without decaying. Eleven years in, it has.

Decision 2: multi-tenancy with genuine isolation

Each estate agency operates as an isolated tenant. When one agency misconfigures something or gets a traffic spike, the other 999 keep processing leads. This is also what makes GDPR tractable: data separation is an architectural property, not a query-discipline promise.

The practical Django lessons from 1,000+ tenants:

• Isolation pays for itself in support load, not just safety. Investigating one agency’s issue never requires touching another’s data.
• Per-tenant configuration will grow forever. Agencies wanted different routing rules, branding, and billing models. Making tenant config first-class early prevented a decade of special-case code.
• The billing model lives on the same isolation. Yomdel charges per lead, so the platform meters delivered leads per agency — the tenant boundary and the revenue boundary are the same line.

Decision 3: the sub-3-second routing budget

The routing algorithm distributes each enquiry by agent availability, expertise, geographic territory, and historical performance. The full decision has to land in under 3 seconds, with 600+ concurrent agents online.

What that budget bought us, concretely:

• PostgreSQL query optimization and strategic indexing before any caching — most “we need Redis” moments were actually missing indexes.
• Celery for everything that isn’t the routing decision. Notifications, billing events, analytics, CRM sync — all queued. The synchronous path does one job.
• Caching only for genuinely hot, slow-changing data (agency config, agent rosters).
• WebSockets for agent notification, so a routed lead appears on the right agent’s screen instantly instead of on next poll.
• AWS multi-region for UK-wide latency, which matters more than raw compute once queries are fast.

None of these is novel. The discipline was refusing to add any layer until the measurement said the budget was at risk.

Decision 4: an abstraction layer over chat vendors

The first chat integration (LiveChat Inc) was painful enough that we built a vendor abstraction layer: the core platform speaks one internal chat interface, and adapters translate per vendor.

That layer turned out to be one of the most valuable pieces of the platform. It let Yomdel add new chat platforms as the market shifted, and — years later — migrate away from a problematic vendor without touching the core. If your product depends on a third-party API, the abstraction layer isn’t over-engineering; it’s the only leverage you have in that relationship.

Zero-downtime deploys, because chat never sleeps

Estate agencies depend on the platform around the clock, so we ship with blue-green deployments, rolling updates, and carefully staged database migrations. New features deploy without interrupting live conversations or lead processing. Combined with the isolation model, this is where the 99% uptime over 11 years actually comes from — not from heroics, but from making “deploying” a non-event a maintenance team of one can do safely.

The operational SLA — 8-hour response, 24-hour issue resolution — has been met consistently for the life of the contract.

What 11 years of the same client teaches you

Most agency case studies end at launch. The part we’re proudest of is the shape of the engagement: MVP in 6 months → scale-up team → one senior engineer maintaining a stable, revenue-critical platform, with the client achieving market leadership on software they own outright — their COO’s words: “a wide-ranging multi-branch project delivered on time and kept up to date and running without any application issues.”

Three things we’d tell anyone commissioning a lead platform:

1. Buy the routing speed, not the feature list. Sub-3-second routing converted leads; every other feature was negotiable.
2. Own your platform if leads are your business. Yomdel’s proprietary IP is why they could out-execute competitors renting the same third-party tools — the platform runs roughly 40% more efficiently than the alternatives agencies were using.
3. Choose a team you can keep. The expensive part of software isn’t building it; it’s the years of changes afterwards. Continuity is a feature — arguably the feature.

We build PropTech and lead-generation platforms for UK, EU, and US businesses — and take responsibility for the systems we build. Read the full Yomdel case study or see our PropTech development services.