Capy the WhatsApp Bot
Local Tech Stacks blogchain
context: a few friends and I are circling around the idea of “Local Community Tech Stacks”: interoperable, somewhat vibe-coded, ideally self-hostable apps to help our communities run. While still fairly nascent, we agreed to start publishing our adventures in this space to record and share our insights for each other and the broader world.
Savannah runs something called food exchange here in Boulder. Every week, each person creates a number of jars of the same dish to then swap with everyone else for their jar of a different dish. The result is everyone having a variety of different food to eat with the simplicity of classic one-big-batch food prep.
the problem: There is nobody who is formally responsible for asking who’s in each week - it just falls to whoever remembers to do it and is in town that week. The moments where nobody remembers result in a bit of a coordination failure.
Enter, Capy.

the solution: Capy is a WhatsApp bot whose entire job is to send a message at a set time each week, prompting the group about who’s in and who’s not. Literally, “Who’s in this week?” It doesn’t have AI. It doesn’t generate a knowledge graph or run analytics to see who’s seen the message, who’s reacted to it, or any of that fanciness. We named it Capy, short for capybara, and gave it a pink beret like the one Savannah has.
the process: Despite the bot not having anything to do with AI, I used AI to build it. Probably about $30 of Anthropic Claude credits. I built the first version in Cursor. Then, on and off half-attentive prompting when something would crash, I’d give it the logs, lightly instruct it but trust this is a simple enough thing that it can figure it out itself.
Challenge 1: WhatsApp doesn’t really support bots. They have “business bots”, but they’re neutered - think more of a restaurant profile that lets you view their menu and place orders through WhatsApp, rather than a bot that is allowed to do things in your group chat with your friends. There is no official API (a way for a program to connect to another program, through an official structure). This is in stark contrast to Telegram and Discord, though more on par with how iMessage works.
Solution 1: Open source to the rescue! There’s a Typescript library (basically a program that connects your own code to WhatsApp unofficially) called Baileys. Claude found it for me and got it set up. This makes up the bulk of the backend code.
I then asked for a frontend to manage the messages that would be sent. I asked for it to be built in ViteJS - another open source framework for building simple webapps. LLMs know it well, it’s light, perfect for little projects like this.

Challenge 2: Since we can’t make an official “bot”, we need to create a real WhatsApp account. WhatsApp, like Apple and Telegram and most other services, disallow new account registrations with a VOIP number (the kind you get from something like Google Voice). Or if they do allow it, their automated screening systems will eventually block or ban it. This is annoying, but not insurmountable.
Solution 2: Enter, US Mobile. This is what’s known as a virtual carrier I believe - they bill you directly but under the hood they run on existing carriers, leasing their networks. They also have very cheap plans - because the majority of the information will be moving through WhatsApp + the internet, we only need to be able to receive a couple text messages at most. So I went with the $8/mo plan.
Problem 3: Deploying this somewhere. Unlike a static site (something like this blog for example - where there is no long-running processes behind the scenes that need to stay functioning), it’s easier if Capy stays connected to WhatsApp. In theory it would be possible to build it in a way where it wakes up, connects, sends the message, and goes back to sleep but then you need to manage the system that wakes it up, kicking the problem up a level.
My usual approach is to rent a server on something like Railway. One server isn’t expensive - usually about $5 or $10/mo. But 10 servers start to add up. Other services, like Vercel don’t work because they don’t allow long-running tasks (like a bot requires). They also generally run $20/mo/seat. Something else I’ve been exploring is running things at home on my Mac Mini. And while this works well, it has some management overhead and ultimately doesn’t solve the problem for my friends very well without a lot of handholding and more overhead.
Solution 3: Some friends and I are building a coworking space in downtown Boulder called RegenHub. It’s very bottoms-up: we run it as a DAO, and we try to balance out the nerdiness with dance parties on the roof. One of my recent projects there has been self-hosting our own infrastructure using a donated gaming PC running Coolify, a self tool to self-host webapps. This doesn’t come anywhere close to the reliability of something on Amazon Web Services but for non-production grade low-stakes projects like this, it’s perfect. Another post to follow soon on this.
So I was able to deploy it to the equivalent of capy.regenhub.xyz
, accessible to anyone else in the hub. It will run at the cost of the eSIM and the electricity this server takes up in the closet. And of course, my time when the next thing breaks. But that’s the journey with these things!

It’s worth mentioning that along the way, there was quite a bit of fiddling around with getting the session to stay logged in. Strange websocket issues when moving over to Coolify. A few intermittent crashes when WhatsApp servers had issues and the bot couldn’t recover. While the first version might’ve been vibe coded blindly, there were absolutely a few moments where I had to put on my engineer hat to nudge Claude in the right direction of how to solve something that I wouldn’t expect from the average barefoot developer.
While one path here is to just wait for the smartest models to get that much smarter, the Local Tech Stacks philosophy prompts us to ask, what if we design and build more things for community, in community? So that neither the ideas, designs, skills, nor resources have to come from one person but might be offered in collectively.
Instead, it could take shape with some combination of repeatable social practices, llm-accessible writings on best practices & tooling, open source code examples of similar apps, shared physical infrastructure, and a broader network for exchanging notes and requests for advice. Besides potentially being more achievable than an infinite improvement curve on the models, it also just sounds more fun, and I look forward to exploring this shape with you all.
see also: