The System Has to Remember

For a few years, a large part of my real estate business lived on pieces of paper scattered across my desk.

I was buying distressed property in Texas. At the height of it, roughly 2,000 foreclosure notices came through my system every month. I had built ways to filter that universe down to forty or sixty properties worth investigating and a much smaller group I might actually pursue.

Then the real work started.

I would sit at my desk with a pen and a sheet of paper and construct the narrative of a deal. I searched public records, researched title, traced ownership, looked for liens and judgments, and tried to understand whatever complications had put the property in front of me.

I became particularly interested in heirship situations. They scared away some competition, and I developed a knack for reconstructing ownership from public records and the fragments families leave behind online.

The foreclosure auction was usually about two weeks away. By the time I picked up the phone, I wanted to understand the property, the foreclosure and the ownership story better than the person on the other end.

My pitch wasn't complicated.

Your property is going away in two weeks. I would like to make you a cash offer today. We will close before the auction.

I wanted to be the authority in the conversation. But I learned not to fall in love with my own narrative. Occasionally someone would tell me something that contradicted what I thought I knew. I would write it down, independently verify it and, once I understood what was true, change my offer or walk away.

If I pursued a deal, the piece of paper became the basis for a digital archive.

If I passed, I threw it away.

That worked until a foreclosure was postponed and the same property appeared again six months later.

I've looked at this before.

But I couldn't always remember what I had learned. Worse, I couldn't remember what I had thought about what I had learned.

I had preserved the deals I bought and discarded most of the work that had taught me why not to buy the others.

The repeated work annoyed me. Losing my earlier judgment bothered me more.

I needed the system to remember.

I had been developing versions of that discipline long before I started buying real estate.

I joined my father's medical practice in 2010 after studying finance at Tulane. The place was full of manual processes that seemed crazy to me.

Someone could spend much of a day searching queries in Google and recording search-result positions so we could compare them quarter to quarter. Billing had to be manually checked to make sure payments had been entered and applied correctly. Patients filled out demographic and consent forms on paper, employees entered the information into the practice-management system, and then someone had to check that the data entry had actually occurred.

Human beings were constantly moving information between systems and then checking whether other human beings had moved it correctly.

I taught myself SQL.

At first, the important thing SQL gave me wasn't automation. It was visibility.

I could audit billing, scheduling, quoting and lead follow-up. I could ask the database whether the processes we had designed were actually being followed. When they weren't, I could identify the problem, correct behavior and gradually clean up the systems of record.

That taught me an early lesson: a database isn't true merely because the records are in it.

If the process creating the data is bad, a better query just gives you a clearer picture of bad data.

Eventually I wanted to move upstream.

Instead of auditing whether an employee had correctly transferred information from a patient's paper forms into the practice-management system, why should the employee have to re-enter it at all?

Around 2016, I started building a system we called BIVI with Philippe Bibi.

Philippe gave me a high-level map of the territory, and then we learned feverishly. We watched Venkat's ASP.NET material on YouTube. We read books. I consumed what felt like every MIT OpenCourseWare computer-science lecture I could find.

And there was Stack Overflow.

Software development was a bitch back then.

You could spend hours comparing proposed solutions to a problem, choose one, finally get it working and discover you had created a hundred new problems. Then you went back into the documentation, books and Stack Overflow and tried again.

I wouldn't choose to go back. But the friction created discipline.

Philippe and I worked on BIVI for months. We QA-tested it up the wazoo before we trusted it in production.

Eventually a new patient could complete paperwork digitally. The information mapped into the practice-management system and the completed documents were linked to the patient's files. Employee hours disappeared from the process, and with them went a meaningful source of human error.

Watching it finally run in production was beautiful.

We thought the opportunity for BIVI was enormous if we could keep widening its scope.

The problem was how slowly we could build.

When I left the practice and began investing in distressed real estate in 2020, I took the same instincts with me.

My first several foreclosure purchases taught me that being able to buy something quickly wasn't particularly useful if I couldn't sell it quickly.

