My role: Chief of Staff, Growth & Development
Timeframe: November of 2025
Tools: Claude Code for VS Code, Cursor, Git/Github, 12Labs API, Vercel, AWS S3
Hamlet
Hamlet is an AI-powered civic intelligence platform that tracks, transcribes, and indexes local government meetings across the United States. It allows professionals and citizens to search public records from thousands of city councils, planning commissions, and zoning boards.
A new, v2 search experience
Real Estate developers were drowning in local governing meeting footage with no way to find what mattered specific to their projects, without watching hours and hours of video coverage. The existing keyword search experience was not enabling customers to find meaningful results and it needed to be overhauled from a technical backend as well, which engineering leadership was resistant to.
From the business side, a passive meeting archive had the potential to become a daily-use intelligence tool, but only if it worked in the way that enabled customer’s specific use cases which implicitly meant developing a semantic and hybrid tool that had both speed AND polish in the expected results.
The Hamlet research & development team
I was the only person who sat across design, research, and engineering on this initiative and could prove out the feasibility & viability of doing a search revitalization with a high degree of autonomy with a working code base and interactive prototype.
Sunil, Founder & CEO
Zach, Head of Product & Engineering
Mike, Lead Engineer
+ 6 additional full stack engineers
Opportunity overview
☹️
Customer need
Customers needed to find what was said about their company or project, without watching hours of footage to get there.
📉
Business opportunity
Semantic search would turn a passive meeting archive into a daily-use intelligence tool and unlock retention and expansion.
⭕️
Challenges
A basic keyword search existed but was broken and actively defended by engineering leadership. The proof-of-concept needed to prove why semantic or hybrid search was worth the effort of a rebuild.
🙈
Risks
Multiple API integrations (namely 12Labs + OpenAI) had to be fast enough to feel useful and stable enough to test with real customers. The speed vs polish was the real tension to manage.
Step One: knowledge gathering
We started from existing signal,
not new research
Here’s a few of the overall activities that we completed:
- Reviewed existing customer interviews, NPS data, and usage patterns
- Search was the #1 unmet need – already validated before I wrote a line of code
- Mapped top search intents: topic, speaker, date range, outcome
- Ran API experiments with 12Labs to confirm what it could actually surface before designing around it
Step 2: Synthesize findings
The core reframe: users don’t search meeting content like a document — they search by meaning. The insight that reframed everything: “What did the council decide about rent control last month?” is a semantic query, not a keyword one. The interface needed to surface decisions, not just matching text.
Three features were scoped from our findings:
semantic search with filters, AI results summary, meeting detail with extracted decisions. Sentiment and save-and-subscribe added as stretch targets.
Step 3: Build the prototype
Outcome: I deployed a testable prototype to GitHub Pages in 2 weeks, with a live URL, not a Figma prototype. Real users, real testing.
I built a prototype myself in 48 commits:
- Integrated 12Labs for video intelligence, multi-modal search results, and transcript extraction
- Integrated OpenAI for results summarization
- Hit a real constraint: native sheet component broke on mobile keyboard input — browser can’t replicate OS-level keyboard behavior. Scrapped it. Rebuilt as standard dialog.
Check out the full demo of the v2 prototype
Notable customers impacted
DR Horton
YIMBY ACTION
PROLOGIS REAL ESTATE DEVELOPER
Once we took the feature live with our Beta testing group, we watched the feedback and analytics roll in.
Real users taught us what we didn’t design for and what was still missing:
- Save-and-subscribe was secondary in the design, but users made it primary
- Sentiment breakdown was the first thing power users gravitated toward
- Field advocates were planning multi-site routes, not tracking single topics — a persona we hadn’t fully anticipated.
“Tons of time [is] saved on my end right away… I could probably gain an hour of my day back at least!”
“So much more time efficient, right, to get the context of what they’re talking about an issue.”
We made three adjustments to our roadmap priorities: (1) elevate save-and-subscribe, (2) sentiment as first-class feature, (3) multi-city workflow. Next sprint backlog set.
Takeaways & learnings
It’s my philosophy that every project and experience has something to teach us. No matter the expertise or experience of the person, there is always something to learn and take away from a project that could be done better or differently next time. There’s also always things done well that should be done and re-applied for the next project as well! Here’s a few of those reflections for the Hamlet Search v2 work:
🏆 Things we did well
- Validated the core hypothesis with a working product, not a prototype
- Built quickly by integrating existing APIs rather than building from scratch
- Stayed close to real user behavior; the save-and-subscribe insight came from listening & watching, not asking
- Made a real technical decision in code (scrapping the sheet component) rather than designing around it
🧐 Things we could have done better
- stablished clearer success metrics before building. Example: “What does “done” mean for this POC?”
- Involved Hamlet’s engineering team earlier to pressure-test API architecture choices
- Documented design decisions more rigorously during build. The commit history is there but the reasoning behind pivots lived in my head.
- Scoped the POC more tightly: sentiment analysis and save-and-subscribe were right calls, but adding them during build extended the overall timeline.
Idealis Design 