Working Myself Out of the Job

Context

Most founding engineers face the same trap. They are the fastest path to shipping, so every critical feature routes through them. That makes the company fast early and fragile forever: the founder becomes a single point of failure, the team never owns the hard parts, and the founder cannot actually do the CTO job because they are still doing the senior-IC job.

As co-founder and CTO of *not less but better*, across the first app (nlbb) and the digital-wellbeing product it became (Wellspent), I set myself the opposite target from the start: build a team and a platform good enough that the product ships without me on the critical path, while I move up the leverage curve from author, to architect, to enabler. Done right, the ultimate test of that strategy is whether the founder can eventually leave without the product stalling. I got to run that test for real.

Challenge

Making yourself replaceable is easy to say and hard to prove. The work has to hold two things at once: the company keeps shipping at pace while a growing team takes ownership of the parts that used to live only in the founder's head. Reduce your involvement too slowly and you stay the bottleneck; too quickly and quality and direction fray.

The progress is also easy to fool yourself about — a feeling of having "delegated more" is not evidence. The honest scoreboard is the git history, so that is what I measured this against, across five years and two codebases.

Contribution

I analysed the full history of both apps — every branch and worktree — attributing authorship across my identities and excluding vendored third-party source so the numbers reflect authored work rather than dependency drops.

On the shipping branch, my share of commits fell across five years from near-total to single digits:

• 2020, nlbb: 97.7% of commits were mine, in a team of three
• 2021, nlbb: 83.2%, as the first real hires landed
• 2022, Wellspent: 53.7%, in a team of six
• 2023, Wellspent: 51.6%, still a team of six
• 2024, Wellspent: 8.0% — the product now shipped without me at the keyboard

Two things show this was deliberate specialisation, not disengagement. The peak of my output came in the middle, not the start: in 2023 I authored most commits during my tenure, while being only half the total, because the team was shipping just as hard. And as I handed off features, I kept the platform — classifying every commit by the files it touched reveals a widening gap between the product work I gave away and the platform work I held onto.

The shift ran in three phases. In the founder-solo years (2020–21) the first app was 98% my code — necessary then, a liability if it had stayed that way. As principal engineer and team lead (2022–23) I ceded the majority of feature volume but absorbed the largest structural changes — the year I contributed the most raw code was the year I owned the architecture, the data layer, and the state-management migration — while taking near-total ownership of continuous integration, release automation, and developer tooling. By 2024 I had become an enabler and platform steward: 5% of feature code but still roughly half of the build system and most of the tooling. The team owned the product; I owned the rails, and got out of their way. The last hard thing I built was the company's first B2B pilot, a partner integration with Babbel that later became the basis of its acquisition.

Lasting Influence

In early 2024 two things converged. I was carrying real burnout — from operational load, but as much from mission drift. nlbb had been built impact-first, funded by impact investors rather than venture capital, and the strategic direction my co-founders wanted to pursue, a turn toward B2B and ad-tech, diverged from the values I had optimised the company around. No hard feelings, but a genuine divergence of compass. I stayed long enough to see the hardest technical problem through — the Babbel pilot — and then, in June 2024, concluded my operational role. The handover was short, not because I rushed it, but because there was little left that lived only in my head.

That is the part I am proudest of. Anyone stubborn enough can be a one-person engineering department for a while; the 98% at the start proves only endurance. The 8% at the end, with the product still shipping and the technical cofounder able to walk away cleanly, is the number that reflects a team I built and a platform I designed to make my own daily involvement optional.

The lesson now sits at the centre of my consulting practice. The dependency worth retaining is the highest-leverage, lowest-headcount surface — the build systems, release pipelines, and tooling that let a small team move fast and safely. Everything else should be deliberately, legibly handed off, phase by phase, so that the clearest proof of an organisation rather than a dependency is simple: it keeps working after you leave, and you can leave, on principle, without breaking it.