2026
Buildable
An ADU feasibility check for Bend homeowners: is it allowed, and does it fit, before anyone pays for drawings.
Role
Product owner, designer, researcher
Timeline
MVP spring 2026 → four-week sprint July 2026
Built with
Next.js, Supabase, City + County ArcGIS open data
Status
Live prototype, recruiting beta users
TL;DR Zoning tells a homeowner whether ADUs are allowed in their neighborhood. It doesn't tell them whether one fits on their lot, which is the question they usually pay a designer to answer. Buildable draws the parcel, insets the setbacks, and lets the owner place one of the City's pre-approved plans in what's left.
Why This Problem
I've worked alongside Bend's Community Development Department for years, and in 2024 my team and I partnered with their staff to write the City's first end-to-end guide to how a permit actually works. Stakeholder workshops, an on-site feedback tool, and a community survey all surfaced the same two questions: how do I apply? and where do I find the information?
Nobody asked can I build this here? Looking back, that was because the site couldn't answer it. By the time people arrived, they had either settled that question somewhere else or didn't know it could be answered at all, and we never thought to ask about something we had no way to offer.
When I started researching ADU permitting for Buildable, guidance from Oregon’s Department of Land Conservation and Development and research from UC Berkeley’s Terner Center for Housing Innovation clarified the question we’d missed: the gap between what’s legally allowed and what’s practically feasible. Owners can commit money to design before validating site, utility, regulatory, and financing assumptions—only to discover a fatal constraint after paying for drawings. My conclusion was that these risks should be consolidated into a single parcel-feasibility report delivered before design begins. Buildable is a first pass at that.
The First Version:
Wrong with Confidence
I scoped and built the initial MVP during a single session in the spring of 2026 using an agent-assisted workflow. That session produced a working app with the right bones: address-first entry, deterministic data separated from AI explanation, and a clear result.
It was also wrong.
Soon after I built the MVP, I put it in front of a few users and found that the app was returning confident, fully consistent results…but for the neighbor’s property.
Rather than using a real point, the geocoder estimated a position along the street from the house number, and when that estimate landed outside the parcel, a fallback picked whichever parcel was nearest. This clearly needed to be tightened up.
Buildable, however, had the problem every side project has: no deadline and no audience, so I joined a four-week accountability sprint (Design Garden, summer 2026) with a public showcase as the finish line.
I went in planning to simply fix the address mismatch, but the solution turned out to be easier and cleaner than expected: I was able to leverage the City's own address-point layer. And by adding a typeahead, the common path never estimates at all. Which left most of a four-week sprint and a much larger question: what should the product actually answer?
Key Decisions
A gated four-step flow.
Property → Feasibility → Placement → Permit plan. The first version put everything on one scrolling page. Adding placement meant the interface had to carry much more without burying the homeowner in questions. Now each step unlocks only when the previous answer is settled.
Pre-approved plans as the starting point.
Bend licenses plans already reviewed against building code, which shortens approval time and lowers fees. The first version never mentioned them. Now each one is a dimensioned footprint the homeowner can try on their own lot. The City's guidance says these plans are still reviewed for setbacks and lot coverage. The plan settles the building; Buildable answers setbacks, and lot coverage is next.
An interactive site plan.
Drag and rotate a plan inside the buildable envelope with a live fit readout. Instead of picturing what a list of setback distances leaves behind, the homeowner sees their usable yard and learns right away whether their plan fits.
Keeping a High-Stakes Answer Accurate
The dangerous failure here isn't a crash. It's a confident wrong answer that someone spends money on. I wrote no code by hand; Claude Code did the implementation while I scoped, decided, and reviewed. So I built the process around one rule: nothing reaches a homeowner that I haven't verified.
One authoritative source for every regulatory value.
I read each value in the code myself and dated it. No AI supplies a number, and there's no AI in the result a homeowner sees.
Thinking separated from doing.
me
One agent for scoping and decisions; Claude Code as the only thing allowed to touch code, one prompt at a time. I relayed every change by hand, so each one passed a review gate.
Rules in the repo, not the chat.
The coding agent reads its operating rules at the start of every session. Protected files are never touched without being named.
Two independent logs.
A decision log and a technical log, with the technical log winning on facts. Thirty sessions in, any decision's reasoning can still be recovered.
What it Doesn't Check (Yet)
Easements, utility capacity, slope, overlay districts, and lot coverage. Results are currently presented as a screening, not a determination.
Up Next
Near term: overlays, lot coverage, a custom-dimensions path, and an export for pre-application meetings. The placement engine doesn't care what it places, and the pre-approved plans also qualify for cottage clusters and middle housing, so extending there is mostly a matter of adding rules, not rebuilding.