The Case for Leaving Projects Unfinished
A meal planner at 60 percent. A client portal that works and looks awful. Three stabs at a website. The pile of abandoned attempts is where skill comes from.
Anyone who builds things accumulates a graveyard. A meal planning app that is 60% done. A client portal that works but looks terrible. Three different attempts at a personal website. An AI tool that generated workout plans and got opened twice. A habit tracker that tracked no habits.
The productivity gurus would call this a problem. "You need to learn to finish what you start." "Discipline is choosing to do the boring work after the exciting newness wears off." "A finished bad project is worth more than an unfinished good one."
They're wrong. Or at least, they're missing the point.
Every unfinished project teaches something
The meal planning app is where connecting a database gets learned. The app never ships, and the skill shows up in the next six things. The client portal is where authentication stops being a word and becomes something you have done. Three personal websites teach three separate lessons about design, deployment and being found.
Each abandoned project is a class paid for in time rather than money, and unlike a real class you only study the part you were curious about.
The "finish everything" myth
This advice comes from a pre-AI era when building things was hard and slow. If a project took 6 months, yeah, you should probably finish it — you've already invested massive time and energy.
But in 2026? You can build a working prototype in 2 hours. The cost of starting something new is almost zero. Why would you force yourself to grind through the boring parts of project #47 when you could start project #48 and learn something new in the process?
The game has changed. The goal isn't to finish things — it's to learn fast and build skills. Unfinished projects are evidence of learning, not evidence of failure.
When finishing matters
I'm not saying never finish anything. Obviously if you're building for a client, finish the work. If you have paying users, maintain the product. If you're close to something genuinely useful, push through.
But that side project you started last Tuesday that you're already losing interest in? Let it go. Start something else. The code doesn't care about your commitment issues.
The portfolio of attempts
Here's what my 200 unfinished projects actually represent:
- 200 times I had an idea and acted on it
- 200 times I learned something new
- 200 different technologies, patterns, and approaches I've been exposed to
- A breadth of experience that no single project could provide
When someone asks me if I can build something, I almost always say yes — not because I've done that exact thing before, but because I've done 12 things that are kind of like it. That only happens when you start a lot of projects.
Start another one
If you're sitting there with 50 unfinished projects feeling guilty about starting #51 — stop. Open your laptop. Start #51.
The best builders I know aren't the ones who finish everything. They're the ones who start constantly, learn aggressively, and occasionally — when something really clicks — see one through.
That's not a character flaw. That's a learning strategy.
Get the next one.
Field notes from real deployments, written the way this one was. No schedule promised and nothing sold to you. Unsubscribe whenever.