Think bigger
Sometimes you have to build something enormous to make one small thing simple.
I want to be able to use my own Messenger history with my agents. Nearly twenty years of conversations are part of my memory: friendships, plans, jokes, things I would never think to save anywhere else. I can search them in an app, but I wanted my data in a place I control, where my own tools can work with it.
This is part of a larger itch I have about my devices. I want to understand what they are doing. I want to be able to build on top of them. If a tool holds something important to me, I feel a need to master the tool rather than just accept the interface it gives me.
So I started with the obvious route: automate an export through the official channels. It gave me a starting point, and it respected the way the service expects people to take out their data. But the export was slow, and making it repeatable was surprisingly complicated. I could get a copy of the past. I wanted something that could also keep up with the present.
One layer deeper
I know the web like the back of my hand. Why not build a browser extension to collect messages as they arrive and save them to my own database?
That worked. It was also full of little exceptions. Conversations load in pieces. The page changes shape. A browser tab has to be open, signed in, and in the right state. Each edge case was manageable on its own, but together they made the simple idea feel fragile.
So I went deeper. I’ve built enough Android apps to know that, sooner or later, you usually find SQLite. I replaced the browser scraping with a rooted Android emulator running the official Messenger app, plus a service watching its message database. That felt more solid. The app could do its own syncing, and I could read what it stored.
But now I had an emulator to keep alive, an Android image to automate, and several services depending on one another. The data was closer. The tool I wanted still wasn’t simple.
The ridiculous idea
Years ago I built Android ROMs. I knew enough to suspect that Java wasn’t magic, and that an APK didn’t necessarily need a whole phone around it to do useful work. What if I built only the Android-shaped world Messenger actually needed?
It sounded absurd. To replace three working but awkward services, I was proposing a runtime with hundreds of thousands of lines of code behind it: translating the app’s bytecode, providing the framework it expects, connecting its native libraries, and giving it a persistent place to keep its data. The official Messenger APK would run inside it. My tools could talk to the app and read the SQLite database it maintains.
A few years ago I would have stopped there. I’m a father of two with a full-time job. I don’t have spare months to disappear into an Android runtime. But now I have agents that can help me investigate, implement, test, and keep track of a problem this wide. The old constraint on what I could attempt had changed.
When the small solution keeps growing complicated, maybe the answer is to think bigger.
We built the headless runtime. The real app can sign in, keep its session, receive messages into its own database, and send a message through its own composer. I can start and stop the container, inspect what the app is doing, and give my agents a controlled way to interact with it. From my side, that begins to look like the small service I wanted in the first place.
The surprising part is where the complexity went. I moved it into a system I can inspect and change, so the thing I use each day can be small. That is what “simple” means to me here: a tool I can start, understand, and make my own.
AI didn’t make the hard work disappear. It gave me enough reach to take on work that used to be out of bounds for a person with my life. Sometimes the sensible next step is not another patch on the small idea. Sometimes you need to think bigger to find the simplicity you were looking for.
Robin Westerlundh
← back to the index