Relay
Permit intelligence for the field.
Product & Design · Systems Design · AI Development
Construction projects stall waiting for permit updates. Relay tracks permit activity and gets the right information to the field before delays happen.
The problem
Permit work is coordination work. A permit goes off track on a missing document, an inspector question, a city backlog, and suddenly you're calling the architect, calling the GC, calling the engineer, calling the city. Everyone has a piece of the picture. Nobody has all of it.
Meanwhile, stakeholders want status. Not next week. Right now, while you're already on the phone with someone else.
The problem isn't that permit information is hard to find. It's that most of it never makes it into any system at all. It lives in voicemails, text threads, and the memory of whoever last talked to the city. The moment that person is unavailable, the record disappears with them.
The insight
The first version of Relay was a CRM. A better way to track permit activity, log updates, manage the moving parts. That would have been useful.
But working through the actual problem surfaced a different question: what if the system could answer status questions instead of me? Not pull from a database of structured entries, but synthesize everything that had happened, including the offline activity, and give a confident answer in plain language.
That reframe changed what the product needed to be. Not a place to log work. A system that captures work as it happens and makes it permanently queryable.
The design challenge
Getting offline activity into the system was the hard part. Construction communication doesn't happen in portals or project management tools. It happens in text messages, forwarded emails, and phone call summaries typed on the way back to the office.
Relay is designed to meet that communication where it lives. Field texts, forwarded city emails, voice notes: whatever the format, it gets ingested, synthesized, and written into a permanent record. The user just communicates. The intelligence happens behind the scenes.
The UI is one surface of that system. The more interesting design problem was what sits underneath it.
Design principles
Every update is an immutable timestamped record. Nothing edited, nothing deleted. Permits live and die by their paper trail. The audit trail isn't a feature. It's the product.
A PM on a job site needs one answer in ten seconds, not a weekly review screen. Relay centers interaction around natural language: ask a question, get a synthesized answer drawn from the full permit history.
Optimizing for the field changes the information hierarchy. The critical signal: what's blocked, who has the ball, what happens next. Everything else is secondary.
The build
This is a moment when wrapping AI around a problem is easy. Knowing which problem to solve, in what order, with what constraints requires something the technology can't supply on its own. Domain knowledge is the differentiator.
Relay's synthesis layer isn't a general-purpose AI wrapper. It's an opinionated system with structure baked in. The output format is fixed by design: status, blocker, next action. Not because those are the only useful questions, but because those are the questions that matter on a job site every time without exception. That consistency is what makes the system trustworthy. That trustworthiness is what makes it usable in a regulated environment.
Every query Claude receives includes the full permit history, not just the latest entry. Context is what makes the system understand a situation rather than just respond to it. Combined with append-only architecture, it doesn't just answer questions. It maintains a reliable account of everything that happened and when.
Stack: Next.js, Supabase, Tailwind, Anthropic API, Vercel. The infrastructure is standard. The interesting engineering is in the synthesis layer and what it knows about permits specifically.
