CASE 09
16 weeks
A bespoke CRM that fits how they actually work, not how Salesforce wishes they did.
A boutique brokerage had cycled through three off-the-shelf CRMs, each abandoned once customization broke on upgrade. We modelled their actual transaction lifecycle — listing to showing to offer to escrow to close — as first-class objects, wired in MLS, DocuSign and payments, and gave buyers a portal that never exposes internal notes.
THE PROBLEM
Off-the-shelf CRMs never fit: showings, escrow, co-brokers, and closing timelines either didn't exist as first-class objects or required heavy customization that broke every upgrade.
Generic CRMs model a pipeline of deals moving one direction. Real-estate transactions fall out of escrow, revive, get reassigned between co-brokers, and carry statutory deadlines that a stage field cannot express.
Because the CRM did not fit, the real state of a transaction lived in a coordinator's head and a shared inbox. When a coordinator took leave, deals slipped past deadlines.
Contracts were email attachments. Finding the executed version of an addendum meant searching three mailboxes, and more than once the wrong version reached a closing table.
CONSTRAINTS WE WORKED UNDER
WHAT WE DID
Modeled the real workflow: listings, showings, offers, inspections, escrow, close.
Automated MLS sync pulls listings nightly; agents only maintain the fields that matter to them.
DocuSign integration means contracts live on the opportunity, not buried in someone's email.
Client-facing portal shows each buyer their journey without ever exposing internal notes.
ARCHITECTURE
01
The transaction is the aggregate root, with listings, showings, offers, contingencies, inspections and escrow milestones hanging off it. Offers are immutable records — a counter creates a new one — so the negotiation history is a fact rather than an edit log.
02
Contingency and statutory deadlines computed from contract dates using configurable rule sets per transaction type, with escalating reminders to agent then coordinator then broker. Recomputed automatically whenever a governing date changes — the class of error that used to cost real money.
03
Nightly ingestion with field-level merge, so agent-maintained fields are never clobbered by upstream data. Licensed fields respect display and retention rules; derived fields are computed locally rather than stored from the feed.
04
DocuSign envelopes created from templates and bound to the transaction. Status webhooks update the timeline, and the executed version is the one the system shows — earlier drafts are retained but visibly superseded.
05
A separate surface with its own query layer that can only read a whitelisted projection of the transaction. Internal fields are not filtered in the UI — they never enter the response.
KEY DECISIONS
WHY
We priced the customization path first. Three prior failures had a common cause: their workflow needed objects the platforms did not have, and bolting them on broke at every upgrade.
TRADE-OFF
Higher upfront cost than another subscription, and they now own maintenance. Against three abandoned migrations, they took the deal.
WHY
Negotiation history is evidence. Mutating an offer row destroys the record of what was actually proposed and when.
TRADE-OFF
More rows and a slightly more complex read model for 'current offer'. Trivial next to reconstructing a negotiation from memory.
WHY
Hiding a field in the interface is one careless API change away from a leak. If the data never reaches the response, the mistake is not available.
TRADE-OFF
Two read paths to maintain. Correct call for a surface where a leak means a commission conversation in front of a client.
THE HARD PARTS
Twelve agents described twelve workflows. Rather than average them into something nobody recognised, we modelled the legally fixed spine — the parts that cannot vary — and made the rest configurable per agent. Adoption followed immediately.
Feed fields arrive incomplete or wrong often enough to matter. Field-level merge with agent-maintained precedence meant a bad upstream value never overwrites a correction, which was the behaviour that had made previous tools untrustworthy.
The original scope had transactions owned by an agent. Real coverage requires shared ownership with an explicit responsibility field, added mid-project after watching a leave handover fail in the old process.
HOW IT RAN
01
Shadowed agents and coordinators through live transactions, mapped the legally fixed spine versus the variable parts, and designed the domain model against real closings.
02
Transactions, offers, deadline engine, roles and permissions, with the coordinator workflow as the primary daily-use path.
03
MLS sync with field-level merge, DocuSign envelopes and webhooks, Stripe for deposits and fees.
04
Portal on its own projection, migration of active transactions, then agent-by-agent rollout with the coordinators as internal champions.
OUTCOME
Weeks → days
Agent onboarding time
12
Agents on one system, after three failed attempts
Automatic
Statutory deadline computation and escalation
1
Authoritative version of every executed document
The whole team is on one system. Agent onboarding dropped from weeks to days because there's nothing to learn that isn't the actual job.
The deadline engine is the feature they would not give up. Contingency dates that previously depended on a coordinator's diligence now escalate on their own.
The buyer portal became a sales asset. Agents pitch it during listing presentations, which was not a goal anyone set at the start.
STACK
APPLICATION
INTEGRATIONS
DOMAIN
SECURITY
HANDOVER
