A one-year plan to prove I had one. Here's what Project Phoenix actually was, what I got right, and what I quietly gave up on along the way.
Former Tanzanian, now happily repatriated European, back in my birth-place of Berlin. I enjoy the little things in life, as well as traveling, hiking and spending time with good friends.
A few weeks after I told the team I was staying — after the decision to keep building Mailbutler alone instead of winding it down — I wrote something for everyone to read. One line from it stuck: we embrace change and adapt to thrive, we rise from the ashes like a phoenix.
That line became the name of a company-wide, one-year restructuring plan. This is the story of what Project Phoenix actually was, what happened when I tried to live up to it, and what I got wrong.
The name wasn't a branding exercise. It was literal. The years before this had been rough. Technical changes on Apple's side had hit our Apple Mail revenue hard, and for a while it genuinely wasn't clear where the company was heading. We'd only run one project that touched the whole company like that before — New Horizons, our Apple Mail rebuild, which is honestly a story for its own post. Everything else had been smaller, more contained.
Phoenix was bigger. It was a one-year plan to restructure how we worked — team, product, process — presented right after I'd told everyone I was taking this on alone. I needed them to see more than good intentions. I needed them to see a plan.
We work virtually as a rule, so that's how I presented it — a video call, not a stage. I'd known most of the team for years by then, and I was fairly confident they'd get behind it. I didn't feel real pushback. What I did feel was a slight, reasonable skepticism: will this actually work? That felt fair. We'd never tried anything at this scale before, and skepticism from people who'd stuck around through the rough years wasn't a vote against me. It was them taking it seriously.
Phoenix had six parts: staying lean, building a product for the future, focusing hard on the product itself, distributing knowledge and ownership across the team, continuous growth, and transparency. All six mattered to me. But if I'm honest, one mattered slightly more than the rest — what I still think of as our flywheel.
The product has to be of high quality and solve real problems. Everything else follows from that.
That belief is the one I'd defend hardest today. Growth, retention, word of mouth — I think they're all downstream of getting the product right first.
Here's the part I didn't expect to be writing about honestly, but this series has never worked any other way. Part of the plan was that I'd step back from operations — less day-to-day involvement, less hands-on software development, more organization and oversight. A few months in, that stopped being realistic. The team got smaller, we wanted to push the product forward on several fronts at once, and I was needed where I'm actually strong: I'm still a software engineer at heart, still a product person. So I stayed in it. More recently I've pulled back in, not out — getting more hands-on with growth work like this very series, and with customer success, because that's where I think the flywheel idea has real, untapped potential right now.
I also dropped Holacracy entirely. It was on the original plan — a self-organizing structure for decision-making — and I presented the concept early on. It didn't survive contact with reality. For a team our size, it was simply too complex to be worth the overhead.
A one-year plan is a vision, not a contract. Being agile also means adjusting the plan while you're still executing it.
Neither of those felt like failures once I sat with them. They felt like the plan doing its job — giving us a direction firm enough to commit to, loose enough to bend.
Nothing on the list caught me off guard along the way, and I think that's actually the best outcome a plan like this can have. Not because nothing changed — plenty did — but because we'd built enough shared understanding early on that the adjustments felt like course corrections, not crises.
Project Phoenix feels done now. Most of what we set out to change actually happened — not all of it exactly as written, but the direction held. The company feels more stable than it did a year before, and it feels more like mine now, in a way it hadn't before I took this on alone.
I don't think the company feels more like mine despite the team. I think it's because of them.
We built this version of it together, not top-down, and I think that's part of why it stuck.
There's a next chapter to this story too, but it's not a continuation of Phoenix. Once Phoenix ran its course, it didn't just get a sequel with a new name — it got replaced by something with a different spirit entirely. Phoenix was about proving I had a plan and rebuilding from a shaky place. What came after started from somewhere else: not survival, but momentum. I'll get into what that shift actually meant, and give an honest check-in on how it's really going, next time.
A year before our 10th anniversary, my co-founder told me he was ready to move on. This is the story of the choice I faced next — and why I decided to keep going alone.
We hired a certification agency to help us get ISO 27001 certified. It didn't work out the way we expected — and the certification turned out to be far more manageable once we stopped following their playbook.
A lost tender taught us something we couldn't ignore: for larger companies, information security isn't optional — it's a checkbox. Here's why we pursued ISO 27001, and what actually changed inside Mailbutler once we did.
A couple of years ago, someone offered to invest in Mailbutler. I turned it down — not because the offer was bad, but because I never wanted a clock ticking on my decisions. Here's the philosophy behind eleven years of building this on my own terms.
Learn how we implemented an AI-powered support bot to improve our response times, reduce agent workload, and deliver round-the-clock answers to customer questions.
