Case study ยท Proof: application

Deal-Flow Infrastructure for a Real Estate Acquisition Company

The engagement

I was retained as the embedded AI systems architect for a mobile home park and RV park acquisition company. They needed to screen inbound deals fast, make sure deals sellers submitted actually reached the principal, and build the off-market sourcing and intake around it. I planned and specced each system, built it with Claude Code, and deployed it. The company runs the systems themselves. I am not in the loop for routine use.

The outcome

The company can take a raw pile of deal documents and get a defensible buy, hold, or pass read in a few minutes for under a dollar. Deals that sellers submit route straight to the principal with an automatic acknowledgment back to the seller, and an off-market sourcing pipeline surfaces the park owners the public listing sites miss. The deal analyzer alone went from $8.00 per analysis to about $0.60, and got more accurate in the process.

Hero system: the deal analyzer

What was actually going on

A non-technical buyer was receiving deal packets (offering memos, trailing-twelve financials, rent rolls, utility bills, leases) that never agree with each other. The offering memo is optimistic, the actuals tell a different story, and the numbers are scattered across formats. Reading each packet by hand is slow. The fast way, pasting everything into one AI prompt and asking for a verdict, is the reliable way to get a confident wrong answer.

The first version I built did exactly that. It cost $8.00 per run, and it reported a different NOI in the metrics, in the offers, and in the cap-rate math on the same deal. That failure defined the real problem. The financial math cannot live inside a model that is free to say something different each time it renders.

What I decided, and what I ruled out

This is the part that matters. Each decision is the path I took and the plausible path I rejected.

  • Rejected the single mega-prompt. I split the work into a staged pipeline where each stage does one job and passes structured data forward. Parse, reconcile, compute, evaluate, structure, assemble. Four AI calls, two deterministic code steps.
  • Rejected letting the model do the math. The model reads the documents and extracts the numbers. Plain code compares the sources, decides which to trust, and computes NOI and the metrics once. This is the load-bearing decision of the whole build. Model wording can change. The math cannot.
  • Rejected trusting whatever number got extracted first. A reconciliation step compares every source against the others and selects what to trust on a fixed hierarchy, where actual trailing-twelve financials outrank an optimistic offering memo, and it flags where sources disagree.
  • Rejected a tool that always answers. When the documents are thin or contradictory, it grades its own confidence and returns a provisional verdict instead of a number it cannot stand behind.
  • Rejected one model for every job. Parsing and structuring run on a mid-tier model. The one judgment stage, market research and red flags, runs on the strongest model with web search. The report write-up runs on the cheapest model. Output volume is the primary cost driver, so putting the cheap model on the writing is where most of the savings came from. Staging plus this split is what took a run from $8.00 to about $0.60.
  • Rejected paying for the client's runs. The tool accepts the client's own API key. They own their runtime cost and their data, and I am not a cost bottleneck sitting between them and their own tool.

Where this could break

  • Market value depends on a cap rate the judgment stage researches live, so that one figure moves between runs while NOI stays fixed. I present value as a provisional estimate off a single chosen cap and never place it co-equal with NOI in the verdict. Anyone reading the report has to treat value as an estimate, not a hard number. That is a deliberate design choice, not a defect.
  • It was validated end to end mostly on one asset type. The RV path shares the same code but has had less real-world validation.
  • The 180+ automated tests cover the deterministic core, the part that does the math. The model stages are not unit-tested. A bad extraction is caught by the sanity bands and the reconcile flags, not by a test. That is a conscious tradeoff. The guardrails sit where the dollars are.
  • One near-miss worth naming. On a real multi-document deal, the normalized NOI was actually negative where a naive single-prompt tool would have reported a healthy positive figure and a believable cap rate. The confidence and reconcile layer turned a silent failure into a loud one.

What changed

Same pile of documents, a few minutes, about $0.60, and a verdict the buyer can defend. NOI is consistent across every section of the report, and the weak spots are flagged instead of smoothed over. The first build proved the trap. The staged, code-decides build is what made the tool both trustworthy and cheap enough to run on every inbound deal. Total build time was roughly 8 to 10 hours, most of it spent on the numbers-consistency troubleshooting, not the wiring.

Supporting systems

Deal submission and routing

Deals that sellers submitted were disappearing into the CRM's default owner assignment and never reaching the principal. Worse, a stock outreach workflow that shipped with the account was auto-emailing cash offers and bot-texting the very sellers who had just filled out the form. For a company whose entire brand is patient, long-haul ownership rather than fast-cash wholesaling, its own system spamming sellers with cash offers was a real credibility risk. I rebuilt the intake so a submission creates the contact, tags it, logs the full property detail, sends the seller a genuine acknowledgment by text and email, and notifies the principal and operator directly. Then I shut off the rogue outreach. Competency shown: workflow reliability and brand-risk cleanup inside a messy inherited system.

Off-market sourcing

The public listing sites miss most small parks, and the owners sit behind LLCs. I built and proved out a pipeline that pulls off-market park lists through a major listing platform's public API, resolves the owner and the LLC behind each parcel through skip-tracing data, and classifies every phone number as landline or mobile through a carrier lookup so outreach reaches the right line. Competency shown: applied data engineering and public-records enrichment.

Website and intake front door

The brand website and the submit-a-deal page host the form that feeds the routing system. Supporting scope: the entry point to everything above.

What I'd do next

Validate the RV path against real RV park deals with the same rigor the MHP path already has, and add a lightweight check on the extraction stages so a bad parse is caught by a test, not only by the sanity bands.

Let’s talk.

If you are weighing where AI actually belongs in your business, the first step is a conversation.