Leadership · June 12, 2026 · 14 min read

Building for the Day You Leave: How I Engineered My Exit From Zepargn

Three years of building, eighteen months of hiring and training, twelve months of progressive disengagement. Now I'm an advisor and the product runs without me. The playbook on the three layers that make a founder-handoff work: the system, the people, the principles.

Most founder-handoffs are emergency handoffs. The founder leaves and the company panics for six months, slowly excavating what was in their head. The wiki is half-empty. The decisions look arbitrary in retrospect because the reasoning was never written down. The team carries on, but slower, and missing the point of half of what was built.

I wanted Zepargn’s handoff to be different. Three years of building, eighteen months of hiring and training, twelve months of progressive disengagement. Today I am an Zepargn advisor. The product runs. The team ships. Active users grow. I am not in the on-call rotation, not in the daily Slack, not in the weekly leadership meeting. The architecture I described in a previous post is the system side of that handoff. This article is everything else: the people, the principles, and the schedule.

If you are a founder who plans to ever do anything else, this is the playbook I wish someone had handed me three years ago.

What “engineering an exit” actually means

Most people think of a founder handoff as an event. Onboarding document, a few weeks of shadowing, hand over the keys. That is not a handoff. That is a resignation.

Engineering an exit is an eighteen-month architectural project whose goal is to make yourself optional. The work is distributed across three layers, and it has to be planned and executed in roughly this order:

  1. The system layer. The code, the runbook, the observability, the CI/CD. The infrastructure that makes the product debuggable, deployable, and reversible by anyone other than you.
  2. The people layer. The hires, the trainings, the relationships that get transferred. The team that takes the codebase to a place you would not have taken it alone.
  3. The principles layer. The written taste, the decision frameworks, the “here is how we think about X” documents that let people make calls without you.

Skip any of the three and the handoff fails in a predictable way. Skip the system and the team firefights instead of shipping. Skip the people and the system runs without intelligence on top of it. Skip the principles and the team disagrees on every non-trivial call because they have no shared model of “good.”

The system layer (covered briefly)

I have written about this in depth elsewhere, so a short summary will do.

The principle that ties these together: information asymmetry is the founder’s biggest exit risk. Everything you know that the team does not know becomes a critical dependency on you. Reduce it deliberately, by writing things down where the team will actually find them.

The people layer

This is the part most founders get wrong, including me at the start.

Hiring for owners, not executors

The wrong mental model is that you hire people to execute the roadmap you draw. The right mental model is that you hire people who will, eventually, draw a better roadmap than you can. The first hires for Zepargn were executors. They were great at the tickets I wrote and useless when the ticket they got was wrong. Two of the hires after that were the same shape, and I did not catch it until they had been on the team six months.

The shift in the interview process, after that lesson:

Out of the five engineers I eventually built the team with, three came in with no prior fintech work and were the strongest hires of the cohort. The discipline they brought from other serious domains was more important than the operator-specific knowledge they could acquire in a quarter.

Training the junior PM (the part I learned the hardest)

Hiring a junior PM into a founder-led product is the most delicate hire you will make. The wrong version of this hire produces a coordinator. The right version produces your successor.

What I did differently from the way I was trained as a junior PM:

I narrated decisions, not just delegated them. For the first six months, every product call I made was accompanied by a written decision (in the repo, in a Loom, or in the weekly note) that explained the reasoning behind it. Including the calls that turned out to be wrong. Especially those. A junior PM cannot read your taste by watching the output; they have to see the reasoning before the output.

I forced disagreement early. Every monthly review included one explicit prompt: “tell me one decision I made this month that you would have made differently, and why.” The first three months produced safe disagreements about minor things. By month five they were pushing back on roadmap calls and they were right twice out of three times. The ratio of pushback to deference is the most reliable indicator that a junior PM is becoming a real one.

I gave them ownership of a vertical, not a slice. The first thing I handed over fully was Zlock, the term deposit product. Strategy, roadmap, metrics, hiring input, customer interviews, post-launch retros. Not just "execute on the spec I wrote" but "this is your product and your decisions hold." Giving a junior PM a vertical they own is harder than giving them work to do, and it is the only thing that actually trains the role.

I exposed them to the boardroom early. Joined every quarterly board update from month four onward, presented the second one themselves. Founders gate the boardroom too long out of a misplaced sense of seniority. A junior PM who has been in the boardroom is a different professional from a junior PM who has only been in the standup.

Today that junior PM is leading the product side of Zepargn. Hiring decisions, roadmap, weekly reviews, board updates. The single highest-leverage decision I made on this product was hiring them eighteen months in, and the second-highest was deciding to actually transmit my taste to them instead of just my tickets.

