Article summary
A political campaign runs on volunteers, and almost none of those volunteers are programmers. For more than the past six months, I’ve been volunteering for a U.S. Senate campaign, building tools that help the campaign and other volunteers organize people and visualize data. What started as a small bot that posts upcoming events to local channels has grown into a set of tools that helps get people into Slack, welcomes new members, routes volunteers into their local channels, tracks signup and canvassing trends on a dashboard, and allows organizers to update settings. Along the way I’ve learned that what makes a volunteer programmer useful to a campaign is rarely the cleverness of the code. It’s earning organizers’ trust, meeting the need in front of you, and building tools the campaign can run without you.
Get involved early.
The sooner you show up, the more influence you have and the easier it will be to get in touch with campaign organizers. Early on in a campaign, nobody has decided yet which organizing platform, chat tool, or spreadsheet-of-record the whole operation will live in. If you’re in the room for those decisions, you can steer the campaign toward platforms with real APIs and away from tools that will box you in later. Once hundreds of volunteers are onboarded onto a platform, migrating is effectively impossible. As the campaign ramps up, organizers will have less and less time. Showing up early is how you build the trust you’ll need to get tools adopted.
Starting early also means your tools can grow with the campaign. The bot that welcomes new Slack members was simple when the workspace had a few dozen people in it. Because it was already running, extending it with an invite-help queue, signup dashboards, and a weekly growth report was incremental work. Building all of that from scratch in the final crunch before an election would have been impossible.
Adapt to the needs of the campaign.
A political campaign is not your typical side project. It has a hard deadline and shifting priorities, and your roadmap should be whatever the organizers need this week. Early on, the bottleneck was getting volunteers into Slack and into the right local channels, so that’s what I automated. As the election drew nearer, the priority shifted to keeping local volunteer leaders engaged, so I added statistics to the dashboard and a weekly growth report that ranks local groups by new signups (a little friendly competition to keep group leaders motivated).
Be prepared to shelve ideas, too. A feature you find technically interesting is worthless if it doesn’t serve the current moment of the campaign. Treat organizers as your product owners: ask what’s eating their time this week, and build that.
Be collaborative.
Make your code available and work in the open. Both of my projects live in public repositories, and the people working with me on the campaign know where they are and how they work. Campaigns have high turnover (volunteers burn out, staff move roles) and a tool only you can see is a tool the campaign loses the day you get busy.
Collaboration also means working with non-technical people, who are most of the campaign. The event bot posts a nightly preview into a review channel so organizers can catch misclassified events before the public digest goes out, and they can add intro paragraphs to the weekly digest just by replying in a Slack thread. None of those reviewers write code, but they shape what the tools post every single day. Design your tools so non-programmers are contributors, not just consumers.
Get your hands dirty.
The best way to know what volunteers and the campaign need is to be a volunteer. Knock doors, make phone bank calls, help run events. When you’ve personally watched a new volunteer struggle to find their local Slack channel, you don’t need people to tell you all the details. Be your own user.
Doing the unglamorous work also earns trust. Organizers are rightly wary of someone who parachutes in wanting to “fix everything with an app.” Showing up to canvass first makes it much easier to have a conversation later about which busy work is worth automating.
Keep the stack cheap and boring.
Campaigns have no money for infrastructure, and they end. Win or lose, the operation winds down after election day. That argues for the cheapest, most boring stack you can get away with. My event bot is just a TypeScript script run on a schedule by GitHub Actions, which costs nothing. The Slack tools are a small app on a hobby-tier host with a free-tier database. There is no Kubernetes cluster, no message queue, and nobody on call.
Boring technology is also handoff-friendly. When you recruit another volunteer programmer, or when someone inherits your tools after you, a plain web app with a cron job is something any developer can pick up in an afternoon.
Build in human review and safe re-runs.
Your tools act in the campaign’s name, in front of hundreds of volunteers. A bug in your side project annoys you; a bot spamming every local channel at 9 a.m. embarrasses the political campaign. So put humans in the loop and make every automated action safe to repeat. Before the event digest posts publicly, a preview goes to a review channel the night before. Internal endpoints support a dry-run flag that computes a report without posting it. And every scheduled job is idempotent: re-running the Monday digest checks whether it already posted today and quietly exits, so a flaky workflow retry never double-posts.
These guardrails cost little to build and they’re what let a campaign trust automation at all.
Handle personal information responsibly.
Campaign tools are soaked in personally identifiable information (PII). My invite-help queue stores volunteers’ names, email addresses, and phone numbers; the welcome bot looks people up by email. And, on a campaign, even a bare list of names is sensitive: it reveals people’s political affiliation, something plenty of volunteers don’t share with their employers or families. People handed this information to the campaign, not to you, so treat it with as much care as you would data at your day job.
The practices are the same ones you already know: collect only the fields you actually need, and show them only to the people who need them. My queue page sits behind sign-in and an explicit admin list. Keep PII out of logs, error messages, and Slack posts. And, if your code is public, be doubly careful that no real data ever lands in the repository: no seed files from production, no screenshots with real names, no volunteer lists in test fixtures. Finally, plan for deletion: when the campaign ends, the data should end with it, not linger in a free-tier database you’ve forgotten about.
Make your tools self-serve.
Every knob that requires editing an environment variable is a Slack DM that you have to spend time on. As the tools matured, I moved configuration, like which group maps to which Slack channel, out of config files and into a settings page that campaign workers and trusted volunteers can use themselves. The invite-help queue works the same way: the volunteer platform calls a webhook, volunteers land in a queue, and admins work through it on a live-updating page without ever pinging me.
You are one volunteer with a day job. The campaign runs seven days a week. Anything the campaign can operate without you is worth the extra effort to build.
Make your tools reusable.
Your campaign will end, but the next one is already forming. Write your tools so another campaign can pick them up: keep group names, channel IDs, tokens, and schedules in configuration instead of hardcoded, write a README that a stranger could follow, and use an open-source license. Nothing in my tools is specific to one candidate. Any organization using the same organizing and communication platforms could deploy them. The hours you invest in one race can keep paying off in races you’ll never volunteer for.
Even simple tools change the world.
You don’t need to build anything sophisticated to be enormously valuable to a political campaign. Most of what I’ve described is a simple loop: read from one API, write to another. But every one of those loops replaces a human copying names between browser tabs, and on a campaign, human hours are the scarcest resource there is. A tool that saves organizers a few hours a week frees them for the work that actually wins elections: talking to voters.
Campaigns are drowning in exactly the kind of busy work programmers are good at eliminating, and almost nobody with our skills is showing up to help. Find a campaign you believe in, get there early, and start building. It’s one of the highest-leverage ways a programmer can give back and help change the world for the better.