Zoning research is where architects lose a lot of time. Every new site means a new set of zoning documents to search through before design can even start. ZoningIQ cuts that process down to a conversation, giving architects fast answers in minutes, backed by the documents they already have.
Architects spend hours manually searching zoning codes and municipal websites for every new project, often across multiple documents for one jurisdiction. There's no single place to look up the answer, and no fast way to confirm it's right.
I designed and built ZoningIQ on my own, end to end, then tested it with a design team of four practicing architects to validate whether it actually solved the problem.
A practicing architect who needs to confirm zoning and code requirements before they can start designing. These codes change constantly, which is exactly why the research has to happen on every project. They need a fast, trustworthy answer so they can get back to the work that actually requires their judgment.
The first version of ZoningIQ returned answers as plain text. No references, no page numbers, no indication of where the answer came from. For most users that was fine. For the more experienced architects in the test group, it was a non-starter. They weren't going to stake a design decision on an answer they couldn't verify. The fix was to surface the source alongside every response — the document name, the section, and the exact language the answer was drawn from. That single change was the difference between a useful summary and a tool they could actually trust.
The early cost question was real: sending a full zoning document to the model on every query adds up. The decision was to keep it simple rather than build a complex search layer on top. ZoningIQ sends the uploaded document directly to the AI, which reads it in full and pulls the answer from the source material. No preprocessing. No index to maintain. The answer comes from the actual document, every time. The tradeoff is that reading a full document takes a moment longer than searching an index — which is exactly why streaming matters. The response starts arriving almost immediately, so the tool never feels frozen.
After testing, a pattern emerged: architects were asking the same categories of questions on every project. Setback requirements. Height limits. Permitted use by zone. The chat interface handled each question well in isolation, but it offered no way to run the same set of questions quickly across a new document. That gap is what a structured template workflow would close — a way to save a question set once and run it against any document, rather than rebuilding the conversation from scratch every time. This feature is currently being designed. The decision isn't whether to build it — usage made that clear. The decision is how structured to make it without adding friction to the tool's main strength, which is the speed of the open-ended question.
Everything in ZoningIQ is grounded in a specific document. Starting with the upload isn't a UX decision — it's what makes the answers trustworthy. When uploading, the architect gives each document a label — like "Parking Rules" or "Height Limits" — and that label follows every answer, the summary panel, and the final export automatically. The organization you set at upload is the organization you get back at the end.
The question input is intentionally open-ended. Architects ask in plain language — the same way they'd ask a colleague — and ZoningIQ pulls the answer from the document they uploaded. No dropdown menus, no form fields, no predefined query structure. The goal was to keep the cognitive load on the document, not on the interface.
The answer view shows the response and the source in the same place. Not just a document name — the specific section and the exact language the answer came from. That specificity is what changed the response from skeptical architects during testing. They weren't questioning the tool's speed. They were questioning whether they could stand behind the answer. The citation gave them something to point to.
As questions get answered, they collect automatically in a running summary panel on the side — organized by the document labels set at upload. Nothing gets lost in the scroll of a chat history. By the time the session is done, the summary is already built.
When the session is done, the architect exports a formatted Word document with every question, answer, and citation already organized by topic. Not a chat transcript — a structured document they can reference, share, or attach to a project file. That's the output ZoningIQ is working toward from the moment the first document is uploaded.
Every decision in ZoningIQ came back to the same problem: speed without trust is worthless in a professional context. The citation requirement, the retrieval redesign, the template workflow — each one was solving a different version of the same question. The citation made the answer defensible. The retrieval redesign made the tool viable at real volume without cutting corners on accuracy. The template work is about making the speed repeatable across projects, not just within one. None of these were polish decisions. They were what separated a demo from something a practicing architect would actually use on a job.
Testing with four architects taught me things I wouldn't have found on my own. The citation requirement didn't come from a design principle — it came from watching a skeptical architect pause and ask where the answer came from. That moment changed the entire output model. Working solo meant I had to make every call myself, which forced a level of clarity about what the tool actually needed to do. But it also meant the only real feedback loop was the testing sessions themselves. What I'd do differently is build that feedback in earlier, before the first version was finished, rather than treating it as a validation step at the end.
Built with Next.js, TypeScript, and the Claude API. Developed with Claude Code.