You can feel it before you can describe it. Sprints take longer than they used to. Onboarding a new engineer used to take a week and now takes a month. The same kinds of bugs keep coming back. Every "small change" turns into a sprawl. The roadmap hasn't shrunk, but the team's capacity to actually ship against it has.
Most founders react to that signal by trying to hire more developers. Sometimes that's right. More often the team you have is competent and the codebase is the problem, and another mid-level hire makes the codebase worse, not better.
It's usually not a capacity problem
It's a structural one. The data model has drifted from the domain. The boundaries between services or modules have rotted. The API has accumulated a decade of "we'll fix it later." The test suite is technically green and practically useless. None of these problems are visible in the ticket queue. They're visible in the velocity.
A principal-level partner, someone who has seen this pattern enough times to recognise it on day one, can name the structural problem, pick the boring fix that pays back fastest, and ship it. That's the work I'm hired for.
How I plug in
Half-time, full-time, or advisory, whichever fits the shape of the problem. I prefer engagements that start with a few weeks of focused diagnosis (usually written up as a short, opinionated document) and then move into shipping. I work with the team, not around it: pair on hard things, leave a paper trail of decisions, and make sure the people staying behind understand the changes well enough to extend them.
No notice period, no minimum term, no contract churn. I scale up when there's serious work to do and step back when there isn't.
What I leave behind
A codebase that the existing team can move faster in. A short list of structural decisions, written down, with the reasoning intact so the next engineer doesn't have to relitigate them. Foundations that will still hold up when the team doubles, when the next round of funding lands, or when a partner asks to integrate.
In for the long term
Most of my clients have worked with me for years, not weeks. I'm not running a side business until a full-time job comes my way. I'm doing this because long-running, high-trust, technical relationships with serious operators are the best way I've found to make work that compounds. If we work together once and it goes well, I'll still be around when you need me next.
