CASE STUDY · REAL ESTATE · STATUS: PROTOTYPE
A lead spoken into a phone, and everything that has to happen next.
Built for a Charleston real estate team. Rails and React, 207 passing tests, zero security warnings, and a hard rule that nothing becomes a lead until a person confirms it.
Status, plainly. This system is built and it works, in a development environment. It has not been deployed to production anywhere. It has never processed real client data. It has never delivered an email — the mail provider was never configured. The “Stage into Dotloop” button currently errors, because the brokerage’s API credentials are not registered yet. MLS integration was never built. There are no adoption numbers, no time-saved numbers, and no error rates, because there has been no usage to measure.
What is verified: 207 passing tests, zero Brakeman security warnings, voice capture and local transcription confirmed working in browser and on phone, the Monday.com push checked against a real board, and the Dotloop payloads checked against the brokerage’s real account.
Separately, and unrelated to this software: I delivered an on-site AI training session to four agents on this team on July 28, 2026. That was real work with real people. It just was not this.
THE PROBLEM
In real estate, the unit of work arrives by voice.
A call, a voicemail, a conversation in a driveway. It exists in someone’s head and on a notepad, and from there it has to reach the CRM, the follow-up sequence, the transaction platform, and eventually the broker.
Nobody is bad at their job. The system just requires a human to be the wire.
BEFORE
The manual path.
- Agent takes the call and writes on whatever is nearby.
- Later — sometimes days later — types it into the CRM, usually with fewer fields than they meant to fill.
- Writes the follow-up email from scratch, in a hurry, at 9pm.
- Does not check whether that contact ever consented to texts.
- Does not check the language against fair housing, because nobody has time to.
- When it goes under contract, retypes the same names and addresses into the transaction platform.
- Hunts for missing documents by memory.
- Broker reviews it in a shared inbox with no record of who saw what, when.
- If anyone asks six months later what happened on this lead, the answer is in four systems and one person’s memory.
AFTER
The same lead, through the system.
- Agent talks into their phone or browser.
- Transcribed locally with whisper.cpp — the audio does not leave the machine for that step.
- Claude extracts it into a structured lead: name, contact, address, timeline, budget, notes.
- Human confirmation screen. Nothing becomes a lead until a person reads the extracted fields and confirms them. This is the gate, and it is not optional.
- Confirmed lead pushes into the Monday.com CRM.
- The system drafts the client email, the client text, and the internal team note.
- Consent ledger checks per contact, per channel, before anything is queued.
- Fair-housing linter blocks — not warns, blocks — flagged phrasing.
- Nurture cadence tiers by lead temperature, respects quiet hours, and stops the moment a human replies.
- Under contract, the system stages the Dotloop loop and generates the compliance punch list.
- Broker review queue, gated by SC license-law permissions, with who-saw-what recorded.
- Append-only audit trail behind all of it, exportable as a one-file printable dossier.
ARCHITECTURE
What it is made of.
A Rails backend with a React front end. Voice is transcribed locally with whisper.cpp, so no transcription vendor sees the audio. Claude handles extraction and drafting against a strict schema, so the output is structured fields rather than prose somebody has to re-read. Monday.com and Dotloop are reached through their own APIs. Underneath it all sits an append-only audit table and a role-based permission model written against South Carolina license law.
Capture
Browser and phone voice recording, audio file upload, or a typed note. Three ways in, one path out.
Understand
Local transcription, then Claude extraction into a fixed set of fields. The original extraction is kept alongside any human edits.
Confirm
The transcript sits beside every extracted field, all editable, audio replaying while you correct. Nothing proceeds without this step.
Distribute
CRM push, drafted messages, nurture enrollment, transaction staging, broker queue — each one re-runnable without creating duplicates.
Guard
Consent ledger, blocking fair-housing checks, quiet hours, and license-law permission gating that shows plain-English reasons rather than hiding buttons.
Remember
Append-only audit events and a one-file printable dossier per lead: intake, transcript, consent, messages, punch list, full history.
WHAT IT TOOK
The easy half and the hard half.
The voice-to-structured-lead path is the easy half. Transcribe, extract, show a confirmation screen. That part is understood.
The hard half is everything that has to be true before a message is allowed to go out: consent recorded per contact and per channel, quiet hours respected, blocking language checks that a licensed person has to clear in writing, permissions that match what an unlicensed assistant may and may not transmit, and an audit record that cannot be edited after the fact.
That second half is most of the work, and it is the half that does not show up in a demo.
WHAT THIS MEANS FOR YOU
The slow part is already thought through.
The reason this matters even as a prototype: the parts that took longest — the consent ledger, the compliance linting, the permission model, the audit trail — are the parts that do not change much between real estate teams. On a new engagement, that is work that has already been reasoned through once.
What does change per team is the shape of your pipeline, which CRM you actually use, and which handoffs hurt most. That is what the Assessment is for.
Want to know what this would look like for your team?
Start with the Map. Two weeks, $750, and a written plan you could hand to any competent developer.
Start with the Assessment →