Confessions of a Recovering Real Estate Analyst
The team building Alpha Deal includes people who came from real estate before they came to software. That background shapes how we build — and it's one of the things that makes the technical problems we're working on genuinely hard in a way that's worth explaining.
What real estate analysis actually teaches you
Working as a real estate analyst in affordable housing development means spending a significant portion of your time doing things that software should be able to do better: researching subsidy program eligibility, reading zoning codes, modeling capital stacks in spreadsheets that grow increasingly fragile as deals get more complex.
It also means building deep pattern recognition about what makes deals work. Which site characteristics actually matter for feasibility at first pass. Which program combinations are worth pursuing versus which are theoretically possible but practically inaccessible. Where the gaps in a capital stack are likely to emerge before you've built the full model.
That pattern recognition is valuable. It's also extremely hard to transfer. It lives in people's heads and in their personal spreadsheet libraries and in the informal conversations they have with colleagues who've done similar deals. There's no structured representation of it that a junior analyst can access or that an organization can maintain as staff turns over.
The software problem we're working on is, in part, a knowledge representation problem: how do you encode the pattern recognition of an experienced affordable housing analyst in a form that's accessible to practitioners who haven't built it through years of deal experience?
The gap between analyst intuition and software precision
Here's a tension that shapes a lot of our product decisions: experienced analysts make feasibility assessments quickly, based on pattern recognition that's difficult to make explicit. Software requires explicit logic — rules, thresholds, calculated outputs.
When you try to translate analyst intuition into software, you discover that a lot of what "feels right" to an experienced practitioner is actually a set of implicit judgments that resist clean formalization. Is this market's income profile compatible with 60% AMI targeting? It depends on the specific tract, the unit mix, the recent allocation history in the state, and about a dozen other factors that interact in ways that aren't captured by a simple rule.
This doesn't mean the software can't be useful — it means the software has to be honest about what it knows and doesn't know. A system that produces confident-sounding outputs when the underlying signal is ambiguous isn't useful to practitioners who are going to make real decisions based on it. A system that surfaces the relevant factors and represents uncertainty clearly can actually help practitioners make better decisions than they'd make with raw data alone.
Getting this balance right — between useful signal and honest uncertainty — is one of the central product challenges we work on. It requires both technical judgment and domain knowledge, which is why the team members who've crossed between the two domains are disproportionately important to how we build.
The perspective that comes from having done the work
When you've been on the practitioner side — when you've spent hours assembling the inputs for a feasibility analysis, when you've discovered a program eligibility issue six weeks into evaluating a site, when you've had a capital stack fall apart because of a soft debt assumption that turned out to be wrong — you build software differently.
You're less impressed by elegant architecture that doesn't match how the work actually gets done. You're more focused on the question of whether the output is actually useful to someone making a real decision under real time pressure. You have more empathy for the user who's using the software while also doing three other things, on a deadline, with a deal that matters to them.
That perspective is useful on an engineering team. It doesn't mean we don't care about technical quality — we do. It means we care about technical quality in service of something real, not as an end in itself.
What this means for who we hire
We're looking for engineers who find this kind of problem interesting: technically hard, domain-specific, and connected to real-world outcomes that are visible and meaningful.
You don't need a real estate background to work here. The domain is learnable, and the engineers on the team who came from traditional software backgrounds have gotten up to speed. What helps is intellectual curiosity about the domain — a willingness to understand why the problem is hard before trying to simplify it, and an interest in building things that practitioners actually use rather than things that impress other engineers.
The real estate to software journey is not a common one. The problems that live at that intersection are correspondingly underexplored. We think that's where some of the most interesting software work in the next decade will happen.
We're building at the intersection of real estate expertise and software craft. If that intersection sounds interesting to you, we'd like to talk.