REConnect: MLS Data Platform Case Study

Problem

A brokerage does not have one neat feed of homes. Listings arrive from multiple MLS boards, each with its own dialect of fields, photos, and agent records. Staff were spending their time reconciling those feeds, and support was spending its time answering the same questions about why a listing looked wrong or why a photo had not arrived. The product had to ingest that data, normalize it, and present one model to tools agents already use, including design tools such as Canva, without turning the back office into a second full-time job.

Scale was not a press-release problem. It was a support and data problem. 15,000+ agents means a bad sync is not a private bug. It is a morning of tickets. The platform also had to keep growing as more firms joined, which rules out a design that only works for the first friendly customer. Tenancy, auth, and the ingest pipeline had to be explicit.

There was a second problem sitting on top of the data. Support load grows with agent count. Hiring linearly against tickets does not work once the questions are repetitive and the answers live in the product itself. The team needed a way to answer from real listing and account context, and to leave the unusual cases for people.

My role

I am the lead engineer and architect for this work at SL Tech (Streamline Technology), remote for a US team. I own the path from MLS ingest to the API agents and partner tools call, and I lead a group of about ten senior engineers. That means I still make schema and boundary decisions, and I also review the work that implements them. I am the technical contact stakeholders can ask when a feed behaves strangely or a release needs a tradeoff explained in product language.

The role is not a slide titled architect. On a given week I am in the Laravel services, the React surface, the sync jobs, or the agent tools, depending on what is blocking a firm. I also set the rule for the chatbot: it can resolve the common ticket, and it cannot invent a listing fact that the database does not have.

Stack

The core application is Laravel on PHP, with MySQL and REST APIs. The product UI is React. Ingest talks to MLS sources through a RESO Web API style integration, maps those payloads into one model, and keeps an OAuth-secured layer for clients that should see only what their brokerage allows. Photos and listing fields move through normalization jobs, not through a request that hopes the remote board is fast. The support side is a production AI agent setup with an MCP-based chatbot, so the tools the bot calls are the same class of tools the platform already trusts, not a side door into the database.

• Laravel, PHP, MySQL, REST
• React for the product UI
• RESO Web API style MLS integration
• OAuth for partner and client access
• Queues for ingest and normalization
• MCP server and AI agents for support

Architecture

I split the system into ingest, the canonical listing model, and the delivery API. Ingest accepts feeds from multiple boards and writes a record of what arrived, including enough of the raw payload to debug a mapping failure later. Normalization turns that into the model the rest of the product reads. The API never scrapes a board on behalf of a user who is waiting on a page. If the data is stale, the product can say so. It does not pretend a live call succeeded.

Tenancy sits in that model. A brokerage sees its agents, its listings, and its connections. OAuth clients, including the Canva path that pulls listing and agent details, get scopes rather than a shared admin credential. Background jobs retry board calls. A poison message does not stop the rest of the queue.

The support chatbot is a client of this architecture, not a parallel one. It retrieves product context and calls tools that already enforce brokerage rules. About 90% of support tickets are handled there because most tickets are lookups and known fixes. The remaining tickets stay with people, which is the point of measuring the percentage instead of claiming the queue disappeared.

Results

REConnect is in production for 15,000+ agents. Listing data from multiple boards lands in one model, and partner tools can pull photos and agent details through an authorized API instead of a manual export. Support load changed shape: AI agents handle about 90% of tickets, and the team spends its time on the rest.

The result I care about as an engineer is that the pipeline is operable. A bad board day is a job failure with a payload you can inspect, not a silent hole in an agent's catalog. New firms join the same tenancy model instead of a fork. That is what lets a team of senior engineers keep shipping without rediscovering the data rules every month.

reconnectapp.com

Related services