How to restart a stalled side project: find the stuck decision

I have a folder of projects that stopped. Not failed, stopped. Each one has a README that ends mid-thought and a last commit from a week I remember being busy. Every time I came back to one, the advice I found was about motivation: set a timer, find an accountability buddy, remember why you started. None of it helped, because motivation was never the problem. This is what did.

Why did it actually stall? The four real causes

Before you restart anything, work out what stopped it. The cause decides the fix, and the wrong fix feels like trying harder at the same wall. Almost every stalled project I have seen fits one of four causes. Run the question in the second column against yours.

Notice that none of the four is "I am lazy." That label is the one that keeps people stuck, because it has no fix. A decision has a fix. A scary step has a fix. If you can name which of the four you are in, you have already done more than most restart advice asks of you.

What is the stuck decision, and how do you make it badly?

The most common cause by far is the first one. Somewhere in the project there is a choice you have been circling: which pricing model, which stack, whether to rebuild the onboarding, whether to narrow the audience. Every session you opened the project, you hit that choice, felt the cost of getting it wrong, and closed the laptop. After a few of those, you stopped opening it.

You find it by reading your own last notes. Look for the sentence with a question mark in it, the TODO that moved from one list to the next, the branch you started and never merged. That is where the project is stuck.

Then give yourself permission to decide badly:

1. Pick the option you can reverse. If one choice is cheap to undo, take it. Most of these decisions are less permanent than they feel.
2. Write the decision in one sentence."It is free for now, and I will revisit pricing after ten users." Putting it in writing makes it real.
3. Set a review date. A decision with a date to revisit is much easier to make, because you are not signing up to be right forever.

This is the same trick behind shipping in public every day: shrink the commitment until it stops feeling risky.

What is the two-hour restart?

The restart is one visible change, small enough to finish in about two hours. Not the feature you were building. Not a refactor. Something another person could see or use that was not there this morning.

• Write the state of the project down: what works, what is broken, what you were about to do. Twenty minutes, plain text.
• Pick the smallest change that makes the project look alive, such as fixing the one broken link, updating the headline, or shipping the one feature that was nearly done.
• Deploy it. A change that exists only on your laptop does not count.
• Tell one person. A friend, a founder in a group, anyone who will reply with a sentence.

That last step is the one people skip, and it matters. A restart that nobody knows about is easy to abandon quietly. A restart one other person saw has a witness.

Should you restart it at all?

Not every stalled project deserves a restart, and an honest answer here saves months. The fourth cause in the table is the signal: you stopped believing in the question. When that is true, no amount of momentum fixes it.

Be careful about how you reason here. The time you already put in is not an argument for continuing. Economists call that the sunk cost problem: past spending that cannot be recovered should not drive the next decision. It cuts the other way too. A project that took a long time to build is not worthless just because you went quiet. Ask only the forward-looking question: if this worked, would I be glad?

• Yes, and I know the next step: restart it using the two-hour method above.
• Yes, but the product needs to change: read what to change before a relaunch before you touch the code.
• Maybe: give it one two-hour restart. If it still feels dead afterward, you have your answer.
• No: close it properly. Archive the code, say so publicly, and keep the assets. A clean close beats a slow fade, and it is a post in itself.

If you do close it, treat the repository with care. GitHub lets you archive a repository so it stays readable but clearly marked as no longer maintained, which is kinder to anyone who found it than leaving it looking abandoned. If you have paying users, a shutdown is a different job with obligations attached. I will cover that in its own guide.

How do you restart in public and explain the gap?

Say what happened, briefly, without apology theater. Three sentences do it: you paused, here is what changed in the meantime, here is what is new. Nobody needs a confession. They need to know the project is moving.

For a project with real users, a restart is also a small relaunch, and the rules in our guide to relaunching your product apply: a relaunch needs something genuinely different to point at. If you changed a decision, say which one. If you simplified, say what you cut. A restart with a reason reads as confidence. A restart with no explanation reads as a hobby.

This is also where the right audience matters. A restart posted into the void gets nothing. A restart shared with other founders who build, who can look at the result and say something specific, gets a reply, and a reply is what keeps you going on day three.

How do you stop it from stalling again?

The project stalled once because nothing was holding it in place. Tie the restart to a cadence you can hold on your worst week, not your best. One small shipped change a week beats a heroic month followed by silence. Our guide to shipping streaks for founders has the worksheet for designing one that survives a bad week.

Three habits make a restart stick:

1. End every session mid-thought on purpose. Leave a note that says exactly what the next task is. Lost context is one of the four causes, and a two-line note removes it.
2. Decide early, review later. When you hit the next hard choice, make the reversible call right away and put a date on it.
3. Keep one person in the loop. A weekly message to a peer is a lighter commitment than a full accountability system, and it works for the same reason.

Frequently asked questions