A very organized zero
Last month I spent some time reorganizing my projects. I used to keep everything in Notion: one single database with tasks from every project, all tagged. I ran the ICE framework in there, the backlog, the Kanban board. It was convenient because I could update it from anywhere, online.
But it was slow: slow to load, slow moving between things, slow just to look at a note.
Or rather, the tool was too powerful for my needs.
One tool to rule them all
So I decided to build Atlas, something that ran locally, versioned, that let me manage several projects at once.
Same shape, every project: Idea → Task → Backlog → Release → Roadmap
And, most useful of all, a log: a place to note down, as I go, what I actually did on that project.
That log turned out useful for two reasons. It works as internal documentation for myself. And with every project logging separately, it's a lot easier now to put together an update for Small Numbers. This blog is one of those projects too, but it's the one that can read the logs of all the others.
Each project still gets worked on its own, in dedicated Claude Code sessions. I also use Atlas to set up new projects, so they start with the same structure, the same project files, for logging and for the agent setup alike.
Paying Brazil to break my app
Right now Stiva is where most of my effort goes. It has a business model in place and probably going to get more updates than the others, at least in this early phase.
Last month I ran a small Google Ads app install campaign for Stiva, starting August 18th. The goal was mainly installs and, simply, app opens. I didn't want people to interact with anything specific or hit some conversion event, I just wanted the app to open. I wanted to expose it to more real devices than the handful I and my few testers use for testing, to see how it initialized, how it opened, whether there were bugs, anomalies or crashes I couldn't see from my own phone.
(It's not really a "campaign", it was online for too few days, with too small a budget. Let's call it a way to get some quick installs.)
I targeted Brazil, in English and Brazilian Portuguese, one of the app's localized languages: a growing market, with lower costs than the US, Canada or Europe.
I set the target CPI a bit too low, which brought in a number of low-quality installs, which in turn led to a number of fast uninstalls too.
Okay, probably not Spotify-campaign numbers, but hey, this is Small Numbers, and real anomalies did show up.
Some of them kept the app from being truly offline.
Others were native Flutter issues, combined with some of the libraries I use.
Others I managed to handle better.
The campaign took a week, the fixes a few evenings more. What ate the rest of the evenings was keeping every project visible at once. That's turning into the real bottleneck, more than any single thing I ship.
Any thoughts on what I wrote? Reply by email. I read everything.