Custom Addresses

Roofr’s New Job flow always starts with an address. Previously relied on Google autocomplete to provide us with both the text address and the lat/lng location data, but when it can’t find the address then the flow breaks. Coverage is worst on new construction, rural sites, and incorrect addresses. The fix sat unsolved for years because reports require lat/lng, and a text-only fallback would let users create jobs that can’t order Roofr Reports.

Custom Addresses ships both halves: type the full address and also drop a pin to lock the coordinates. The sacred-data model keeps user input safe from automation. It’s also the first AI-created prototype at Roofr. Static Figma screens weren’t impressing stakeholders, so I built a basic interaction in HTML/CSS/JS with Claude Code, which was used to get approval. Afterwards I partnered with a backend developer to stand the same env up inside the real codebase. Design team onboarded to the same workflow afterward.

1. Address-entry friction at scale. 40% of surveyed users hit issues; 55.8% cite “address doesn’t show up” as the #1 complaint.
2. Direct revenue risk. Reports require coordinates. A text-only fallback would create jobs that can’t order reports.
3. Data integrity. Contractors were using fake addresses to get around the current limitation, corrupting downstream metrics and products.
4. Sales objection unblocked. “We can’t adopt Roofr until we can enter our new-construction addresses.”
5. Roofing CRM needs to support all addresses. It was extremely frustrating to our customers that we only supported addresses that were in Google’s Places API.

• Lat / lng non-negotiable. Reports need coordinates.
• Autocomplete stays the happy path. Fallback can’t add friction for the addresses Google still finds cleanly.
• Entity contract holds. Payload backwards-compatible.

The project ran as a progression of artifacts. Each one unblocked the next.

1. Static Figma mockup. Layout was right; the interaction questions stayed open.
2. PRD with Claude. Edge-case enumeration first to iron out the interaction pattern between text fields and pin dropping.
3. HTML/CSS/JS prototype with Claude Code. Leaflet, Nominatim, glass form panel, floating and anchored pin states. Built so stakeholders could feel the interaction. First AI-created prototype at Roofr.
4. Real-codebase env, BE-dev partnered. BE dev set up the foundation; I did all the FE styling and UX. Engineering team is building off of this.
5. V1-skip sign-off. Walked the C-suite, VP Engineering, and CRM PM Lead through the real-env build. Group chose the complete release over a text-only interim that would have broken the report funnel.
6. Design-team onboarding. Rolled the same Claude Code workflow out to the rest of the design team. The team’s been running it since and it’s become the de facto standard.

• Figma isn’t always enough. Static didn’t resolve the questions; a full Figma prototype was impractical. The call was recognizing that and moving to code.
• Prototype-in-code collapses the decision cycle. Debounce, pulse timing, modal-size animation, reverse-geocode latency. The real stack surfaces those early.
• Partner on the real codebase. The HTML prototype was a sales tool. The real-codebase env is the handoff artifact.
• Sacred-data is a contract, not a form pattern. Applies anywhere the system auto-fills or auto-corrects. The purple / normal language plus the “Auto” badge is portable across the product.
• AI workflow ≠ AI output. The model didn’t choose sacred-data, V1-skip, the BE partnership, or the team rollout. It accelerated edge-case enumeration, PRD drafting, and translating interaction into code.

In build. Q2 ‘26 rollout. KPIs below fill in as numbers land.