MLS Platform Software: What Happens When the RESO Feed Stops and 6,000 Brokers Notice

Why an MLS core is not a listings website with a login

At 8:40 on a Tuesday morning the syndication feed to a major portal fails validation and stops. Within 20 minutes the MLS help desk has 60 calls, because a broker's listings vanished from a consumer site and the broker's seller is on the phone. The MLS staff cannot see inside the feed job, cannot replay it, and cannot tell the broker when it will recover, because the platform is a vendor product and the answer is a support ticket. Meanwhile the rules committee approved a change three weeks ago about how a status must be updated within a fixed number of hours, and the vendor has scheduled it for a release next quarter.

That is the actual product an MLS sells: continuous availability of clean, rule compliant data to thousands of subscribers and dozens of downstream consumers, under enforceable local policy. Not a search interface. CoreLogic Matrix, Rapattoni, FBS Flexmls, and ICE Paragon are the incumbents and they are serious systems with decades of accumulated domain knowledge, particularly around field level rules and broker workflow. Flexmls has been notably responsive on standards work. The constraint is not that they are bad. It is that an MLS is a governed cooperative whose rules are set locally by a board, and a multi tenant vendor product can only expose the configuration surface it chose to expose. When your policy needs something outside that surface, you wait, or you do it manually, or you do not do it.

In the platform work we have done for data cooperatives and marketplaces, the pattern that pushes an organisation toward building is always the same: the rate of policy change exceeds the rate of vendor change. Everything else, cost, performance, interface preference, is negotiable. That one is not.

Problem 1: RESO compliance is a certification you keep earning, not a port you finish

The Real Estate Standards Organization Data Dictionary and Web API are the reason a national brokerage or a technology partner can consume your data without a bespoke integration, and NAR requires MLS compliance with RESO standards. The Data Dictionary evolves. The Web API has its own versioning and certification process. Meanwhile RETS, the older transport, is being retired, and every consumer still on it needs migrating on a timeline you do not fully control.

What a custom build does: treat the standard mapping as a versioned layer rather than as your database schema. Your internal model holds your local reality including fields the dictionary has no place for, and a mapping layer projects it into each supported dictionary version. You can then serve a partner on an older version while another consumes the current one, and a dictionary update becomes a mapping change rather than a core migration. Put the certification tests in your own continuous integration so a conformance regression fails a build rather than an audit. Getting this backwards, meaning building your core in the shape of the current dictionary, is what makes legacy systems impossible to evolve.

Problem 2: the rules are the product, and they are local by design

Every MLS has its own rule book. Photo minimums and how quickly they must be added. Status change deadlines measured in hours. What may appear in public remarks. Coming soon duration and what marketing is permitted during it. How days on market and cumulative days on market are calculated when a listing is withdrawn and relisted, which is one of the most argued numbers in the industry. Display and cooperation policies, including the practice changes that followed the NAR settlement, which removed offers of compensation from MLS display and left each MLS implementing surrounding policy locally.

Vendor platforms expose rules as configuration flags. That covers the common cases. It does not cover the rule your board passed last month that ties a fine schedule to a repeated violation pattern across a brokerage rather than a listing.

What a custom build does: rules become first class, effective dated objects with their own test cases. A rule has a trigger, a condition, an action, a severity, and a date it took effect, and historic enforcement is evaluated against the rule version that applied at the time, not the current one. That matters when a broker appeals a fine from four months ago. Validation runs at input in real time so an agent is corrected before publishing rather than fined afterwards, which every MLS says it wants and few can do. The compliance queue then holds only what genuinely needs human judgment, and the fines workflow carries notice, appeal, and resolution with the evidence attached.

Problem 3: media is the operational cost nobody puts in the business case

A modern listing carries 40 photographs, a floor plan, a video, and sometimes a three dimensional tour. Across an active market and a decade of archive, that is a very large object store with a demanding read pattern, and it is where MLS platforms actually fall over. Upload handling has to cope with an agent pushing 60 images from a phone on a poor connection at a property. Ordering matters and gets re sequenced. Watermarking and attribution rules differ by policy. Downstream consumers each want their own sizes.

What a custom build does: separate the media pipeline from the listing transaction entirely. Uploads land as immutable originals, and derivatives are generated asynchronously at the sizes each consumer needs, served from a CDN with signed URLs so licensing is enforceable rather than aspirational. The listing references media by identity, so re ordering is a cheap metadata operation and never a re upload. Retention policy is explicit, because archived media is a real cost line boards should decide consciously. Duplicate detection at ingest is worth building, since the same photo set reappearing across relistings is both a storage cost and a quality signal.

