If your MVP depends entirely on one developer's knowledge, you have a bus factor of 1, and you're one unavailable person away from a project stall, regardless of whether that unavailability is ghosting, illness, or just a sudden new opportunity.
Here's what minimum-viable documentation looks like for an early-stage MVP, achievable without slowing down development meaningfully.
Architecture overview (1 page): What the major components are and how they connect. Doesn't need to be exhaustive. It needs to be enough that someone else could orient themselves without weeks of code archaeology.
Decision log:
Why did we choose X over Y?
What were we optimizing for?
What would make us reconsider this choice?
Five minutes per significant decision. Saves weeks for whoever inherits the project.
Setup and deployment notes: The undocumented stuff that lives only in one person's head, environment variables, deployment quirks, third-party service configurations. This is consistently the hardest thing to reconstruct after a developer disappears.
Milestone-based deliverables with explicit "what's done" criteria: Not just code shipped. A brief explanation of what was built and why, attached to each completed phase.
Code comments at decision points: Not comments explaining what the code does. The code should do that. Comments explaining why a non-obvious approach was chosen.
None of this requires a large time investment relative to the cost of reconstructing it after a developer becomes unavailable, which research suggests can take 4 to 12+ weeks of recovery time.
Full breakdown on the resilient MVP framework: → https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp (foundersbar.com)
Top comments (0)