The successor test: could another developer take over your app tomorrow?

Mik Bry · 2026-08-25 · ~5 min read · Launch Readiness · Documentation

Here's a question worth asking yourself today, before anything goes wrong: if you hired a developer tomorrow, could they open your project and actually pick it up — or would the first thing they tell you be "give me a week to read through this before I can quote you anything"?

That gap between those two answers is real money and real time, and it exists whether or not you ever change developers.

01 — What is it?

Software teams have a name for this risk: the bus factor — the number of people who could disappear from a project before it's in real trouble. A project with a bus factor of one depends entirely on whichever single person currently holds the context in their head. A widely cited 2016 study of 133 popular open-source projects on GitHub found that 46% of them had a bus factor of exactly one. Those were established projects with commit histories going back years. A solo founder building primarily with AI can easily end up with a bus factor of one, without ever consciously deciding that's the risk they're taking.

Reference: Avelino, Passos, Hora & Valente (2016), "A Novel Approach for Estimating Truck Factors," ICPC — checked 2026-08-25.

I call the version worth checking today the successor test: could you hand this project to another developer right now and get back a meaningful, fixed-price quote — without paying them a week just to figure out what your app does and how it's built?

Existing writing about "bus factor" or "handoff" almost always assumes a human predecessor the new developer can interview. That's not your situation. If your app was built with Cursor, Claude Code, Lovable, v0, Replit or similar, a lot of the why behind the code — the tradeoffs you discussed, the shortcuts you agreed to take, the "we'll fix this properly later" — never made it into a comment or a commit message. That context may live in an AI conversation that isn't part of the repository or accessible to the next developer. Reconstructing a decision from an old AI chat can be harder than reconstructing it from a human's memory, because at least you can still ask a human a follow-up question.

02 — Why should a non-developer care?

You don't need to plan for disaster to care about this. The cost shows up immediately, the first time you need outside help for any reason — hiring your first developer, bringing in an agency, adding a technical co-founder, or just asking a freelancer to fix one bug while you're busy elsewhere.

Without minimal documentation, many of those conversations start with some version of: "we need time to understand the code before we can quote the work." That week is not a hypothetical future cost. It's a cost you're already carrying today. That discovery time can end up reflected in the estimates you receive.

Think of it as the recipe versus the finished dish. Your running app is the dish — it looks and tastes right, and that's genuinely worth something. But a new cook can't reproduce it, extend it, or safely change one ingredient without the recipe: what's in it, why it's built that way, what happens if you swap something out. Most founders picture handing off a project like handing over a tidy binder — a clear README, a short "here's how it works," a list of decisions and why they were made. What actually gets handed off, most of the time, is the finished dish with no recipe at all: a working app and a closed chat window.

03 — What does good look like?

You don't need professional-grade documentation to pass the successor test. You need three things, each short enough to read in one sitting, and each low enough of a bar that you — a non-coder — can ask your own AI coding tool to draft it directly from your existing project:

• A README. What the app does, who it's for, how to run it locally, and where the important pieces live.
• A plain-English architecture summary. A few paragraphs, no diagrams required: what are the main parts (the app, the database, the payment provider, the email service, whatever else it talks to), and roughly how they connect.
• A decision log in plain language. Not a changelog of what changed — a short record of why the consequential choices were made, the kind of thing that used to live only in your chat history.

The bar here is deliberately low. As Tom Preston-Werner put it back in 2010, arguing for writing the README before the code: software without useful documentation is nearly worthless to anyone but the person who already understands it, and writing down your intent is what makes it possible for someone else to collaborate on it at all. That was true before AI-assisted coding existed, and it hasn't stopped being true now that the first draft of your code came from a conversation instead of from you typing it line by line.

Reference: Preston-Werner, "Readme Driven Development" (2010).

04 — What can I safely ask my AI agent?

This is a look-and-report question, not a "go write the docs" instruction. You're diagnosing the gap before you decide what to do about it — the same "not found" discipline as everywhere else in this series: an agent that can't find documentation should tell you it found none, not assume it doesn't need to write more.

Read the answer carefully. If the agent says it found no documentation at all, that finding is your first gap — not a sign the check failed. Sit with the list for a day before deciding what, if anything, to fix. That decision is yours; the prompt above only exists to make sure you're making it with the facts in front of you instead of finding out during an actual handoff.

This is one article in the Launch Readiness KB series. The successor test itself costs nothing and takes a few minutes — what you do with the answer is up to you, instead of a future developer's quote deciding it for you.