adlk.ioI drop my kids at school just before eight and I'm usually in my coffee shop by half past. That first hour or two is the most useful part of my day, and it looks like this.
There are two messages waiting on my phone. One is the overnight report from the ops side: what got tested while I slept, what broke, what got fixed and is now waiting for me to look at it. The other one is the numbers: signups, trials, conversions, what moved in search, which experiments are due. Neither of them was written by a person.
I spend maybe 20 minutes on pull requests. Then the numbers, then the dashboard, then the support mails that can't wait until the afternoon. And then, most mornings, I spend the rest of that hour arguing with an AI about what Franz Mail should become. Not writing code, just pulling an idea apart, looking for the hole in it, throwing it away and starting again.
Quite often somebody joins me. Developers, product people, other founders, whoever I've talked into a coffee that week. I put the same ideas in front of them that I spent the morning arguing about with a model, and they're a completely different kind of test. A model will argue with you all day and still let you keep a bad idea. Someone who has actually shipped something usually won't. I've thrown away a ton of things at that table that looked great on screen an hour earlier.
Some of the most useful conversations aren't with people I invited at all. The person who founded the place runs a business, manages a team and keeps track of a hundred things across a dozen channels, and they think about all of that in words I would never have come up with myself. That's worth a lot more to me than another developer nodding along. And every now and then someone at the next table leans into whatever we're arguing about and turns out to have had the same problem in a completely different industry. Vienna is small.
I run Franz alone. 19 apps, packages and services, ten years old, paying customers on macOS, Windows and Linux. The OS fragmentation is real: something that works everywhere breaks on one distribution, one window manager, one Windows build. The pile of open issues that comes with the sheer complexity of all this never gets to zero and it never will.
The morning is still calm, and that's only because a lot of work happened without me.
Faster alone than with five people
The speed is real and it's bigger than I expected. Work I would have needed most of a year for now lands in a few months. I've run Franz with up to five people at different points, and alone today I get more done than we did back then.
That's one step away from a story I don't believe though. This isn't about replacing the people I worked with. I wrote about why Franz is one person now earlier this year, and that wasn't a downsizing decision.
Part of it is just coordination. Specifying, handing over, waiting, explaining the same context for the third time was the price of being more than one person. That price drops a lot when the thing you hand work to already knows everything you know.
Then there's the money. Franz only has to fund me. When five salaries depend on the revenue and you want to run an experiment that might push that revenue down for a few months until it's dialed in properly, it gets scary. It's a mental rollercoaster and you feel it every time you open the dashboard. So you take the safe version of the idea, or you quietly don't run it at all. Alone I can try the thing that might not work, be wrong where customers can see it, and keep adjusting until it works. Almost everything I'm proud of in ten years of Franz came out of that freedom.
The change I'd actually point at is quieter though. Almost everything I now hand to a machine is work I was doing, but only occasionally. When there was a gap, or when something had already gone wrong and I went looking. I ran the full end-to-end test suite when I had a bad feeling about a release, which means I ran it after I already suspected the answer. I looked at the dependency updates when the pile got embarrassing. I sat down with the analytics properly maybe once a quarter, usually because I was trying to answer a question I should have known already.
None of that was neglect and it's not really about being alone either. We didn't do these things when there were five of us. Nobody was slacking. Everyone had their role and so many tasks in their own queue that no one ever got around to setting up this kind of infrastructure or doing the analysis. Nobody gets hired to build test infrastructure, or to spend two days with the analytics figuring out which question is even worth asking. It's always the thing you'll get to once the current thing ships.
All of those jobs were important, and all of them lost to whatever was on fire that week.
That's the work that moved over. The tests now run every night against the real app. The dependency updates get validated while I sleep and arrive as a recommendation. The numbers land on my phone every morning whether I ask for them or not. None of this replaced something I was doing well. It replaced something I did badly, once in an eternity, and always starting from zero.
Doing it every day is a different job
This is the part I didn't see coming, and it's the reason I think it matters beyond my own setup.
When you do something once a quarter you start from nothing every time. There's no baseline, you don't remember what you concluded last time, and you have no idea whether you're getting better at it. You produce a snapshot, you feel informed for a day or two, and three months later you do the whole thing again from scratch.
When it runs every day it starts leaving things behind.
It also helps that none of this is me sitting at a prompt asking for things. These are loops. They run on their own schedule, they hand back something I have to sign off on, and whatever came out of the last run is where the next one starts.
The clearest example is the marketing side. Every action gets written down as a prediction first: what should change, by how much, how it's measured, and on which date I judge it. On that date it gets scored: confirmed, refuted, or wrong for a reason nobody saw coming. Once a week the whole ledger gets audited and the hit rate recalculated.
The current score isn't flattering and it's not supposed to be. The predictions are wrong quite often, which is the whole point of experimenting with small things, measuring them and then deciding whether to go deeper or drop it. What interests me more is what grows out of the misses. There's a rule now that a good hit rate on the numbers must never hide a bad premise underneath, and it exists because of one week in June where the metrics looked excellent and half the reasoning was wrong. The rule is written down with the date and the evidence attached, and it applies to every decision made since.
So the shift isn't more output. It's a self-improving loop: the mistakes turn into rules and the rules make the next round better. You can't get that from a job you do twice a year, no matter how good you are at it, because there's nothing to accumulate.
The machine prepares, I commit
One line runs through all of this and I didn't plan it. I noticed it afterwards, in two completely different places.
Nothing an agent does on my code gets merged automatically. It tests, diagnoses, fixes and explains itself, then it opens a pull request and stops. The last move is always mine.
Then I looked at the design document for the next version of Franz Mail, where the AI drafts your replies for you, and found this written down as a founding principle months ago: Franz writes, the user sends. No automatic sending, ever.
Same boundary, drawn twice, for the same reason. The machine does the preparation and a human commits.
I'm not precious about this because of some principle about human dignity, it's practical. Everything upstream is only worth something as long as that last step stays real. The moment approving becomes a reflex, nobody is checking the preparation anymore, and then you've just built a very fast way to be wrong.
It did not give me my time back
The version of this story where AI hands you your evenings back is not the one I'm living.
I still work a lot. A normal day, and then quite often another few hours in the evening once the house is quiet. That hasn't really changed.
What changed is the shape of it. I can start something big just before I leave, a piece of work or a long test run or a research job, and it carries on without me. When I check back hours later it has made progress, and if it hit a point where it needed a decision, that decision is sitting there waiting. It's quite patient. Nothing gets worse because I answered at nine in the evening instead of three in the afternoon.
And it's not only waiting either. Usually what it needs from me is small. Yes, do it that way. No, not that one. Take the second option. Half a minute of answering from wherever I happen to be, and it runs on for another few hours. A decision that costs me 30 seconds is often the only thing between a job that's stuck and a job that's done by the time I sit down in the evening.
This is what lets me pick my kids up at two, or take half a day for sport. I'm not running the company from my phone at the school gate. The work just waits. A build that failed at three in the afternoon used to mean the afternoon was gone. Now it's something to read when I next sit down.
With two kids and no colleagues that's been worth more to me than fewer hours would have been.
If you're running something alone
Don't start with the impressive thing. Start with the list you already have in your head: the jobs you know are important, that you actually mean to do, and that lose every week to whatever is urgent. The dependency updates. The tests you run when you're already nervous. The numbers you look at when something feels off.
Pick one. Make it happen on a schedule instead of on a feeling.
Then the part people skip: make it leave something behind. A file of what got decided and why. A record of what you predicted and whether it happened. If every run starts from nothing you've automated a chore, which is fine, but that's all it is. If every run inherits the last one, you've started something that gets better on its own.
If you work in a team
The usual version of this conversation is about doing the same work with fewer people, and that's not what I'm describing.
Nothing on my list was taken from anybody. It came off the pile that never gets to the top. Every team I've ever worked with has that pile: the flaky tests everyone agreed to ignore, the dependency PRs nobody reviews, the accessibility pass, the docs that went stale in March, the competitor check somebody does the week before the offsite. Nobody is doing that work today, so there's no job to lose.
That's a much easier place to start than the middle of somebody's actual role, and it's where this stuff is least threatening and most obviously useful. Which matters quite a lot if you want people to try it instead of quietly resisting it.
The second thing that transfers has nothing to do with code. Don't accept AI output unless it arrives with evidence you can check in 90 seconds.
For my tests that means the pull request has to say, per failure, whether it decided the app was broken or the test was, and it has to have watched the failure happen before it's allowed to fix anything. For a report it means the numbers carry their source. For a translation, somebody who actually speaks the language signs off. And for anything you can't verify up front, you write down what you expect to happen and the date you'll check.
That rule is worth more inside a team than it is for me alone, because a team already runs on trusting each other's work. Evidence is how you keep the speed without lowering the bar.
Which brings me to the part I owe some developers an answer on. I wrote earlier this year that product people are in a good position to operate this way, and that being able to build has gone from the entry fee to a bonus. That didn't land well with every developer who read it, and I get why.
Here's the other half of it, and a year of working like this has made me more sure of it rather than less. The judgment that used to go into writing the code now goes into catching what's wrong with it, and that's a harder job than it was, not a smaller one. The amount of plausible-looking work arriving in front of you every day has gone up enormously and almost all of it reads well. Someone who can look at a change and feel that it's superficially right and structurally wrong is the most valuable person in a setup like mine, and that instinct only comes from having built and maintained things for years. You can't hire around that and you can't prompt your way past it. Nothing in my week would be safe without it.
What this series is
Over the next weeks I want to go through this properly, one piece at a time: how the overnight testing actually works and what it took to make it trustworthy, the dependency updates I never had time to check, what happens when the thing writing your tests is the thing being tested, and why a marketing agent that's wrong most of the time is still worth having. The last one is about the only thing in all of this that no machine has given me: what my customers tell me when I actually talk to them, which is quite often the opposite of what the dashboard says.
None of this is theory. It's just what my Tuesday looks like.
If you're a founder working out how much of this you can hand over, and where the line should sit, that's the work I do with teams. Let's talk.
