Turning Real Estate Work Into Software

Spencer Harkness and I have been friends since college. We had previously worked together on RealROI, and we had already been sharing an office for more than a year before Upperline was formed and before I formally joined the company. Upperline was founded by Spencer; for me, joining was a continuation of a working relationship that was already well established.

I formally joined as VP, Acquisitions & Operations and worked at Upperline during 2025–2026. My responsibilities spanned new acquisition business development, market expansion, investor relations, and strategic systems operations. In practice, that meant analyzing market trends, identifying prospective markets, originating acquisition opportunities, and working through underwriting, due diligence, and acquisition efforts.

The software followed from that work. An assumption I was using in an underwriting model was also something I needed to investigate during diligence. Information going into a deal presentation needed to stay connected to the analysis behind it. As I worked through those problems, I increasingly built software around them. The acquisition and operating work gave me the questions to ask and a way to judge whether the software made sense.

The platform developed from company and contact infrastructure into software supporting deal presentation and investor workflows. CRM and communication activity became part of that broader operating context, alongside acquisition screening and underwriting.

I came to see these as parts of the same working process. The contact, the opportunity, the presentation, and the underwriting model needed to stay connected. Thinking through those connections became as much a part of the work as deciding what belonged on a screen.

Underwriting brought that into focus. I wanted to be able to follow the economics from the assumptions to the result, without having to untangle the application around them.

I built a deterministic retail-development underwriting engine in TypeScript. Its calculation logic was deliberately independent from React, Next.js, HTTP, users, and databases. Given the same assumptions and calculation policy, the engine was designed to produce the same results without depending on the state of the application around it.

The model connected development geometry and capacity to tenant economics and development costs. It carried those assumptions through a timeline, construction financing, and lease-up, then into sources and uses, stabilized net operating income (NOI), disposition, and returns. Sensitivities and diagnostics provided ways to examine how the model behaved as assumptions changed and where its outputs needed attention.

The important architectural choice was the boundary around that calculation. A user interface could collect assumptions and present results, while the engine remained responsible for the economic model. A database could store a version without becoming the place where the calculation was defined. Neither a page render nor a network request needed to be part of reasoning about the arithmetic.

That separation made calculations testable and reproducible independently of the interface. It allowed a set of assumptions to be examined as a calculation problem, with an expected result, rather than requiring the whole application to be running before the result could be understood. It also made the distinction between a changed assumption, a changed calculation policy, and a display issue easier to reason about.

Determinism has a precise and limited value here. Reproducing a result does not establish that the assumptions are sound or that an investment should proceed. It provides a stable basis for examining how those assumptions become economics. The investment judgment still sits with the people reviewing the opportunity.

A reproducible calculation also needs a record of what was calculated. The system developed versioned underwriting persistence so that historical versions could retain their assumptions and economics as the work continued.

Revision-aware saves accounted for the version being edited. Stable tenant identities kept a tenant connected across revisions, while preservation of calculation policy retained the basis on which a historical result had been produced. Together, these concepts made a saved underwriting more than a collection of the latest field values.

Finalized historical economics were protected. When assumptions changed, stale calculations were cleared so that an earlier result would not remain attached to a newly edited set of inputs. The distinction mattered: a result belongs to the assumptions and policy that produced it.

“Final” represented a preserved historical snapshot. It did not necessarily mean financial approval, and it did not claim that every assumption was correct. Its purpose was to retain a particular state of the analysis so that later work did not silently rewrite the earlier record.

Later, I worked on a problem familiar from reviewing real estate documents: finding a number is only the beginning of understanding it. Take a hypothetical broker document from which software extracts “$32/SF.” That does not establish that market rent is $32/SF. It means a particular source appears to contain that value. I would still want to know what the number referred to and review it in context before relying on it.

That distinction shaped the document work. An uploaded source became a verified artifact; an extraction produced a candidate for human review, then an observation with a durable record of its provenance. Having a document, extracting a value, reviewing it, and deciding the system could treat it as authoritative were separate steps. Machine extraction was not treated as truth.

For me, the useful record had to preserve the connection to the source and the review behind the value. That is why provenance mattered: someone coming back to the information needed to be able to understand what supported it. Human review was its own act of checking the extraction against the source and its context. Evidence and inference needed to remain distinguishable.

At the reviewed handoff, downstream comparable search, recommendations, and automatic application of Property Intelligence to underwriting were not completed product capabilities. My work here explored how information from documents could become dependable enough to use; those further steps remained unfinished.

Looking back, building the software made me look more closely at the work itself. Real estate work supplied the questions; software required me to define what an assumption meant, which calculation used it, what a saved version preserved, and when information was ready to be relied upon.

Those are the habits I carry forward: being able to follow a calculation, return to an earlier analysis, and understand what supports a piece of information.

Spencer and I continue to have a good relationship after my departure from Upperline. Our friendship and work together began well before the company, and I think of this period as part of that longer history. It also changed how I approach software: I now pay closer attention to the questions that only become clear when you are doing the work.