What We've Learned from the Deals That Broke Our Product
Every software product has edge cases that reveal assumptions the team didn't know it was making. Most software handles these by logging an error and moving on. When our product breaks on a real affordable housing deal, a practitioner trying to make a real decision gets wrong information — or no information — at a moment when they needed it.
The deals that have broken our product have taught us more about what we're actually building than the deals that worked as expected. Here's what we've learned.
The zoning code that didn't match the database
Early in our deployment with one of our design partners, a site evaluation came back with a density assessment that the analyst immediately knew was wrong. The zoning code in our database reflected a prior version of the city's ordinance — a significant upzoning had been adopted six months earlier and hadn't propagated to the public databases we were using.
The analyst knew the current zoning because she worked in that market every day. If she hadn't caught it, the density assessment would have informed a go/no-go decision that was based on outdated information.
What we learned: zoning data freshness isn't just a data quality problem — it's a trust problem. A system that surfaces authoritative-looking information that turns out to be stale is worse than a system that's explicit about the uncertainty. We changed how we represent data currency: we now show when data was last verified and flag when a jurisdiction has enacted known reforms that may not yet be reflected in our database. We'd rather show uncertainty than false confidence.
The capital stack that couldn't handle the deal structure
A deal came through with an unusual structure: a ground lease from a municipality combined with low-income housing tax credits, historic tax credits, and a CDFI loan with nonstandard terms. Our capital stack modeling handled each component individually but didn't correctly model the interaction between the ground lease structure and eligible basis for the tax credit calculations.
The model produced a capital stack that looked viable but overstated equity by about 15%. A developer who built a deal around that number would have discovered the error when an investor's underwriting came back differently.
What we learned: the edge cases in capital stack modeling aren't edge cases — they're where the most interesting deals live. Unusual deal structures are often the ones that most need accurate modeling, because they're the ones where practitioner intuition has fewer comparables to check against. We've significantly expanded our capital stack modeling to handle complex structures, and we now flag explicitly when a deal structure involves interactions our model hasn't been validated against.
The market where our program data was incomplete
A design partner in a smaller state evaluated several sites using our platform and flagged that we were missing a significant state-level soft loan program that was actively deployed in their market. The program wasn't in our database. The deals they were evaluating looked like they had larger gaps than they actually did.
What we learned: our program database coverage isn't uniform. In major LIHTC markets we have strong coverage; in smaller states and markets we have gaps that matter for the teams working there. We've added a mechanism for practitioners to flag missing programs — which serves both as a data quality improvement loop and as a signal about which markets we need to prioritize for deeper coverage.
The pattern across all of them
Every deal that has broken our product has broken it at the same place: the gap between general rules and local specifics. The general rules — how LIHTC equity is calculated, how debt service coverage works, how QAP scoring criteria apply — we model well. The local specifics — this jurisdiction's current zoning, this state's specific program terms, this market's actual credit pricing — are where we've failed.
The lesson we keep relearning is that affordable housing development is irreducibly local. A product that works well in three markets and breaks in a fourth isn't doing its job. The path to a more robust product runs through more market coverage, better data freshness, and more explicit handling of uncertainty — not through better modeling of the general rules we already handle well.
We're building more honest software for practitioners who need accurate information to make real decisions. If the challenges described here are interesting to you, we'd like to talk.