MARL: how we built a 100K-user real estate app and sold it

From concept to 100,000 users to acquisition — the full story and the decisions that shaped it.

MARL was a real estate mobile app with live MLS data integration, neighbourhood analytics, and agent-client communication tools. We built it, grew it to over 100,000 users across Canada, and sold it.

This is the full account of how it happened, what we got right, what we got wrong, and what we would do differently.

The problem we were solving

In 2015, the real estate search experience on mobile was a consumer-facing property search with no tools for the agent-client relationship. Buyers searched on Realtor.ca. Agents emailed PDF listings. Conversations happened over text and voicemail.

The gap we saw was in the collaboration layer — a shared workspace where buyers and agents could search together, annotate properties, track showings, and communicate without switching between four different apps.

We had been building mobile apps for six years. We knew how to ship. What we did not know yet was how complex MLS data integration would turn out to be.

MLS integration: the hard part

MLS data in Canada is federated. There is no national MLS API. Every regional board has its own system, its own data format, its own access requirements, and its own latency characteristics.

We integrated with the major boards covering the GTA, Vancouver, and Calgary. Each integration required a separate agreement, separate credentials, and a separate data pipeline. The schemas did not match. Refresh frequencies varied from near-real-time to 24-hour batch. Some boards required that specific fields be displayed in specific ways.

We spent three months on MLS integration before we had a working prototype of the actual app. If we did this again, we would budget more aggressively for the data layer and set more conservative timelines for everything downstream of it.

What we built

The core product was iOS and Android apps with four main components: property search with filters and map view, property detail pages with MLS data and neighbourhood context, a shared favourites and notes system for agent-client collaboration, and a messaging layer that kept conversation in context with specific properties.

We also built an agent-facing web dashboard for managing client relationships and tracking showing history.

The technical stack was React Native for mobile, Node.js for the backend, PostgreSQL with PostGIS for geospatial queries, and custom ETL pipelines for each MLS integration.

Growth to 100,000 users

We launched in the GTA first and expanded market by market as we added MLS integrations.

Growth came primarily through agent adoption. Once an agent used MARL with one client, they used it with all of them. We focused on onboarding agents rather than consumers directly, which gave us better retention and more predictable word-of-mouth.

The jump from 10,000 to 100,000 users exposed scaling issues we had not anticipated. The MLS data pipelines that worked fine at 10,000 users showed lag at 50,000. Map queries that were fast with a small active user base slowed as concurrent users grew. We spent about three months on infrastructure work between the 50K and 100K mark that we should have anticipated earlier.

The acquisition

We were acquired in 2019. The acquiring company was interested in both the technology and the user base.

The negotiation took about four months from first conversation to close. The things that made the acquisition go smoothly: clean code, well-documented APIs, data that was genuinely valuable, and an active user base. The things that complicated it: MLS data licensing agreements that needed to transfer, and one integration that was more tightly coupled to our infrastructure than it should have been.

If you are building with an acquisition in mind, think early about what a buyer would want to see in your data room. Clean contracts, documented integrations, and a user base with measurable engagement are the things that move the needle on valuation.

What we would do differently

First, budget more time and money for the data layer. MLS integration was harder than expected and was on the critical path for everything else.

Second, build the agent dashboard earlier. The agent-facing tools turned out to be more important for retention than the consumer features, but we treated them as secondary. They should have been primary from day one.

Third, think about the acquisition data room from month one. Not because you should optimize everything for exit — that is the wrong frame — but because the discipline of keeping clean contracts, documented systems, and measurable metrics makes you a better operator regardless of outcome.

If you are building a PropTech product in Toronto or Ontario, we know this space. Book a strategy call.