What if I'm embarrassed to abandon?

Embarrassment is a bad reason to keep going. The sunk cost fallacy says “I’ve already invested 2 years, I can’t stop now.” The truth: the 2 years are spent regardless. The next 2 years are a choice. Choose the next 2 years deliberately, not by inertia.

Guide · Universal

When to abandon a project

Q: What's the difference between abandoning and drifting?

Abandoning is a decision made with eyes open, communicated publicly, and closed with grace. Drifting is the slow fade — the project dies by not-being-worked-on, with no announcement, no final commit, no clear end. Drifting is bad because it leaves the original creator (and any users) hanging. Abandoning is good because it gives everyone closure.

Q: Should I tell people I'm abandoning?

Yes. Always. The announcement is the closure. It can be a single line in the README, a final commit message, a blog post, or a BreakPoint drop. The act of announcing is the act of completing the abandonment. An unannounced abandonment is just drift.

Q: How do I know if I'm abandoning or just stuck?

Stuck has an exit ramp — there's a specific blocker and a path past it. Abandoning is when the path past the blocker costs more than the project is worth. If you can describe the blocker in one sentence, you're stuck. If you can't, you're probably abandoning.

The opposite of "finish what you started" is "know when to stop." This is the 7-question checklist for deciding whether to keep pushing or to abandon your project with grace. For code, writing, art, music, home, business, and learning projects.

Published July 13, 2026 · ~5 min read

The hardest question

"Should I keep going?" is the hardest question in any project. The instinct is to say yes — sunk cost, momentum, identity, the social cost of admitting defeat. But sometimes the right answer is no. The trick is being able to tell the difference between "I should keep going" and "I should stop." This guide is the 7-question decision framework for that.

The 7-question checklist

Answer yes or no. If you answer "no" to 3 or more, abandon. If you answer "yes" to 5 or more, keep going. The middle (4-5 yes, 2-3 no) means: try one more sprint, then re-evaluate.

1. Is the original motivation still alive?

Why did you start? Is that "why" still there, or has it become abstract? The original motivation was specific: "I want to learn Rust by writing a CLI tool" or "I want to write a memoir about my mom." If the original motivation has become a vague sense of "I should finish what I started," the project is dead. The motivation is the project. The work is just the artifact.

2. Is the project still solving a real problem?

For product/code/business projects: is there still a user? Has the problem changed? Has someone else solved it better while you were away? The market moves on. The project that solved a real problem 2 years ago may solve a problem that no longer exists.

3. Are the dependencies still alive?

For code: 3 levels deep, is the dep tree still maintained? For writing: is the genre still readable (some genres age poorly)? For business: is the supply chain / platform / market still standing? A project that depends on dead infrastructure is a project that's already dead — you just haven't noticed.

4. Can you describe the next action in 1 sentence?

If you can describe the next concrete action in 1 sentence ("The next action is to write chapter 4"), the project is alive. If you can't ("I should pick it up again sometime"), the project is dead. The next action test is the strongest test of project liveness.

5. Is the time you're investing proportional to the value?

Sunk cost is a fallacy. The time you spent is spent. The time you will spend is a choice. If the project requires 6 more months of weekends and the value is "I'd feel good if I finished it," that's a poor trade. If the value is "I want to learn X" or "I want to share this with the world," it's worth it.

6. Are you avoiding the project or the abandonment?

There's a difference between "I'm not working on it" and "I can't bring myself to work on it." If you're avoiding the project itself (opening the file, the canvas, the chapter), the project is the wrong thing. If you're avoiding the abandonment (the announcement, the closure), the project may be fine — you just need a forcing function for the abandonment decision.

7. Will you regret abandoning in 5 years?

Imagine yourself 5 years from now, looking back. Will you regret the abandonment? Or will you regret the continued investment? Most abandoned projects, in hindsight, were the right call. Most prolonged projects, in hindsight, should have been abandoned earlier. The 5-year test is usually the deciding factor.

The responsible abandonment ritual

If you decide to abandon, do it responsibly:

Announce it. README, blog post, tweet, BreakPoint drop. The announcement is the closure.
Document what's done. A summary of the state of the work. What works, what doesn't, what's left.
Open-source / hand off the work. If the work has value, let someone else take it. The 41% revival rate applies to all projects.
Archive the original repo / folder. Don't leave it half-private, half-public. Either commit to it being public, or archive it.
Update your portfolio. If the project is on your resume / portfolio, note the abandonment honestly. Most hiring managers respect "I built X to 80% and decided to focus on Y" more than "I built X to 100% but X never went anywhere."

Frequently asked questions

Is abandoning a project always a failure?

No. Abandonment is a feature of any healthy creative life. Most accomplished creators abandon more projects than they finish.

What's the difference between abandoning and drifting?

Abandoning is a decision. Drifting is the slow fade with no announcement.

Should I tell people I'm abandoning?

Yes. Always. The announcement is the closure.

How do I know if I'm abandoning or just stuck?

Stuck has an exit ramp. Abandoning is when the path past the blocker costs more than the project is worth.