Piná, AI for Urban-Code Compliance
My role: Founder, designer, builder. Research, brand, frontend, backend, pipeline orchestration. Live at: pina.mygoll.com. Status: Self-service launched April 2026 (Block 1-4: intake, report, validation, payment). Building in public.
A solo-built product that reads a building project, cross-references it against municipal urban code, and tells the user whether the design will pass, before the city hall says no.
Live in production, with real users testing on real projects. Honest about what the LLM can and can't do, the design exists to protect users from probabilistic outputs in a domain where being wrong has real consequences.
Context
Urban-code compliance is the gate between an architect or builder and the municipal approval that lets them break ground. It's a high-friction process: every municipality has its own code (zoning rules, building heights, setbacks, lot occupancy, parking requirements, FAR/floor-area-ratio), updated frequently, written in legal Portuguese, and rarely consolidated in a single source.
Architects iterate projects 3-5 times before they're willing to submit. Each iteration is expensive in time. Each rejection is more expensive, sometimes weeks of rework.
Piná is the triage that happens before the architect goes to the city hall. In Brazil specifically, ~90% of submissions return for corrections; the average wait from first submission to permit is about 90 days. A pre-submission triage that catches errors saves the architect time and the city hall capacity.
The problem
Two problems intersect:
For the architect / builder, checking a project against the municipal code is tedious, error-prone, and feels like work an algorithm should do. But every city has different rules, written in legal Portuguese, and rule changes happen often. There's no commercial tool that does this well.
For the technology, until recently, software to read a building project and cross-reference it against an arbitrary city's code required hand-coding every rule for every city. The cost-to-coverage ratio was brutal.
LLMs change the equation: a model can read a code PDF and interpret it on demand, with structured output. The bottleneck moves from "how do we code 122 cross-referenced regulations?" to "how do we make sure the model doesn't hallucinate?"
That's the design problem.
How I work
Piná is a solo project I've architected end-to-end. I do research (interviewing architects, builders, municipal staff), brand and content, frontend design, backend, and the pipeline that orchestrates LLM calls, vision, and rule-checking. The role spans builder-designer-researcher, but the discipline is the same: nothing ships unless I can explain how it could go wrong.
The system has three layers:
Intake
User uploads project (PDF, photos, schematic). 4-level extraction pipeline: text-first via PyMuPDF, vision used only on specific gaps. Cost low for common case.
Cross-reference
Project matched against municipal code, parameter by parameter. Every output tagged with source: PDF, CALC, LEI, IMAGEM.
Verdict
Parameter-by-parameter report, not opaque. Each rule shown alongside its source. Where the system can't be sure, it says so explicitly.
Trust-centric design
The architecture isn't "AI gives you the answer." It's "the system shows its work, and asks when it doesn't know."
Three design principles, all earned the hard way:
1, Honest about uncertainty
When a parameter can't be confidently inferred from the project file, the system asks the user to confirm, it doesn't fabricate. This was non-negotiable from day one because hallucinated parameters in this domain could mean an architect submits a non-compliant project thinking it's compliant.
2, Source-tagged output
Every claim in the report carries a tag:
PDF (came from the project), CALC (derived), LEI (from municipal code), IMAGEM (from vision read). The user can audit the chain and challenge any value. No black box.
3, The product doesn't replace the architect
A disclaimer below every report makes clear the analysis is a triage, not a substitute for CREA/CAU professional certification. The architect still owns the submission. Piná protects them from obvious errors; it doesn't sign their drawings.
What's been built
- Live self-service product (intake → report → payment via Stripe → delivery via email)
- 4-level extraction pipeline (PyMuPDF text-first, vision only on specific gaps)
- Multi-municipality coverage (currently scaled in Brazilian markets, expandable)
- 14 reports run with real projects across cities (private cases, internal validation)
- Brand, voice, and visual identity built around honesty about uncertainty ("we'll tell you when we don't know")
Where the LLM still falls short, and how design covers it
This is the part that matters to anyone hiring for AI-native product roles.
LLMs can hallucinate parameters. Mitigation: every value in the report has to point to a source in the original file or in a confirmed calculation. If the model can't ground a value, it surfaces "I don't know, please confirm", not a guess.
Municipal codes use legal language that's locally idiomatic. Mitigation: cities are parameterized municipality by municipality, with the code as input, not as hard-coded rules. New cities go through a one-time onboarding where the code is structured, but the analytic engine remains the same.
Project files vary wildly in quality. Mitigation: text-first extraction handles most files cheaply; vision is reserved for specific gaps (e.g., schematic-only inputs). The pipeline degrades gracefully rather than refusing the input.
What I'd flag in an interview
Building this taught me how to design with AI as a material. Not "with AI" as a feature, with AI as the substrate that has its own physics (probabilistic, expensive, occasionally wrong). Design choices follow from those physics, not from feature backlogs.
Same problem, ten years apart. This idea has roots in a research project I worked on at PUC-PR in 2019 (then called OND, then Pinape, now Piná). It was technically impossible then; the answer was always "you'd need to hand-code every rule for every city." LLMs unblocked it. The product is what 2019-me wanted to build but couldn't.
Honest about what doesn't exist yet. There is no paying customer base today. The product is live, real architects have tested it on real projects (private validations, friend-of-friend introductions), and the technical foundation is sound. Distribution and pricing-validation are open problems I'm working on, not problems I'm pretending I've solved.
Constraints + the road ahead
- No paying customers yet. Distribution and pricing are open work.
- Municipal coverage is bounded. Each new city is real onboarding work, not infinite scale.
- I'm solo. The product has to be simple enough that one person can hold the whole stack.
- Live in pina.mygoll.com, visit and audit.
Why this case sits here
Piná is where my research, service-design, and trust-centric instincts get expressed as product. It's the answer to the question "what would a UX-trained builder make differently?" The answer is: less feature, more constraint. Less "AI magic," more honesty about uncertainty. Less polish, more legibility about how the system gets to its answer.