Zero-to-one backend architecture for a consumer PropTech platform
NEO is a consumer-facing real estate platform built from scratch to surface pre-construction and under-construction property listings — inventory that is often missing or fragmented across traditional MLS systems.
I owned the backend architecture end-to-end, from initial system design through first production launch and subsequent growth. The platform was designed to support highly variable listing data, performance-sensitive search queries, and fluctuating consumer traffic while remaining simple to operate and evolve.
This case study outlines the zero-to-one decisions, trade-offs, and production learnings involved in taking NEO from concept to a live, consumer-used system.
When we started NEO, the real estate ecosystem lacked a dedicated, centralized marketplace for pre-construction and new-build inventory. Traditional MLS platforms did not consistently surface this data, limiting discovery for agents, developers, buyers, and investors.
From a zero-to-one standpoint, the challenge was to design a backend system capable of supporting multiple stakeholder types, dynamic and non-uniform listing attributes, and performance-sensitive search — all without the safety net of an existing architecture.
NEO serves multiple user groups with overlapping but distinct needs:
The backend needed to reconcile these perspectives into a single, searchable platform while supporting rapid data changes and evolving product requirements.
The backend followed a stateless service architecture to enable horizontal scalability and predictable performance under variable load.
MongoDB was used to model property and project data with significant variability across regions, builders, and project types. Indexing and query optimization were applied to support fast search and filtering across large datasets.
As a greenfield system, decisions balanced speed of delivery with long-term sustainability:
The initial launch focused on stability and observability rather than feature completeness.
This approach allowed the system to evolve based on real usage instead of assumptions.
With hindsight from production operation, I would:
These refinements reflect learnings from scale rather than fundamental architectural mistakes.
The system was designed to scale predictably while remaining simple to operate and evolve.
Discuss this project →