Deal Studio: From Research to Shared Work

The earliest preserved substantive Git evidence is dated April 21, 2025. It contains PowerShell and Selenium tooling for collecting Redfin land listings, enriching them with Regrid parcel information, and writing records to SQL Server.

The distinction between a listing and a parcel was already explicit. A listing described an opportunity being marketed. A parcel record described the underlying land and its tax identity. Asking price and advertised acreage belonged to one source; ownership, assessed values, and legal descriptions came from another. A separate relationship connected them.

That relationship could not always be inferred from an address or a point on a map. The backfill workflow opened Regrid near a location and asked the operator to select the correct parcel. By April 23, it also allowed a listing to be skipped and corrected the pairing logic so that an existing property could still be connected to another listing.

The practical problem was visible in those instructions. Finding nearby land was useful. Recording the correct relationship still required judgment.

A separate repository, DealStudioPrototype, already contained a branded ASP.NET Web Forms application on April 22. It had leads, separate deal records, persisted property notes, and a manual interface for pairing listings with parcels.

The scraper and the web application were developing alongside one another. While the collection scripts were being corrected, the application was already giving the resulting research a place to be reviewed, annotated, and pursued. Its first substantial commit contains an existing body of work; it does not tell us how long that work took.

Several changes over the following days make the expansion unusually clear. On April 23, a polygon drawn on the lead map became an input to a server-side spatial query. On April 26, lead details began retrieving parcel information through the listing-to-property relationship, displaying assessor context and a satellite preview.

FROM Leads L
LEFT JOIN RedfinPropertyPairs RPP ON L.ExternalID = RPP.ListingID
LEFT JOIN Properties P ON RPP.TaxID = P.TaxID
WHERE L.LeadID = @LeadID

The same April 26 layout included contact and task sections, although those remained mock interface content. By April 27, registration code was writing distinct Contacts and Users records, alongside login, sessions, and profiles. People were becoming part of the stored model, even while some of the surrounding workflow remained a sketch.

The available history then has a gap: neither repository preserves commits from April 28 through June 19. On June 20, a substantially rewritten Deal Studio application appears, using FastAPI, React, PostgreSQL, and PostGIS.

The evidence strongly supports a rewrite of the earlier workflow. There is no shared Git ancestry between the repositories, and the comparison found no whole-file migration at the examined checkpoints. The clearer continuity is in the relationships: a lead connected to a listing, a listing paired with a parcel, research attached to property identity, and a deal represented separately from a lead.

June transfer scripts directly target several database structures used by the prototype, including leads, contacts, users, and listing-to-parcel pairs. They strengthen the connection between the two implementations. They do not establish that every transfer ran successfully or that the old data reached the final model intact.

The newer application made more distinctions explicit. Listings became normalized records separate from incoming source data. Property notes broadened into interactions. Tasks acquired stored assignments and due dates. Users and organizations became part of the ownership model.

The public description on Land-Based Strategies set out a broader scope: sourcing, enrichment, diligence, underwriting memory, collaboration, and reporting. It described preserving assumptions and decisions as an investment thesis changed. The repositories show parts of that model taking form, including parcel research, notes, and assigned work. They do not establish the full underwriting, reporting, or execution system described there.

Looking back, I recognize the collaborative direction I remember from that period. Research needed to retain enough context for someone else to return to it: which property was being considered, what had been learned, who was involved, and what needed to happen next.

The broader architecture did not make every workflow more complete.

In the April prototype, the drawn polygon reached the server query. In the June application, drawing remained in the interface, but the located lead request did not send the polygon as a search constraint.

Lead-to-deal promotion showed a similar difference. The prototype connected its button to a handler that inserted a separate deal record. June retained a promotion service, while the corresponding interface action changed the lead’s stage without calling that service.

The simpler prototype had its own gaps. An early note insert used a different timestamp column from the note query. Later map filtering depended on a stored procedure whose definition is missing from Git. The comparison does not establish that the prototype worked flawlessly.

It does show that a rewrite can preserve an idea while losing a connection needed to use it. The model became more ambitious before all of its paths were joined back together.

Later development expanded sourcing into Texas tax-sale PDFs and other acquisition sources. The parser history gives a more detailed account of the work than a list of supported sources would.

A general PDF parser gradually accumulated exceptions. Case numbers and legal descriptions did not consistently occupy the same positions. An address beginning with zero could be legitimate. One sale item could contain several geographic identifiers. A preserved document even contained a malformed printed minimum-bid amount.

By July 14, Brazoria documents could be routed to a separate parser combining text and table extraction. Some differences could be handled after a record was parsed; others required a different way of reading the document itself.

The source material was changing the structure of the software. The earlier parcel-confirmation prompt had exposed the same constraint in another form: collecting information did not settle what it meant or whether the relationship was correct.

Deal Studio contained acquisition research, basic price-per-area calculations, assessor information, and follow-up workflows. The repositories do not establish a complete underwriting engine or an autonomous investment system. They also do not establish production adoption, user counts, revenue, transaction volume, successful deployment, or investment outcomes.

The final preserved state remained unfinished. An August notification integration imported an email helper that the checked-in module did not define. The available history ends on August 30 with an unresolved connection, rather than a demonstrated release milestone.

These limits are part of what survives alongside the substantive work: an acquisition system being assembled, revised, and extended, with some paths implemented and others still incomplete.

I remember Deal Studio as a precursor to the systems I later built at Upperline. Before I joined, I had begun building a model of collaborative acquisition work: distinguish records that represented different things, make their relationships explicit, preserve the research around an opportunity, and give follow-up a place in the system.

Upperline gave those assumptions an operating environment. Other people had responsibilities. Deals accumulated documents, communications and decisions. Investment work had to survive handoffs. Deal Studio had given some of those ideas an early software form; at Upperline, they would encounter the organization itself.