I Have About 10 Half-Built Projects and Almost None of Them Have Launched

I have about ten half-built projects sitting around. Some are folders. Some are half-wired repos. Some even have domains. Almost none of them have launched. That is not a humblebrag. It is a tax I keep paying in attention.

If you build for a living — sites, products, tools, side projects — you already know the pattern. The first stretch feels electric. Architecture, clever ideas, visible progress. Then you hit 75% or 90%, the fun work is mostly done, and somehow a brand-new idea looks more honest than finishing the one in front of you.

This post is about that trap: why builders stall near the end, what “finished” actually means, and how to get through the last stretch instead of adding project number eleven.

The 75–90% trap

That zone feels productive because you can still open the project and feel like an operator. There is always one more feature, one more redesign, one more “quick” refactor. The identity of “I’m a builder” gets fed by activity — not by a live URL.

Starting is cheap dopamine. Finishing is exposure. At 80%, the remaining work is rarely the cool stuff. It is content, edge cases, deploy, pricing copy, analytics, the awkward “is this good enough for strangers?” question. Novelty dies. Risk rises. So the brain offers a rescue: a new blank canvas where you are brilliant again.

I have written about a cousin of this in sales — separating the closer from the chaser. Warmth gets the verbal yes. Systems collect the payment. Builders confuse the same jobs. The builder brain loves the chase of a new stack. The closer brain has to declare done and put it in public.

What does “finished” even mean?

This is where most of us lie to ourselves. “Finished” becomes a moving finish line so we never have to cross it.

For web builders and developers, a useful definition of finished is not “no more tickets forever.” It is closer to this:

• Live. There is a public URL (or a real install) a stranger can open without you SSH’ing for them.
• Usable. One primary path works end to end — signup, buy, book, read, download, whatever the point was.
• Owned. You would send it to someone without a ten-minute apology tour.
• Optional business path. If it is meant to make money or leads, there is at least one clear next step — even if it is ugly.

Finished is not pixel-perfect. Not every feature on the whiteboard. Not “maintainable for a decade.” Not “I would bet my reputation on every edge case.” Those are iteration goals. Iteration only starts after something exists in public.

Ship the ugly version or keep collecting almosts. Ninety percent done with no launch is still zero revenue, zero real user feedback, and zero proof you can close.

Why we bail before launch

The reasons are rarely mysterious. They are just uncomfortable:

1. Fear of judgment. As long as it is private, it can still be “going to be great.” Live means people can shrug.
2. Perfectionism dressed as standards. High standards are real. Using them to avoid a URL is not standards — it is stalling.
3. Shiny next idea. New projects restore the feeling of progress without the vulnerability of shipping.
4. No external deadline. Client work finishes because someone else is waiting. Personal and founder projects do not, unless you invent a finish line.
5. Identity saturation. Starting feeds “I build things.” Finishing threatens the fantasy of the perfect version still living in your head.

Same energy as collecting domains and calling it strategy. I wrote about that clutter tax in The Real Cost of Owning Too Many Domains. Half-built projects are the heavier cousin — they cost mental RAM every week you pretend they are still “in progress.”

Kill, park, or launch — the only three moves left at 80%

Finishing does not always mean forcing every corpse live. Sometimes the honest finish is deciding what the project is allowed to be.

• Kill. Delete or archive with a clear “no.” Free the attention. Dead projects still tax you if they sit in “someday.”
• Park. Write a one-line reason, a reopen date, and what “good enough to resume” looks like. Parking without a date is just quitting with better branding.
• Launch. Cut scope to the definition of done above. Put a date on the calendar. Ship the minimum that is live and usable.

When I actually finish hard things — like building our own member portal instead of renting another platform forever — it is because the finish line was clear and the alternative was more expensive than shipping.

How to get through the last 20%

Motivation is unreliable. Systems for finishing are not glamorous, but they work better than hoping you feel inspired on a Sunday:

1. Write the finish line before week two. Before you fall in love with the architecture, write: live URL, one user path, what you will deliberately leave out for v1.
2. One active unfinished project. Everything else is killed or parked. Starting #11 while #1–#10 are open is how the pile grows.
3. Timebox a launch week. Not “when it’s ready.” A week where the only job is the boring list: deploy, copy, forms, analytics, soft launch.
4. Separate builder brain from closer brain. Builder invents. Closer ships. Same person can wear both hats — just not in the same hour while inventing a new feature mid-deploy.
5. Make accountability public. Tell someone the ship date. Post the URL when it is ugly. Private goals renegotiate at 11pm. Public ones sting when you flinch.
6. Use tools to finish, not to start more. Cursor (and later agents like Punk) should accelerate the last stretch — tests, copy drafts, deploy chores — not spawn another half-built side quest.

If a tip fails, you will know because the screenshot of your open projects does not shrink. Good. Adjust the system, not the story.

What you get when you finish (even ugly)

Worst case: you launch something quiet and learn it was the wrong bet. That is still cheaper than carrying ten ghosts.

Best case: real feedback, real credibility, maybe real revenue — and mental RAM back for the next thing that deserves a start. Finished work compounds. Almosts do not.

Final thoughts

I am not cured. I still have half-built projects. Naming that is the start of treating finish as a skill — same as pricing, same as follow-up, same as closer vs chaser.

Finished is live and usable. Not perfect. The last 20% is where builders either become operators or stay collectors of almosts. Pick kill, park, or launch — then protect one active finish line until it has a URL.