Real Estate CRM Software Development: Features, MLS Integration and Build vs Buy

Build only if the CRM is your edge

Off-the-shelf real estate CRMs are good and cheap for what they do. Follow Up Boss, for example, lists its Grow plan at $69 per user per month ($58 billed annually), Pro at $499 a month including 10 users and Platform at $1,000 a month including 30 users (Follow Up Boss pricing, checked October 2026). A 30-agent team pays roughly $10,000 to $12,000 a year. A custom CRM cannot beat that on cost alone.

Custom makes sense when the CRM is part of the product or the operating model: a brokerage with its own lead routing rules and commission splits, an iBuyer or rental operator where the CRM drives offers and inspections, a PropTech startup selling a CRM, or a team that has outgrown three tools glued together with Zapier and wants one data model.

Features by user

Lead routing: where custom CRMs earn their keep

Leads arrive from portals, the brokerage website, paid ads, open houses and referrals. A good routing engine decides in seconds who gets each lead and what happens if nobody responds. Typical rules:

• Match on area (zip code or polygon), price band, buyer or seller, language and lead source.
• Round-robin among eligible agents, weighted by performance or capacity.
• Response timer: if the agent does not call or text within, say, five minutes, the lead moves to the next agent or to a shared pond.
• Source-specific rules, for example portal leads with referral fees go only to agents on that programme.
• Every assignment and reassignment written to an audit log, because routing disputes between agents are common.

We built the same shape of engine for Seek My Service, a service marketplace where requests are matched to vendors by cross-referencing their subscription areas and categories against the client's zip code, with SMS, email and in-app notifications through Twilio and SendGrid and five roles with route-level permissions. It is a services marketplace, not real estate, but the routing and notification problem is the same.

MLS and IDX data through the RESO Web API

Listing data comes from the MLS. The Real Estate Standards Organization (RESO) Web API is the current standard way to receive it: a RESTful API built on the OData V4 specification, which replaces the older RETS standard that RESO has deprecated. Field names come from the RESO Data Dictionary, and MLSs certify their Data Dictionary compliance on the Web API (RESO Web API, checked October 2026).

• Access is per MLS. You need a data licence agreement with each MLS (directly or through a broker's membership), and each MLS has its own display rules for IDX, VOW and broker back-office use.
• Replicate, then serve. Most products pull listings on a schedule into their own database and search index rather than calling the MLS on every page view.
• Photos are the heavy part: plan storage, resizing and a CDN.
• Aggregators such as Bridge Interactive, Spark API and Trestle can reduce the number of separate MLS integrations; their fees and terms vary by MLS.

For the cost of a full listings portal (map search, saved searches, alerts and lead capture), our cost to build a real estate app like Zillow post breaks it down: $36k to $66k for an MVP in 11 to 20 weeks, and $75k to $138k for the fuller product. Open the Zillow preset in the calculator.

E-signature and transaction management

Do not build e-signature. Integrate DocuSign, Dropbox Sign or a similar provider through their APIs: they handle the legal signature trail under the US ESIGN Act and UETA, and agents already know them. The custom work is around them: generating the state's purchase agreement and disclosures from deal data, sending envelopes, tracking status by webhook and filing the signed copies against the transaction.

Transaction management is a checklist engine with dates. Each deal type (buyer purchase, listing, lease, new build) has a template of tasks and documents; contract dates (acceptance, inspection, appraisal, financing, closing) generate deadlines; a transaction coordinator or broker reviews documents before the file is closed. The data model is simple. The work is in configuring templates per state and keeping deadlines correct when contract dates change.

Data model and reporting

Most of what agents and brokers ask for in a CRM is reporting, and reporting is only as good as the data model underneath. Four entities carry almost everything: the contact (a person, with consent records and every phone number and email they have used), the lead (one enquiry from one source at one time, so a contact can have several), the deal (a transaction with a type, stage, dates, price and commission split) and the activity (every call, text, email, showing and task on a single timeline). Keeping lead and deal separate is the decision that matters most: it lets a brokerage report on cost per lead by source, conversion from lead to deal by agent and time from first contact to closing, which are the numbers that decide where marketing money goes.

Expect agents to keep using their phones. A CRM that does not log calls and texts made from the agent's own number, or does not offer a business number through Twilio that forwards to their mobile, will end up with empty timelines. Plan this in the MVP, not as a later feature.

Architecture we would recommend

Geo search matters for both listings and routing. We used MongoDB 2dsphere indexes for location matching on CareFlair, a two-sided care marketplace in Australia; PostGIS does the same in PostgreSQL.

Cost

We have no published real estate case study yet; the work cited above is adjacent. The real estate app development page and the real estate industry hub describe what we build in this sector, and the app development cost calculator gives a range for your own feature list.