The Architecture of Scale: How We Are Building a Platform Designed to Handle the Entire Affordable Housing Pipeline
Building a platform for affordable housing development means building for a domain that is, by design, locally specific, regulatory complex, and resistant to standardization. Every market has its own program landscape. Every state has its own QAP. Every jurisdiction has its own zoning logic. Every deal is, in some meaningful sense, a custom financing structure.
This is not an easy problem to build a platform around. It's also, for the right kind of engineer, an unusually interesting one.
What "platform" means in this context
We use "platform" deliberately. Alpha Deal isn't being built as a collection of point solutions — a feasibility calculator here, a program lookup there. It's being built as an integrated system that can hold the full pre-development workflow: site evaluation, program eligibility assessment, capital stack modeling, pipeline tracking, and the data infrastructure that connects all of it.
That architectural ambition creates real engineering challenges. Here are a few that are shaping how we build:
Multi-jurisdiction regulatory modeling. Zoning parameters, income limits, program eligibility rules, and subsidy program terms vary by geography in ways that don't conform to a clean data model. Building a system that represents this variation accurately — and that can be updated as regulations change — requires careful data modeling decisions that we're still evolving. We haven't fully solved this problem. We have a working approach and a clear view of where it breaks.
Capital stack computation. Modeling the interaction between multiple subsidy programs — how they stack, what they produce, what compliance requirements they impose on each other — is a computational problem with a combinatorial character. The naive approach (evaluate all combinations explicitly) doesn't scale. We've developed heuristics that work well for common structures; the edge cases are where it gets interesting.
Data quality and freshness. The raw inputs our system depends on — parcel data, zoning records, income limit publications, program parameters — come from sources with inconsistent update cycles and variable quality. Building infrastructure that maintains data freshness across dozens of sources, surfaces data quality issues, and degrades gracefully when inputs are missing is ongoing work with no clean endpoint.
Practitioner-grade performance. Our users make real decisions with real stakes. A system that's slow, unreliable, or opaque about its limitations doesn't get used — regardless of how good the underlying analysis is. Performance and reliability requirements in this context aren't just engineering table stakes; they're core to whether the product earns the trust of practitioners who could do this work without us.
How we build
We ship fast. Not recklessly — the domain demands accuracy that carelessness would undermine — but with a genuine preference for learning from real usage over extended internal iteration. Our design partners are active affordable housing developers who use the product on real sites. Feedback cycles are short by design.
The engineering team is small, which means high ownership of significant systems. If you build something, you own it — the architecture decisions, the edge cases, the ongoing maintenance, and the relationship with the users who depend on it. This is a real trade-off. It also means that what you build actually matters to how the company evolves.
We don't have a separate platform team and a separate product team and a separate data team. We have engineers who build across those dimensions because the work doesn't separate cleanly. If you thrive in that kind of environment — where the scope of what you're responsible for is broad and the organizational context is lean — this is a good fit.
What we're looking for
We're looking for engineers who care about the quality of what they build, not just that it ships. Who find the technical problems described here genuinely interesting. Who want to work on something where the output is real — where the software affects decisions that affect real housing outcomes.
We're also looking for engineers who are honest about what they don't know. Affordable housing development is a complex domain. We don't expect engineers to arrive knowing it. We do expect them to approach it with the same rigor and curiosity they'd bring to any hard technical problem.
The physical world connection isn't a branding choice. The deals that get evaluated in our platform turn into buildings that turn into homes. That's a longer chain of causality than most software produces. For engineers who find that meaningful — not as a primary motivation, but as a real one — it changes how the work feels.
We're hiring engineers who want to build serious software for a domain that matters. If the architecture problems described here are interesting to you, we'd like to talk.