When the SaaS Co-Founder Who Wrote the Codebase Walks: A PE Operator's Replacement Playbook

The git log nobody read during diligence

The quality of earnings looked clean. ARR was sticky, net revenue retention was north of 110%, gross margins held. So you closed. Then, eighteen months later, you finally pull the git history on the core billing service, and one author name accounts for sixty percent of the commits that still touch production. That name belongs to the technical co-founder. And the email in your inbox says they're leaving the week their earnout vests.

This is a different animal from a hired CTO resigning. A salaried executive leaves with a network and a methodology. A technical co-founder leaves with the only mental model of why the schema is shaped the way it is, why that one cron job must run before the nightly export, and which "temporary" hack from 2019 is now load-bearing for your three largest accounts. They didn't manage the platform. They are the platform's documentation, stored in a format you cannot back up.

In diligence we underwrite key-person risk reflexively when the founder is the brand or the top salesperson, and valuation specialists routinely apply discounts of up to 25% where that dependency is acute. We rarely run the same exercise on the person who can still deploy to main without a code review. That omission is how a clean QofE produces a platform that can't ship a security patch the quarter after its author leaves.

The earnout cliff is a countdown, not a contract

Here's the trap specific to a co-founder, as opposed to any other engineer who quits: the earnout creates the illusion of retention. For twelve to twenty-four months they stay, they keep merging, the roadmap moves, and everyone exhales. What's actually happening is that the single point of failure is deepening. Every feature they personally ship during the earnout is a feature only they understand. The retention period isn't buying you a transition. It's compounding the dependency while you're not looking.

So the clock matters, and the clock is unfriendly. If you wait until notice is in hand to start an external search, you're looking at a four-to-six-month executive search timeline before a permanent replacement is even seated, never mind productive. And the all-in cost of that replacement runs to roughly 200% of annual salary once you load in recruiting fees, sign-on, and the productivity lost while a stranger reverse-engineers a codebase with no map.

And replacement is the wrong frame anyway. Say a 60-person vertical SaaS company has a co-founder who hand-built the multi-tenant architecture. The instinct is to find another brilliant architect. But the person who can hold an entire codebase in their head is, almost by definition, the person who never had to write it down — which is precisely the trait you are trying to engineer out. The original-author CTO optimizes for shipping the next thing fast. The scaling CTO optimizes for ten engineers being able to ship safely without them. The friction of forcing the first into the second is usually what triggered the exit in the first place. Don't replicate the dependency in a new hire. Dismantle it. The numbers say the odds of a hired tech executive succeeding without a clean handover are closer to one in five anyway.

Run the exit as an extraction project with a deadline

Stop negotiating to keep them. Re-cast the remaining earnout window as a fixed-scope knowledge-transfer engagement, with the co-founder as the source, not the owner. Here is what that looks like on a calendar.

First, map the dependency surface, not the code. Don't ask for code comments — you'll get nothing useful and lose two weeks. Ask three questions and watch the answers. Where in the system does a single failure take the product down? Which credentials, certs, or vendor accounts live only in their personal password manager? Which customer-specific behaviors are encoded in their head rather than in config? The honest gaps from that conversation are your remediation backlog, and they map directly to the discount a future buyer would otherwise apply.

Second, pair them out instead of writing them out. Documentation produced in isolation rots on contact. Instead, sit a mid-level engineer or an interim lead beside them and have the co-founder do the work while narrating — screen shares recorded, transcripts kept. You're capturing the why behind decisions, which is the part that never makes it into a wiki and the part that's expensive to relearn at 2 a.m. during an incident.

Third, bridge before you hire permanently. A CTO hired in a panic inherits an undocumented mess and tends to churn inside a year, which resets the entire clock. Seat an interim operator whose mandate is explicitly not to innovate — it's to stabilize, document, and prepare a clean seat for the permanent leader. Done right, the eventual hire walks into an operating system instead of a haunted codebase.

If notice is already in hand and you're inside the 48-hour window, start with our CTO-departure stabilization plan, then run the deeper dependency review using the operating-partner tech audit framework. A co-founder's exit isn't the threat to your thesis. The undocumented platform was always the threat — the exit just put a date on it. Use the date.