Deal Studio: An Investment Systems History

During my distressed-investing years, I collected foreclosure opportunities, put information into SQL, and wrote queries to narrow what deserved further investigation. The question could change from one opportunity set to another. A useful tool might be a scraper, a query, or a small piece of analysis built for the problem in front of me.

$Address = $chrome.FindElements([OpenQA.Selenium.By]::TagName('h1'))[0].Text
$County = $chrome.FindElements([OpenQA.Selenium.By]::TagName('dd'))[0].Text
$SaleType = $chrome.FindElements([OpenQA.Selenium.By]::TagName('dd'))[1].Text
$SaleDate = $chrome.FindElements([OpenQA.Selenium.By]::TagName('dd'))[2].Text
$AccountNo = $chrome.FindElements([OpenQA.Selenium.By]::TagName('dd'))[3].Text

/*CREATE TABLE LGBSDetails
(
	[APN] nvarchar(25)
	,[StateClassCode] nvarchar(55)
	,[LandUseCode] nvarchar(55)
	,[LandSize] int
	,[BldgSize] int
)
*/

Getting a record into a database did not make it an investment. Property and ownership research still followed. So did questions about title, liens, access, value, and what could realistically be done before an auction or closing.

The tools became part of that work. Their value depended on what I could establish and execute after they produced a result.

Blinka Road in Waller is one example of this earlier period.

I had built a scraper that collected foreclosure opportunities and inserted the resulting data into SQL. A one-off query brought Blinka to my attention because of the apparent pricing spread and the size of the property. Further research showed significant road frontage, which suggested a subdivision thesis.

I contacted the owner, negotiated the acquisition, and drafted the purchase agreement. My investment partner and I arranged private financing for approximately 80% of the purchase price and brought the transaction to title. We obtained a postponement of the scheduled foreclosure auction to allow time to document the loan and close. An old judgment and delinquent property taxes were among the issues we had to address.

After acquiring the property, we demolished old structures and cleaned it up. We then executed a plat-exemption/subdivision strategy that divided approximately 10.5 acres into four smaller parcels. The final parcel sold approximately four months after we acquired the parent tract.

Blinka did not run through the later Deal Studio application. It belongs to this history because the scraper, database, query, research, and acquisition work were already operating together.

The Land-Based Strategies transaction account documents that sequence in the context of the investment practice.

Much of the early work was bespoke. A query answered a particular question. Research informed a decision. A contact or title issue created the next task. Those pieces did not necessarily remain together in a form I could return to later.

Preserving source records was only part of the problem. I also wanted to retain what I had learned about an opportunity: why it seemed interesting, what needed checking, whom I had contacted, and why I had pursued it or passed.

That problem became a larger part of the software work. I explore the experience behind it more fully in The System Has to Remember. Here, it explains the move from separate tools toward an application with persistent records and relationships.

The preserved history of the later named application begins in April 2025. Those commits provide a dated record of the later software, not a start date for the investment tools that preceded it.

One recurring problem was the relationship between a listing and the underlying parcel. They represented different things. A listing could supply an asking price and marketing information; a parcel supplied another set of identifiers and property information. Connecting them required care.

An April collection workflow used PowerShell, Selenium, Redfin, Regrid, and SQL Server. Its instructions preserved a practical warning: reaching a nearby parcel on the map did not establish that it was the correct parcel.

An overlapping Web Forms application made some of those relationships available through lead and property records. A later query retrieved a lead through its listing-to-parcel pairing:

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 application also developed notes, map filtering, and contact and user records. The surviving versions need to be read individually: some contact and task presentation was mocked, while later April work added persistent contact and user functionality.

By June, another implementation used FastAPI, React, PostgreSQL, and PostGIS. Its model extended across listings, interactions, tasks, assignments, users, and organizations.

The preserved repositories do not establish a continuous code migration from the earlier Web Forms application. Transfer scripts show work toward moving selected records, but they do not prove that a complete migration occurred.

The broader model also ran ahead of some connections in the interface. In the inspected June version, a drawn map polygon was not passed into the lead query. A promotion control changed a stage without invoking a separate backend deal-creation service.

These distinctions matter to the record. A model, a service, and a working path through the interface are different kinds of evidence.

Collection continued alongside the application work. Texas foreclosure documents presented problems that a single parser could not reliably resolve: varying layouts, legal descriptions, multiple identifiers, missing or zero-valued addresses, and malformed bid values.

July work on Brazoria County used separate text and table parsing approaches. The source material required interpretation as well as extraction.

The surviving record through August 2025 contains unfinished work. It does not establish a completed underwriting platform, broad adoption, or a system through which every transaction passed.

Deal Studio’s history includes useful individual tools, an acquisition informed by those tools, and a later application that attempted to bring more of the surrounding work together.

I later continued working on related operating questions at Upperline. That work belongs to Upperline and is separate from the Deal Studio materials documented here.

The preserved 2025 application is documented here as historical work. I continue building and adapting software around operating, investment, research, analytical, and workflow problems; that continuing work does not imply that this application is a current product.

The tools changed as the questions changed: collecting an opportunity, comparing it with others, understanding a parcel, or retaining the work needed for the next decision.