Why side projects stall at 80% (and how to ship)

Side projects rarely die at the start. They stall at about eighty percent, once the interesting problems are solved and only the boring visible ones are left.

That is the wall: auth works, the hard algorithm works, and what remains is empty states, the settings page, error copy, a landing page, and deciding on a name. None of it is fun, all of it is required, and none of it produces the feeling that kept you going for the first eighty percent.

Calling that a motivation problem is why it keeps happening. It is a structure problem.

Define "done" before you build anything

Write, in one sentence, what has to be true for the project to be finished. Not the vision — the finish line.

"A stranger can sign up, create one list, and share it" is a finish line. "A really good task app" is not, because nothing can ever satisfy it, which means you can work forever and never arrive.

The sentence should be short enough that at eighty percent you can read it and know exactly what is left.

Ship the ugly version to one real person

Not a launch. One person who is not you, using it for something real.

This is the single highest-value move available, and almost everyone delays it until after the polish — which is backwards, because that person will tell you that half the remaining twenty percent does not matter and one thing you had not planned does.

You cannot get that information from thinking about it, and you cannot get it from friends who say it looks great.

Put it in the week, not in the weekend

Projects that live only on weekends die on the first busy weekend, and there is always a busy weekend.

Two hours on a Tuesday evening, in the calendar, beats an aspirational Saturday. The point is not the hours — it is that the project keeps existing in your normal week rather than needing a special occasion.

Keep a log, because momentum is invisible otherwise

At eighty percent, the work stops looking like progress. Three evenings of error handling feels like nothing happened, even though the project moved further than the week you built the fun part.

One line per session about what moved is enough to see that. Without it you are judging momentum by how the work felt, and boring work always feels like stalling. This is the same reason most productivity systems fail — nothing records what actually happened, so you are left guessing.

The boring twenty percent, in order

When you hit the wall, do them in this order: whatever blocks a stranger from using it, then whatever makes it not embarrassing, then everything else. Most of "everything else" turns out to be optional once someone is actually using the thing.

When to kill it

If the finish line has not moved in a month and you feel relief rather than frustration about that, kill it. Write down what you learned and take the evening back.

A project you keep restarting costs more than one you end deliberately. Ending it is not failure — carrying it around for a year is.

The short version

• One sentence that defines done, written before you start
• One real user before the polish, not after
• Two hours in the working week, in the calendar
• One line of log per session so momentum stays visible
• Kill it if the finish line has not moved in a month

If you want the week planned around the finish line and a record of what actually moved, that is what KyzenX is for.