We're building Keystone as an AI-native platform for real estate development — site boundary in, feasible masterplan out. None of that works without one unglamorous ingredient underneath it: a database that knows what you're actually allowed to build, city by city. This is a short, honest account of what happened when we tried to build that database across the US, because the failure modes turned out more instructive than the successes.
The number we started with was wrong
Early on, we estimated our US coverage gap at "roughly 800 cities, 300 covered." When we went back and checked it against the Census Bureau's July 2025 estimates, the real number for cities at the 100,000-population threshold — the segment that actually matters for mid/large developers — was 348 cities, with 128 already in our matrix (37%). The 800 figure was real, it just counted a different, wider population threshold (50,000+), not the one we meant. Small thing. But it's exactly the kind of error that compounds silently in a business plan if nobody goes back and checks the arithmetic against its source.
Scraping is not the hard part. Trusting the scrape is.
We built a pipeline to pull zoning ordinances from Municode, eCode360, and city-hosted PDFs — the standard places US municipal code lives. Getting the raw text isn't the bottleneck. Two batches (40 cities) went through source-capture, and only 2 of those 40 came back with clean, genuinely usable dimensional data: Aurora, CO and Long Beach, CA. The other 38 hit some combination of Cloudflare blocks, ordinance restructuring in progress, or tables that don't parse cleanly into rows and columns.
That 2-of-40 ratio isn't a tooling failure we're going to paper over. It's the actual base rate of "this data is structured enough to trust without a human reading the source page." Anyone building on scraped regulatory data should expect a number in that range, not a marketing number.
Some cities don't have an FSI/FAR at all
Aurora, Colorado's zoning code doesn't use a Floor Area Ratio concept for its residential districts — it regulates form through lot area, setbacks, height, and density instead, a completely different control logic than Long Beach, California, which does use FAR (0.60 to 3.0 across its 19 residential districts, Title 21, Table 31-2A). A matrix that assumes every jurisdiction speaks "FAR" will silently misrepresent every place that doesn't. We had to add a null case for "this jurisdiction doesn't work this way," instead of forcing a number where the underlying regulatory logic doesn't have one.
The rule that mattered most: null beats guessed
Long Beach's own table had six residential districts where the source PDF had column-alignment breaks — cells that don't line up cleanly after extraction — and range values with no stated selection rule (is the applicable number the low end, the high end, or does it depend on a condition stated elsewhere?). Every one of those cases got recorded as `null`, with the specific ambiguity written down next to it, instead of filled with our best guess.
That sounds like a small methodological choice. It isn't. A wrong FAR number that looks confident is worse than no number at all, because it gets trusted and used downstream — in our case, by a generation engine that sizes buildings against it. We'd rather our matrix say "unverified" on 210 of 348 cities than have false confidence on any of them.
Where this leaves us
As of this pass, verified coverage moved from 128 to 130 of 348 target cities — a small, honest increment, recomputed from the actual gap list rather than assumed. We also now have a documented procedure for the calculate-normalize-write step itself, because after weeks of scraping we found this step had never actually run for any batch in the program's history. Raw capture had been happening. Turning raw capture into a verified matrix entry hadn't.
We're writing this down not because the number is impressive yet. It's because the discipline behind the number — verify the scope claim, expect most of the scrape to fail cleanly rather than fail silently, treat "no data" as a valid answer, check that your pipeline's middle step is actually running — is the same discipline that has to hold when this same data feeds a masterplan someone will actually build from.
---
This is a founder-voice account of Keystone's own internal build process. Every figure above (348-city threshold, 128/130 coverage, the 2-of-40 batch outcome, Aurora and Long Beach specifics) is drawn from Keystone's own verified internal tracking, not a third-party source. No external market, regulatory, or competitor claims are made in this piece.