Why the Capital Stack Is a Software Problem
The capital stack is the financial architecture of a real estate deal. It describes, in layered form, every source of money that funds a development project — equity at the top, senior debt at the bottom, and a range of mezzanine, subordinate, and soft financing in between. Getting it right is the difference between a deal that closes and one that doesn't.
In affordable housing, capital stack construction is extraordinarily complex. A typical deal layers federal tax credit equity, tax-exempt bond proceeds, conventional construction and permanent debt, HOME funds, local housing trust fund soft loans, and sometimes state tax credits, historic tax credits, or opportunity zone equity — each with its own eligibility requirements, compliance obligations, sizing constraints, and interaction effects with every other layer.
This complexity is currently managed primarily in spreadsheets. We think that's a fundamental mismatch between the problem and the tool — and that the gap is large enough to be a significant software opportunity.
Why the capital stack is hard to model
The challenge isn't just that there are many financing sources. It's that the sources interact in ways that aren't linear or independent.
The amount of 9% LIHTC equity a deal can generate depends on eligible basis, which is affected by the presence of certain other financing sources. The debt service coverage a conventional lender will underwrite depends on the net operating income, which is shaped by the unit mix and AMI targeting, which in turn affect how much soft debt is needed to fill the remaining gap. Soft loan program terms — interest rates, deferral periods, forgiveness provisions — affect the deal's long-term cash flow profile in ways that change what a permanent lender will offer.
These interdependencies mean that changing one variable in the capital stack ripples through every other variable. Modeling a 9% LIHTC deal with three or four soft loan sources isn't a simple calculation — it's a system of interrelated constraints that needs to be solved simultaneously.
In a spreadsheet, this is done through a combination of hardcoded assumptions, circular references, and the analyst's implicit knowledge of which variables drive which others. It works, in the sense that experienced analysts produce valid capital stacks. It doesn't work in the sense that it's slow, fragile, hard to audit, and nearly impossible to reuse across deals without significant manual reconstruction.
The combinatorial problem
Most development teams approach capital stack modeling by selecting the financing sources they know well and modeling those. This is rational given the time constraints they operate under, but it systematically under-explores the space of possible structures.
The number of potentially applicable financing sources for a given affordable housing deal — depending on location, deal type, population served, and other factors — can be quite large. Modeling every plausible combination manually isn't feasible. But leaving combinations unexamined means deals that could have been structured more favorably, or that could have been feasible with a different structure, get passed over.
This is the combinatorial problem that software is well-suited to address: not replacing the judgment about which structure to pursue, but expanding the set of structures that get evaluated before that judgment is applied.
Why this hasn't been solved yet
The capital stack problem has resisted software solutions for reasons that are instructive about what a good solution requires.
Domain specificity is high. Building a capital stack model that's accurate requires deep knowledge of each financing program — not just its headline parameters but the nuances that affect how it interacts with other sources. That knowledge is hard to encode and changes as programs evolve.
The data is fragmented and dynamic. Program parameters — tax credit pricing, income limits, HOME allocation levels, local soft loan terms — change regularly and are maintained by different agencies with different update cycles. A capital stack model is only as good as the program data it's built on.
The users are experts. Affordable housing developers know when a model is wrong. A tool that produces plausible-looking but inaccurate outputs gets dismissed — and getting dismissed in this market is difficult to recover from. Accuracy isn't a nice-to-have; it's the baseline requirement for adoption.
These barriers are real. They're also the source of the defensibility of a well-built solution. The same characteristics that have kept the problem unsolved make it hard for a new entrant to replicate a solution that's been built carefully over time.
The engineering surface area
For engineers thinking about this problem, the interesting work lives at several layers:
Data infrastructure. Maintaining accurate, current representations of program parameters across dozens of financing sources and hundreds of jurisdictions is an ongoing data engineering challenge with no clean endpoint. It requires pipelines, quality checks, and update processes that are more complex than they sound.
Constraint modeling. Representing the interdependencies between financing sources in a form that's both computationally tractable and expressive enough to capture real-world nuance requires careful systems design. The naive approach — model every interaction explicitly — doesn't scale. The interesting work is in finding the right abstractions.
Scenario generation and comparison. Building interfaces that let practitioners explore multiple capital stack scenarios quickly — understanding what changes when you swap one financing source for another, or when you adjust AMI targeting — is a product and engineering challenge that requires both fast computation and careful UX design.
Uncertainty representation. Not every input to a capital stack model is known with precision. Tax credit pricing fluctuates. Soft loan availability is uncertain. Construction costs are estimates. A model that represents this uncertainty honestly — rather than presenting point estimates with false precision — is more useful to practitioners making real decisions, and harder to build correctly.
The capital stack is a software problem not because spreadsheets are bad tools, but because the problem has outgrown what spreadsheets can efficiently handle. The teams that solve it will have built something that sits at the center of how affordable housing deals get structured — which is a valuable and defensible position to occupy.
Alpha Deal is building the capital stack modeling infrastructure for affordable housing development — helping teams explore more structures, faster, with greater accuracy than spreadsheet-based approaches allow.