Borough: Civic Platform Design
Borough is a civic startup that connects residents and local governments through community discussions and structured 311 reporting. I led product design from concept to MVP, shaping mobile UX, AI-assisted reporting, brand identity, and early go-to-market across five pilot towns.
Product Strategy
Mobile UX
Branding
Go-to-market
AI Integration
CONTEXT
Reporting civic issues is fragmented and uncertain for residents and municipal departments.
You spot a pothole. You look for somewhere to report it. You find a phone number, an email, or a buried web form. You submit. Nothing happens, or at least nothing you can see.
On the other side, municipal departments receive unstructured inputs across phone queues, email inboxes, and spreadsheet trackers, and spend more time triaging than resolving.
The dominant platforms — CivicPlus, Granicus, SeeClickFix — were built for government operations, with resident interfaces bolted on. No one had meaningfully claimed the small and mid-sized suburban town market, where civic infrastructure is thinnest and the gap between residents and local government is widest.
DISCOVERY & RESEARCH
40 interviews across two states confirmed the problem, and gave us the language to frame it.
Primary Research
• Semi-structured interviews
• 25 residents · 15 municipal staff
• Boston suburbs + southern Michigan towns
"Reporting the issue is a bigger nuisance than the issue itself." — Frank Pelosi, resident
Secondary Research
How might we improve the civic reporting experience while helping residents stay engaged with their town?
Solution
Borough: a unified town app where residents report issues, stay informed, and engage with their community, all in one place.
PRODUCT STRATEGY & SCOPING
Borough was designed for V2 from day one. The MVP was a deliberate scope reduction to validate adoption before expanding.
Before any design work, I ran a lean canvas exercise with the founding team to pressure-test the business model and identify the riskiest assumptions. Borough was always a full town app. MVP established the civic foundation. V2 deepened the community layer. V3 scaled it. Each phase had to earn the next one.
Features that required an established resident base couldn't come first. Trust had to be built through utility before community could grow on top of it.
INTERACTION FLOW
Moving community to the landing page as primary interaction to drive regular engagement.
Early designs prioritized reporting as the primary entry point. Usability testing revealed low re-engagement, residents returned only when they had an issue to report, creating an episodic usage pattern. Repositioning the community feed as the default surface drove habitual engagement without deprioritizing the core reporting utility.
AI reduced reporting friction without taking control away from residents.
Residents abandoned the form mid-way due to friction. Replacing it with AI-assisted plain language input reduced the effort to submit, but residents couldn't verify what was being sent on their behalf. The final model kept the AI input and added a manual review step before submission. The ease of conversation with the control of a form.
SYSTEM DESIGN
The AI layer processes complex resident input and routes it to the right department, sending back report status to the user.
The AI processing layer is grounded in a RAG pipeline built from each town's own documentation: department taxonomy, town hall transcripts, municipal records. Departments retain override control on routing and priority. Status updates flow back to the resident in real time.
BRAND & VISUAL DESIGN
GO-TO-MARKET
Borough needed two adoption strategies: one to onboard towns, one to onboard residents.
Selling to towns
GTM for a civic platform isn't a typical consumer launch. The buyer is a town administrator or municipal director, not a resident. I developed the pitch deck and supporting materials used to onboard the five pilot towns, framing Borough's value in operational terms — reduced triage time, structured intake, resident transparency, rather than product features. The lean canvas grounded those conversations in validated assumptions rather than vision.
Getting residents in
Onboarding a town meant nothing without resident adoption. We planned Facebook campaignstargeting each pilot town to drive initial awareness, paired with early adopter incentives to convert the first wave. The first 100 residents in each town earned exclusive badges, and a referral program offered town-based rewards, like discounts, local business perks, community recognition to turn early users into advocates.
PRODUCT OUTCOME
Five towns launched in six months, with routing, reporting, and community active across all pilots, and the architecture ready for everything V2 demanded.
Structured inputs reduced manual triage for departments. Status visibility reduced resident follow-up. Community and utility coexisted without either undermining the other. The MVP proved what it needed to prove: that residents would engage and departments would trust the system, clearing the path for the fuller town app vision in V2.
5 Pilot Towns · 6-Month MVP · AI-Assisted Routing in Production
REFLECTION
Borough taught me what design actually looks like outside a controlled environment.
I learned to own the entire product surface, not just the design layer
There was no existing foundation. Research, branding, design, roadmap, GTM, website, animations, visual assets, team alignment — all of it started from zero and landed with me. It wasn't scope creep. It was just the reality of being the only person on the team who understood what the product needed to be.
I learned to make good decisions under real constraints: no budget, strict timelines, and five towns to keep happy simultaneously
Six months, no budget, strict deployment timelines, and five pilot towns each with their own needs and expectations. The job wasn't just designing a product. It was constantly balancing what towns needed against what we could reasonably build, while keeping every team member pointed in the same direction. By the end there was a structure, a roadmap, and a clear V2 vision where there had been nothing.
I learned that tight dev collaboration means designing ahead of the build, not reacting to it
Me and the developer were on call constantly. I'd explain design intent, he'd flag edge cases and development constraints. We always knew which section was coming next, so I finished designing before he needed to start building. On the AI feature especially, we decided the direction and implementation together. No handoff friction. No surprises.
