Build · Empowered.Vote (volunteer) · 2025

Empowered.Vote — shipping voter tools as an AI-augmented builder

Shipping production TypeScript features for a civic-tech voter platform using Claude Code as primary development partner.

Role: Product builder

Context

Empowered.Vote is a civic-tech project building tools that help voters understand candidates, ballot measures, and the actual mechanics of voting. I’ve been contributing as a volunteer product builder, shipping features end-to-end in TypeScript with AI as my primary development partner.

This is the work I’m currently doing alongside my research practice — and it’s the closest thing on this site to “here’s how I work as a builder, not just as a researcher.”

What I did

Over roughly three months I led four user-facing features into production:

  • Compass — guided voter exploration
  • Essentials — core voter information
  • Treasury Tracker — campaign finance surfacing
  • Read & Rank — ballot measure analysis and ranking

The stack is TypeScript front-to-back, with Supabase, Netlify, and GitHub as the surrounding infrastructure. My development workflow uses Claude Code as the primary partner: I do all the prompting, framing, and review; the AI handles most of the line-by-line code. Bugs surface through iterative use rather than through extensive traditional testing — a deliberate tradeoff given the volunteer scope and the speed it lets us ship.

Outcome

Five production features shipped in ~three months, used by real voters, with the iteration loop tight enough that we could respond to feedback quickly.

Just as importantly: the experience has reshaped how I think about UX research in an AI-augmented practice. Most of what I argue for in research conversations now — about where AI helps, where it adds friction, where it’s misused — comes from having actually built with it, not just from reading about it.

Reflection

Two honest notes.

On the AI framing. I am not a traditional software engineer, and I don’t claim to be. What this work supports is a narrative about being a non-traditional builder who ships real software with AI; it doesn’t pass the bar for senior engineering roles on paper. I think that’s the right honest framing, and it’s also a framing I’d defend on the merits: working this way is genuinely different from either pure engineering or pure prompt-engineering, and it’s where a lot of UX-adjacent product work is heading.

On what transfers back to research. The most useful skill I’ve built here is reading what the AI gets wrong fast enough to redirect it without burning a day. That same skill — recognizing when a research direction is sliding off the rails early — is one I’ve leaned on in research work too. The medium is different; the underlying habit is the same.