Building AI-first Donkeycorns (and Whatsapp Wrapped)
Ideas are cheap, and execution is faster than ever, but knowing what exactly needs to be built remains a key skill.
Since I lost quite a few subscribers writing about genocide and enlightenment, let’s redress this unfortunate situation by writing about AI✨ and donkeycorns🦄. This usually fixes things.
This post is about what I learned so far building Hey, What’s Up?
The initial spark
A couple of weeks ago I came across a mailing list thread with a dozen entrepreneurs complaining about Whatsapp overload. They can’t keep up with Whatsapp because it’s too much, but they can’t ignore it either because everyone is using it. Wedding invitations are missed, questions go unanswered, useful information is impossible to find.
How hard could it be to fix this problem using AI? Surely an afternoon?
Is that a donkeycorn?
What went through my mind is that this problem has a shape of a donkeycorn. If you don’t know what a donkeycorn is, read about it here. But here’s the gist:
People complaining about a specific problem in strong terms
At least two people saying they’d pay a few dozen pounds a month for it
AI-first: the solution couldn’t have existed without AI and it will get better thanks to AI.
No fundraising required to build the solution, can be easily bootstrapped
Revenue potential that can be very attractive for a small team (single digit millions)
Here’s what I imagined. An app that takes my Whatsapp messages and asks an LLM to surface what matters: events, actions, topics, across both groups and 1:1 conversations.
Whatsapp is end-to-end encrypted, but it’s possible to get the messages by pretending you’re an official messenger like WhatsApp Web, scan the QR code with your phone and get the entire archive.
Yes, it’s against the Terms and Conditions of Meta, but there are lots of apps doing this, so maybe it’s not the end of the world. And, if I were thinking about a business that would last for two decades, I would be more concerned about this. But I’m thinking in donkeycorn terms.
If a donkeycorn makes money for a couple of years on a small scale and then Meta shuts it down — no big deal. It wasn’t too hard to build, it didn’t require investment, it delivered some profits, and it wasn’t meant to be a full-time effort anyway.
Proof of Concept: One Day
First step: let’s build a proof of concept to show that it works.
To avoid reinventing the wheel, I installed Beeper, a meta-messenger that allows you to sign into various messengers including Whatsapp and exposes the messages locally via an MCP, which an AI can easily access. So Beeper got me access to my whatsapp data.
To analyse the messages using AI, I decided to use Claude via OpenRouter. Fortunately, OpenRouter makes it dead easy to make a request to an LLM and to switch LLMs on the fly without changing a line of code. Convenient.
By the end of the day, thanks to Claude Code as my faithful AI coding agent, I had it working on my machine. It wasn’t sophisticated but it was pulling messages from Beeper, analysed them with Claude via OpenRouter and gave me the highlights.
Does anyone care? Let’s find out!
User Feedback
I sent that proof of concept to six people who initially complained about the problem. Of them, two actually tried it and gave quite positive feedback. What I learned:
People who tried it said it was very useful in surfacing things they actually missed
Four people couldn’t be bothered to install Beeper and configure the API access.
This is very useful data for only one day of work. Where do we go from here?
Can AI Help?
I set up a project in Claude, uploading all relevant files there: the original mailing list thread, user feedback, my thoughts on donkeycorns, etc. I also connected it to the github code repository. This meant that for every chat about this project Claude would have deep context. I prompted Claude in that project, as a meta instruction, to help me think through this idea and move it forward, so it can challenge me and do research for me.
From that moment, every question I had to think through starting with building the Products Requirements Document was done with Claude in the context of that project.
Alpha Version: One week
Claude and I looked at what we learned from the proof of concept and made two obvious conclusions:
The app delivers value on initial launch even as a primitive prototype (good)
People can’t be bothered to install Beeper, enable its API, then MPC, then create an access token, then copy it over to the app and not forget the OpenRouter key, too. (bad)
It was clear that it needs to work in one click, meaning zero configuration. This became the requirement for the Alpha version.
Experience taught me that it really, really helps to have a detailed Product Requirements Document describing how the app should work before I ask AI to build it.
Historically, maybe 10% of effort went into thinking what needs to be built and 90% into building it. In the AI-first world, it flips. 90% goes into thinking what needs to be done, and 10% into making it happen. All the effort goes into achieving upfront clarity.
So I spent several hours going back and forth with Claude about how exactly the Alpha version should work. What happens on startup? What libraries are we using to access Whatsapp? How the data is stored? How is it encrypted? Will accessing the data mark the messages as read? There are dozens of questions like this that need to be thought through.
The resulting PRD was over 1,500 lines of text written by Claude after a long conversation with me. We decided to make it a Mac app because we’d be handling a large volume of data we’d need to store safely and because down the line we’d be using a local LLM for privacy reasons. Neither is possible in a browser.
Then I handed it over to Claude Code and it built it for me after a few days of iterating on it part-time. Much of it was learning how to get data out of Whatsapp, which I’ve never done before.
But soon enough, it was working as a Mac app without Beeper.
What about privacy?
Let’s digress a bit. Whatsapp data is very private. Even for a proof-of-concept, privacy is a non-negotiable requirement. This means:
All processing is done locally and the messages are never sent to our servers
The data is always encrypted using Mac’s own encryption tools (they’re good)
Later, we can use a local LLM instead of calling Claude through OpenRouter, making sure the data doesn’t leave your laptop at all.
Even when we’re using OpenRouter, we use AI providers that don’t train on and don’t retain the data
Writing a privacy policy that explains what we’re doing and why
Taking care that we don’t expose the data to analytics by mistake, e.g. through session replays. And we need analytics to capture errors and user behaviour (but not private data).
My first instinct was to use a local LLM straight away, but I realised that it is tricky for two reasons:
It’s big: downloading an LLM means a few gigs of data
It’s slow: running it on an average laptop is not nearly as fast as in the cloud, and even the cloud is not instant as there’s a lot of data to process.
But! A local LLM is free (OpenRouter costs money) and very private, so we’ll do it one day, just not in the Alpha version.
Roadblock! Apple Doesn’t Like Me
It’s the first time in my life I’m building a Mac app, which would never happened without AI. I know enough about software development to guide Claude Code but not enough to build a Mac app myself, which is why AI is such an incredible point of leverage for people who know what they want to build.
However, since I haven’t been building Mac apps, I didn’t have an active Apple Developer profile. I naively assumed that signing up would be as easy as paying the yearly fee. How wrong I was… It only took a week to sort it out through human support at Apple and I’m still not sure it’s fixed for good.
Roadblock 2! Baileys…
Baileys is a popular library used to access Whatsapp by scanning the QR code. I spent a week building a solution on top of it until I hit a weird bug. Sometimes the messages would sync after scanning the QR code and sometimes they wouldn’t. After half a day of debugging it appeared that Whatsapp uses two different methods of delivering the messages, choosing between them according to its own criteria, and Baileys supports only one of them. Bummer.
This is one of those challenges that AI can’t navigate on its own yet. I can’t just tell Claude Code to sort it out because there are very different ways of sorting it out and they require both product and engineering judgement. Do we fix Baileys? Do we move to a different library? Which one? Do we do something else?
As I was building this product, I kept thinking that it would be hard for a non-engineer could build it. AI enabled me to build a Mac app without any Mac development experience, but it did require my engineering judgement on an ongoing basis.
Long story short, we did a heart transplant: Baileys was out and another library was in. Only took half a day with Claude Code instead of a couple of weeks by hand.
Whatsapp Wrapped: One more week
For the last two weeks I felt like my Apple Developer account is a few hours away. Apple support kept supporting me. It even got activated last Thursday only to be disabled again on Friday because of a glitch on their side. Then I got it working again on Saturday…
And one day it struck me: while I’m waiting, I can build Whatsapp Wrapped!
After all, I’ve got all my Whatsapp data in a local database. How hard can it be to build Whatsapp Wrapped?
Not too hard, it turns out, and it was good fun! This is one of my favourites:
Lessons learned
Here are a few things I learned so far.
First, you can move fast with AI and an idea. A proof of concept in a day, an Alpha version in a week. All of this was done part-time in between work calls, travel, meetings and Christmas preparations. This wouldn’t have been possible without AI.
Second, being an engineer helps. It’s not impossible for a non-engineer to build stuff with AI, but it’s so much easier for me because I used to be a software developer before AI.
Third, all the effort goes into defining what needs to be done. Building is easy if you know what needs to be done. You think you do until you start explaining it to AI. If your thinking is a mess, the software is going to be a mess. As Henry Coutinho-Mason said in his excellent piece, “Schools today teach skills; AI will reward those who can articulate what needs doing.”
Fourth, ideas are cheap but execution still matters. While do I hope that people find the product useful and eventually pay for it, there’s no defensibility in ideas. What I do care about is learning how to move fast. Ideas don’t matter, but my ability to go from an idea to a proof of concept in a day and an alpha version in a week matters. Because if I can do it 30 times in a row, some will work and the skill will compound. As I keep repeating, you’ve got to use AI all the time to understand what it’s capable of.
Fifth, donkeycorns are real. This idea would be a non-starter without AI. Why? To build it without AI you’d need more time and effort. To justify that, you’d need a chance of more impressive revenues. Suddenly you’re pitching VCs to hire engineers instead of building. But there’s legal risk, so VCs don’t invest and you give up. But with AI, trying something like this is cheap and easy. Donkeycorns!
What’s next?
If you’d like to try it, give it a go!