Redemption periods, title issues and other complications created roadblock after roadblock. I could deploy capital efficiently and then discover that I had bought an asset I couldn't efficiently move.

I began thinking less about the profit on an individual property and more about the velocity of the money moving through the practice.

Nothing teaches a lesson in grit like getting punched in the nose.

I bought things I couldn't sell. I got sued. Sometimes my idea of what a property was worth and what somebody would actually pay for it turned out to be two different things.

Eventually I started asking whether I could move some of the difficult work to before I owned the property.

My first pre-foreclosure purchase was two adjacent lots down on Matagorda Bay in Sargent, Texas. I closed through a title company, hired an agent and roughly doubled my money in about a month.

The money was nice.

The process was more important.

Closing through title gave me much stronger confidence in marketable title on the sell side. Instead of treating foreclosure as the place where I had to buy the property, I could treat the approaching foreclosure as the signal that brought an opportunity to my attention.

I had figured out how to buy fast.

Now I needed to figure out how to sell fast.

Over time, I developed a practice around finding situations where I believed the complexity was solvable. I got better through repetition, pattern recognition and failure.

I eventually took on a partner who brought capital and private-lending relationships while I continued sourcing opportunities. That allowed us to spread capital across more opportunities and move more quickly.

Over five years, I completed dozens of transactions on the buy and sell sides.

But most of the work still ended with the word no.

The deals I didn't do contained much of the learning that made me better at the deals I did.

The system shouldn't just preserve transactions.

It should preserve learning.

Later, when I moved into commercial investment and development at Upperline Companies, I carried those instincts with me.

Almost everything else was different.

In distressed investing, the foreclosure process gave me a signal and a deadline. In commercial real estate, sellers often had no obvious reason to sell at all.

The data was different too.

I had started Deal Studio with the idea that I could ETL multiple sources into my own environment. Then I discovered how little useful commercial information was actually published.

Sometimes I had to call or email a broker just to get an asking price. And the broker might not respond unless they believed I represented a bona fide buyer.

It took me a few cycles to get used to that.

So my data-acquisition strategy started including coffee. Lunch. Pickleball. Conferences. ULI. Bisnow. I leaned on the résumés and relationships of the people around me and developed my own.

I also discovered something I loved about commercial real estate: teamwork.

We could sit with architects, civil engineers and landscape designers and imagine an entirely different future for a piece of land. Brokers understood markets. Lawyers saw risks. Bankers understood capital. Analysts tested assumptions.

I loved collaborating with people who were exceptional at specialties I wasn't.

But all of that expertise created another information problem.

It was siloed.

The architect knew one thing. The civil engineer knew another. The broker had another piece. Someone had the current underwriting. Somebody else had an older assumption.

Making a decision could turn into a telephone game.

On one land acquisition, our feasibility exercise took too long. While we were still assembling the information we needed to decide whether the site worked, another buyer took the property.

That one hurt.

A good investment decision made after the opportunity is gone has no value.

Our team already knew how to underwrite these opportunities. That expertise lived in the people doing the work and in increasingly sophisticated Excel models.

What bothered me was how little permanence the intelligence had between deals.

We could spend weeks learning a submarket, testing rents, tenant-improvement allowances, sale comps, construction costs, population growth, household incomes, home values, job growth, traffic counts and proposed road projects—and then begin much of that learning again on the next opportunity.

I started working on ways to systematize the underwriting process.

Not to replace the judgment behind it.

To give that judgment a better starting point.

If we had already paid to learn something, why should the next deal start from zero?

Capital should compound.

Knowledge should too.

Artificial intelligence entered this story gradually.

Deal Studio was the first project where I realized how much ChatGPT could augment my ability to code.

It pushed me into a pile of firsts: new languages, frameworks, databases and deployment tools. Things that once would have sent me into documentation and Stack Overflow for days became tractable much more quickly.

The cost of crossing a technical boundary had collapsed.

That was a revelation, but I was still fundamentally using AI to help me code.

Then, in July 2026, I built Meridian.

Meridian changed the way I built.

I started using Codex agentically. Instead of treating AI as something that could answer a programming question or help write a function, I began developing a workflow around architecture, bounded implementation, testing, evidence and review.

While writing this essay, I became curious whether that story was actually true or whether I had constructed a cleaner retrospective narrative than the record justified.

So I did what I have learned to do with any narrative I care about.

I tried to prove myself wrong.

I asked Codex to go through the Git histories of Meridian, Upperline and the system I am building today and reconstruct how my engineering practice had actually changed.

It corrected me.

The chronology was messier than I remembered. Meridian itself didn't begin with the mature engineering process I associated with it. That process emerged inside the project. Some architecture had been documented retrospectively. Some supposedly complete work explicitly excluded live production acceptance. Documentation occasionally contradicted other documentation.

But the larger change was there.

More decisions were becoming durable before implementation. More constraints were explicit. More definitions of correctness were moving into tests and enforcement. Documentation increasingly existed not merely to describe what had been built, but to constrain what could be built next.

Someone tells me he's an heir.

Write it down. Verify it.

A broker gives me a rent.

Useful. Not necessarily authoritative.

An AI extracts a fact from a document.

Candidate, not truth.

Codex tells me an implementation is complete.

Show me.

The tools have changed.

The instinct hasn't.

Today I use ChatGPT as part of the architectural and review process. We explore a problem, challenge assumptions, define domains and establish constraints.

Codex then interrogates those ideas against the actual repository. It tells me where the architecture collides with reality. We iterate. Once the idea survives that process, Codex can act as the engineer and implement it.

Then the work comes back for review.

Did it satisfy the intent? What evidence supports that? What did it change that it wasn't supposed to change? What remains unverified?

If the answer isn't good enough, it goes back.

That process has made documentation vastly more important to me.

Not because I suddenly became a person who loves writing documentation.

Because context has to survive.

From me to ChatGPT. From architecture to Codex. From implementation back to review. From one session to another and from one part of a large system to another.

Documentation became part of the machinery.

AI didn't teach me the discipline.

It removed a constraint on how completely I could express it.

I am now back at my father's practice.

In some ways, I am working on the same problem Philippe and I were trying to solve with BIVI ten years ago.

In one important way, I'm not.

BIVI was designed to augment the practice-management system. The incumbent system remained the center of gravity. We built better tools around it.

This time, I am not trying to augment it.

I am replacing it.

The first obligation isn't to invent a beautiful new version of how a medical practice should operate. It is to understand and preserve the patient journeys that already exist.

Appointments. Consultations. Quotes. Cases. Payments. Financial history. Permissions. The strange edge cases accumulated over years of actual use.

I want to reconstruct that reality faithfully before I start changing it.

Then I want to go wide and deep.

Patient self-service. Imaging. Payments. Prescriptions. AI-enabled workflows. The pieces that today live in different systems or depend on people carrying information between them.

Ten years ago, Philippe and I believed BIVI could become something much larger if we could keep widening its scope.

We just couldn't build fast enough.

This time, I can.

But that isn't really why I came back.

When I worked for my father the first time, I struggled with owning my success.

The practice grew dramatically during those years, but it was still my father's practice. There was always a question in my mind about what was mine.

So I went out into the world.

I got my answer.

I succeeded on my own. I failed on my own too.

I bought properties I couldn't sell. I got sued. I made bad calls and good ones. I learned how to find opportunities, put capital at risk, work with partners, borrow money, negotiate, build systems, lose deals and keep moving.

I learned that being wrong doesn't make the next decision for you.

You still have to make it.

My father has been incredibly supportive through the good years and the hard ones.

Now he is entering the final era of his practice.

And I find myself back where I started, with something I couldn't have brought with me the first time.

Not just better software tools.

Everything that happened after I left.

I can see an opportunity to change the trajectory of his business once more. To take the practice that first gave me somewhere to learn, preserve what it has learned over decades, and give it a new operating system for whatever comes next.

I don't need it to answer whether I can make something of my own anymore.

I already went out and answered that.

This one is a thank you.

Then I'll move on to the next problem.