Abstracting the Chaos: How We Translate Thousands of Pages of Zoning Code Into a UI a 22-Year-Old Analyst Can Understand
Zoning codes are among the most information-dense, inconsistently structured, and widely misunderstood documents in American public life. They're written in legal language, organized according to no standard taxonomy, updated on irregular schedules, and interpreted with significant discretion by local planning departments that don't always agree with each other.
They're also the regulatory foundation for most of what we build. Which means that turning thousands of pages of zoning code into a UI that a 22-year-old analyst can use without a planning degree is one of the defining technical and design challenges of the Alpha Deal product.
The abstraction problem
Abstracting zoning code is a multi-layered problem. The layers:
Data extraction. Zoning ordinances are published in a wide variety of formats — some as structured databases, many as PDFs, some as scanned paper documents that have been digitized with varying accuracy. Getting from the source document to a machine-readable representation of the relevant parameters is messy and inconsistent across jurisdictions.
Schema normalization. Even once the data is extracted, it doesn't conform to a standard schema. One jurisdiction expresses density as units per acre. Another uses floor-area ratio. A third uses a maximum building height in feet combined with a daylight plane requirement that effectively limits FAR without stating it explicitly. Normalizing these representations into a consistent schema — so that a site in Phoenix and a site in Boston can be evaluated against the same interface — requires both technical work and domain judgment.
Interpretation under ambiguity. Zoning codes frequently don't answer the specific question a developer needs answered. They specify setbacks from the street but not how the municipality interprets an irregular parcel boundary in that calculation. They specify height limits but not whether mechanical equipment on the roof counts toward the limit. Interpreting code provisions in the presence of genuine ambiguity requires judgment that a deterministic system can't fully provide — which means the software has to be honest about the limits of what it knows.
Update maintenance. Zoning is not static. Municipalities amend their codes regularly, sometimes substantially. A database of zoning parameters that was accurate six months ago may not be accurate today. Maintaining freshness across thousands of jurisdictions is an ongoing operational problem, not a one-time engineering effort.
Where UX becomes a technical problem
The UX challenge isn't just making zoning information accessible. It's translating regulatory complexity into something that's actionable without being misleading.
A 22-year-old analyst evaluating their second affordable housing site doesn't need to understand the full complexity of a zoning ordinance. They need to know: can we build the unit count this deal requires on this parcel? If not, what would need to change?
Getting from raw zoning data to an interface that answers that question accurately — without hiding the uncertainty that exists in the underlying data or the interpretation — requires making choices about what to show and what to abstract away. Those choices have real consequences: abstract too much and you create false confidence; show too much and you overwhelm users who can't navigate the complexity.
The design principles we've landed on: show the output the user needs to make a decision, surface the specific factors that drove that output, and flag explicitly when the confidence in the underlying data is limited. Don't hide the complexity — structure it.
Consumer grade is not a shortcut
"Consumer grade UX in a professional tool" is a phrase that gets used loosely in enterprise software. What it usually means is: clean visual design, fast load times, intuitive navigation.
What it actually requires, in a domain as complex as affordable housing development, is something more demanding: a product that respects the practitioner's expertise while reducing the surface area they have to actively manage. This is different from making things simple. It's about making things legible — organizing complexity in a way that matches how an expert thinks, not in a way that removes the complexity the expert needs to see.
Building this for affordable housing development means understanding how practitioners actually use zoning information in the context of a feasibility decision. It means knowing what level of precision matters and what's just noise. It means designing interfaces that work for the fifth time a user sees them, not just the first.
That's a harder design problem than most consumer software faces — and an interesting one for designers and engineers who care about the difference.
What we're building toward
The zoning abstraction problem is not fully solved. Our current approach handles the most common zoning structures well, handles a wider range of cases adequately, and has documented gaps where the underlying data is thin or the interpretation is genuinely ambiguous.
We have a clear view of where the product needs to go from here and a realistic sense of how long it will take. If you're interested in working on a technical problem that's harder than it looks — that sits at the intersection of data infrastructure, domain complexity, and product craft — we'd like to talk.
We're building infrastructure that makes zoning code legible for practitioners making real decisions. If this kind of problem is interesting to you, reach out.