Should I charge for the handoff?

Sometimes. For code/business projects with real value, a handoff fee or revenue share is reasonable. For personal projects (writing, art, music, learning), handoff is usually free. The 41% revival rate is a function of the handoff, not the price.

How do I find someone to hand off to?

Three channels: (1) your existing community (Twitter followers, newsletter subscribers, Discord members), (2) the BreakPoint drop flow, (3) targeted outreach to people who've expressed interest in the project domain. Most handoffs happen through existing relationships, not cold outreach.

Guide · Universal

How to hand off any project

Q: Why bother with a handoff?

Because the 41% revival rate from the 2019 arXiv study applies only to projects with a handoff mechanism. Without one, the revival rate is much lower. Most abandoned projects never revive not because no one cares, but because no one can find them or doesn't know how to take them on. The handoff is the enabler.

Q: What's the minimum handoff documentation?

Three things: (1) the original intent (why you started, what you were trying to do), (2) the current state (what works, what doesn't, what's left), (3) the next action (the single most important thing the new owner should do first). That's it. The minimum handoff is 1-2 pages.

When you can't continue but you want someone else to. The 7-step handoff process for code, writing, art, music, home, business, and learning projects. Increase the 41% revival rate by handing off well.

Published July 13, 2026 · ~6 min read

The 41% handoff

Per a 2019 arXiv study, 41% of abandoned open source projects come back to life — but only when there's a handoff mechanism. The handoff mechanism is the difference between a project that gets a second chance and one that dies in place. The mechanism is simple: a public place where the project is described, where a new owner can find it, and where the original owner can describe what's left. This guide walks through the 7 steps of that handoff.

The 7 steps

Step 1: Decide to hand off (don't drift)

The first step is the decision. Don't drift into a handoff — the project deserves a real announcement. The decision is: "I am handing off this project. Here is the documentation. Here is the new owner (or, here is the place where the new owner will be found)."

Step 2: Write the original intent (the "why")

A 1-2 paragraph description of why you started the project. What problem you were trying to solve. Who you were trying to help. What success would have looked like. This is the most important part of the handoff. The new owner needs to know not just what the project is, but why it exists.

Step 3: Document the current state (the "what")

A precise description of what's done and what isn't. For code: which features work, which are partial, which are abandoned. For writing: which chapters exist, which are drafted, which are outlined. For art: which pieces are done, which are in progress, which are sketches. The state doc is the new owner's roadmap.

Step 4: Identify the next action (the "now")

The single most important next step. The new owner should be able to read this and start working within 24 hours. "Add OAuth support" is a next action. "Refactor the auth layer" is not. The next action is the smallest concrete step that moves the project forward.

Step 5: List the resources (the "where")

All the URLs, files, accounts, and platforms the new owner needs. Repository URLs. Hosting accounts. Domain registrar. Newsletter list. Social media accounts. Design files. Supplier contacts. The resource list is what the new owner needs to take over operationally.

Step 6: Identify the audience (the "who")

Who uses / reads / listens to / enjoys this project? The new owner needs to know the audience to communicate with them. For OSS: contributors, users, dependents. For writing: readers, beta readers, agents. For music: listeners, playlist curators. The audience is the new owner's most valuable asset.

Step 7: Announce publicly, drop on BreakPoint

The final step is the announcement. Publish the handoff doc. Drop the project on BreakPoint. Tweet the handoff. Email the audience. Tell your community. The handoff that no one knows about is not a handoff — it's a private goodbye. The handoff is a public event.

The 4 handoff archetypes by project type

Code: maintainer-to-maintainer handoff. Transfer repo ownership, write the handoff doc in the README, set up co-maintainers in the registry, announce on the project's website.
Writing: author-to-co-author handoff. The new author finishes the manuscript, the original author retains credit. Rare for solo handoff — co-authoring is more common.
Art / Music: creator-to-co-creator handoff. The artifact is more personal. Co-creation or a "remix with credit" model is more realistic than a clean handoff.
Home / DIY: owner-to-owner handoff. Less common — most home projects are too tied to a specific physical space. But documentation as "lessons learned" can be valuable.
Business: founder-to-founder handoff. The most common handoff archetype in the real world. The new founder takes over operations, the original founder moves on.
Learning: learner-to-learner handoff. The artifact is the notes, the study plan, the highlights. Handoff is "here's what I learned, you take it from here."

Frequently asked questions

What is a project handoff?

A handoff is the act of transferring ownership and context of a project from one person to another.

Why bother with a handoff?

The 41% revival rate from the arXiv study applies only to projects with a handoff mechanism. The handoff is the enabler.

What's the minimum handoff documentation?

Three things: original intent, current state, next action. That's it.