Handing over the operator relationships

In consumer fintech, the operator relationships (mobile money, aggregators, banking partners) are quietly half the product. The ops lead at MTN takes my calls because we have worked together for two years. That is a real asset, and it does not transfer through a doc.

The protocol I used, repeated for each operator:

  1. Three handoff calls. First call: I introduce the new owner from our side, I run the conversation. Second call: the new owner runs it, I am in the room. Third call: I am not invited.
  2. A written brief on every operator: who they are, what we built together, what blew up in 2024, what they care about, who has power on their side.
  3. A standing invitation to ping me for the first six months on calls where I might have context. After six months I declined half of them.

The principles layer

The third layer is the one that lets the team make decisions on the days I am unreachable.

The product principles document

Two pages. Pinned in Notion. Read at every new-hire onboarding, referenced in every PR review where a design call is being made. Six principles, each one a short statement followed by a paragraph explaining what it rules out:

These were not principles I imposed top-down. They were principles I extracted by writing down the rejected counter-arguments from three years of internal debates. Each one is a record of a real disagreement that had a winner.

The roadmap template

I stopped maintaining a roadmap as a list of features in month sixteen. The new format, used at every quarterly planning since:

That template, used consistently, lets the team plan a quarter without me. It also lets me look at a quarterly plan as an advisor today and tell, in five minutes, whether the planning is rigorous or vibes.

The disengagement schedule

Twelve months of progressive withdrawal, paced so the team had time to absorb each handoff before the next started. The schedule I followed, approximately:

The pace mattered. Pulling back faster would have left the team scrambling on capabilities they had not yet absorbed. Pulling back slower would have prevented them from growing into the gaps. The twelve-month window felt long while I was inside it. In hindsight it was the minimum.

What advising actually looks like

The shift from operator to advisor is also a shift in what you are useful for. The transition takes a while to internalise.

I am no longer the best person to ask for tactical advice. I am too far from the data, too far from the operator nuances of the current month, too far from the team’s daily friction points. Any tactical advice I give is, at best, six months stale. I have learned to decline those questions and route them back to the people closer to the work.

I am, however, the best person to ask for “why did we decide X in 2024” questions, and for “here is a big strategic move we are considering, what are we not seeing?” questions. Long-horizon strategy and context recovery are what advisors are uniquely positioned for. The further I get from the day-to-day, the more useful I become for the few things that need an outside view.

The mental shift, stated as a rule: an advisor is more useful when they are rarely needed than when they are constantly needed. If the team is calling you weekly, you have not actually handed off; you have just changed the cadence of your own operational work.

The signs the exit worked

Six honest tests I apply, in roughly increasing order of importance:

  1. I am not in the on-call rotation. (Easy test.)
  2. I do not get pinged for normal product decisions. (Easy test.)
  3. The product grows in my absence. Not flat, not slowly declining. Actually grows. (Medium test.)
  4. The team disagrees with me, ships their version, and they are right more often than they were a year ago. (Hard test.)
  5. New hires happen without me writing the spec or sitting in the loop. (Hard test.)
  6. The principles document gets edited by the team, with principles I would not have written, that improve on the version I left. (Hardest test.)

Zepargn passes all six today. The last one took the longest. The team rewrote one of my six principles last quarter (the wording of "Ship for the median user, not the median engineer" became "Ship for the user whose phone is two generations old") and the new version is better than mine. That edit is the test that finally said the exit was real.

Three things I would do differently if I started over

1. Write the runbook before the first incident, not after. The runbook would have been a third the length if I had started writing it from the first deploy, and the team would have had it months earlier.

2. Write the decision log from day one. Three years of decisions are partially lost because the early ones live in my head. The log started in year two. Half of what should be in it is reconstructed from memory, badly.

3. Hire the junior PM eighteen months earlier. The default PM-to-engineer ratio at small companies is wrong. Hiring one junior PM at year one, instead of year two, would have given me a successor a year earlier and shaved a year off the exit timeline.

What this taught me about leadership

Building for the day you leave is not selflessness. It is the only path to scale beyond yourself. The founder who cannot leave is the founder who cannot build anything new. The product that cannot survive its founder is not a product, it is a project.

The job of a CTPO at the founder phase, restated: design the conditions under which the room runs without you. The runbook, the decision log, the principles document, the junior PM you trained from year one. These are the artifacts. The artifacts outlive the person.

Zepargn is still running. The team I trained is shipping the credit product extension this quarter, the OAuth import is in beta, the metrics keep climbing. None of it is my work anymore. All of it is. That is the test.