Problem 4: the history is the asset, and legacy schemas quietly destroy it

An MLS's long term value is not today's active inventory, which the portals have anyway. It is the complete, field level history of every listing in the market: what it was priced at on each date, how status moved, when it went off market and came back, which office held it, what changed in the remarks. That record supports comparative market analysis, appraisal, market statistics, dispute resolution, and any analytics product the organisation might sell.

Legacy systems commonly store the current state and a partial change log, which means reconstructing what a listing looked like on a given date is guesswork. Once that history is compromised, no amount of future engineering restores it.

What a custom build does: an append only event record for every change, with actor, timestamp, previous and new value, and the rule context. Current state becomes a projection of that record, not the source of truth. This makes days on market calculations reproducible rather than contested, makes an audit of who changed what trivial, and turns your archive into something you can license with confidence. It also happens to be the cleanest way to implement the change feeds that downstream consumers want, since they can ask for everything since a timestamp and get a correct, complete answer.

Problem 5: feeds are contracts, and an outage is a governance problem

IDX, VOW, broker back office feeds, syndication, appraisal and analytics licences, each is a data licence agreement with defined permitted use, defined fields, and defined recipients. In many MLSs the actual technical enforcement of those agreements is loose: a feed is provisioned once and then forgotten, and nobody can readily prove which fields a given consumer received last March.

What a custom build does: the licence is the configuration. A data licence defines the consumer, the permitted field set, the geographic and status scope, the delivery mechanism, and the term, and the feed is generated from that definition so it cannot drift from the agreement. Every delivery is logged with counts and a checksum, so when a broker asks why their listing did not appear on a site, staff can answer in the call rather than opening a vendor ticket. Deprovisioning on termination is automatic, which is the control most often missing. Rate limits, keys, and per consumer monitoring turn feed reliability into something your team owns rather than something that happens to you.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape for a platform of this weight. A focused first release, meaning the data core with event history, RESO aligned mapping and Web API, listing input with real time rules validation, media pipeline, and feed provisioning, runs $120,000 to $250,000 in 18 to 26 weeks. A full replacement adding roster management with association sync, compliance and fines with appeals, licence administration, public record integration, statistics, and member facing search runs $350,000 to $900,000 over 12 to 20 months.

What drives price up specifically for an MLS: the volume and quality of historical data to migrate, almost always the largest single work item because decades of records carry field meanings that changed over time. The number of downstream consumers, since each is migrated with its own testing and tolerance for disruption. Association roster integration. Public records and parcel data, which arrives per county in per county formats. And governance overhead, since rule decisions need committee time no schedule can shorten.

What keeps price down: phasing, so the new platform becomes the system of record for data and feeds while the incumbent front end keeps serving subscribers, then the member experience migrates.

Build versus buy, and when staying with your vendor is right

Stay with the incumbent if you serve under roughly 1,500 subscribers, your rule set is close to regional norms, and your board's policy changes are infrequent. Rapattoni and FBS Flexmls both serve organisations of that size well and the economics of building will not work. Also stay if your real complaint is the user interface, because a front end can be replaced against a vendor API for a fraction of a platform replacement, and that is the cheaper answer to a common problem.

Build, or commission a build you own jointly with peer MLSs, when two or more of these are true. Your policy change cycle is materially faster than your vendor's release cycle, and manual workarounds have become normal operations. You are consolidating with other MLSs and need one platform across differing rule sets, which is a data model problem no configuration screen solves. Your data licensing is a real revenue line and you cannot administer or evidence it. Your historical data is degraded and you need an event based record before more of it is lost. Or you want to build products on top of your data, in which case owning the platform is the precondition.

How to choose a developer for an MLS platform

Ask them to explain how they would keep your core model independent of the RESO Data Dictionary while still certifying against it. If they propose making the dictionary your schema, they have not thought past the first release and you will be locked to a version.

Ask how they model rules. You want to hear effective dated rule objects with test suites and historic evaluation, not a settings page. Then ask how a fine issued last quarter is defended when the rule has since changed.

Ask what they have built at this shape: multi tenant data platforms with high read fan out, event sourced history, and third party feed consumers under contract. Real estate experience is a bonus, the architecture skills matter more.

Ask who owns the code and the data, in writing, before kickoff, and ask about the exit path. You should own the repository and the full historical archive in exportable form. An MLS that has just spent a decade constrained by a vendor should not sign a contract recreating the same dependency under a different name.