Why I Build Side Projects I Never Finish (And Why That's Okay)
My GitHub is a graveyard of unfinished projects. Turns out that's not a failure—it's exactly how I learn best.
My GitHub is a graveyard of unfinished projects. Turns out that's not a failure—it's exactly how I learn best.
I have 47 repositories on GitHub. Want to guess how many are "finished"? Maybe five. The rest are abandoned midway through, sitting there with their last commit from months or years ago. "Update README" or "WIP: trying new approach" frozen in time.
For years, I felt guilty about this. I'd see other developers with polished portfolios, completed projects with proper documentation and live demos. Meanwhile, I had a digital graveyard of half-built apps, experimental libraries, and prototypes that never made it past the proof-of-concept stage.
Then I realized something: those unfinished projects taught me more than any completed one ever did.
Here's what a typical side project looks like for me:
Week 1: I'm on fire. New idea, full of excitement. I scaffold the project, set up the tooling, get the basic structure in place. Everything is possibility.
Week 2-3: I'm deep in the interesting problems. How do I handle this state management challenge? What's the best way to structure this API? I'm learning, experimenting, breaking things and fixing them.
Week 4: I've solved the hard problems. The project basically works. Now I just need to polish it, write docs, deploy it, add those last few features...
Week 5: I've moved on to something else.
Sound familiar?
Here's the thing: all the learning happened in weeks 2 and 3. That's where I wrestled with new concepts, tried different approaches, actually grew as a developer. The polishing phase? That's just applying what I already know.
There's this famous saying in software: the first 80% of the work takes 80% of the time, and the last 20% takes the other 80% of the time.
For side projects, it's even more skewed. Getting something working is fun and challenging. Making it production-ready is tedious.
Adding error handling for every edge case. Writing comprehensive tests. Creating documentation. Setting up CI/CD. Building a proper landing page. Handling user authentication. Adding loading states and error messages. Making it mobile responsive. Optimizing performance. Fixing that one weird bug that only happens on Safari.
This stuff matters for production applications. But for learning? It's mostly busywork.
I used to force myself through this phase anyway, thinking that "finishing" was important. But I was miserable, and I wasn't learning anything new. I was just grinding through tasks I'd done a hundred times before.
These days, I'm more intentional about what I want from each side project. Usually, it's one of these things:
Learning a New Technology: I'll build something small to understand how a framework, library, or language works. Once I've wrapped my head around the core concepts and built something functional, I'm done. Mission accomplished.
Exploring an Idea: Sometimes I just want to see if something is possible. Can I build a tool that does X? What would the architecture look like? How would I solve this particular problem? Once I've answered those questions, the project has served its purpose.
Solving a Specific Problem: Occasionally, I build something because I need it right now. A quick script to automate something. A tool to solve a problem I'm facing. These are "finished" in the sense that they work for my needs, even if they're not polished or public-ready.
Experimenting With Patterns: I'll implement the same application multiple times with different approaches. A todo app with Redux, then with Zustand, then with React Query. Not because I need another todo app, but because I want to understand the tradeoffs between different state management approaches.
Notice what's not on that list? "Build a polished product to show off in my portfolio."
When I was starting out, I thought I needed an impressive portfolio of completed projects to get hired or be taken seriously. So I'd torture myself trying to finish things just to have something to show.
But here's what I've learned after hiring developers and being hired myself: nobody cares about your todo app with perfect documentation and a deployed demo. They care about whether you can solve problems and write good code.
A GitHub full of experimental projects actually tells a better story than three polished portfolio pieces. It shows curiosity. It shows you're actively learning. It shows you're not afraid to try new things.
Some of my best interviews have come from discussions about unfinished projects. "Oh, you were experimenting with WebRTC? What challenges did you run into?" That leads to a much more interesting conversation than "I built a todo app with React."
I'm not saying you should never finish anything. There are times when seeing a project through to completion is valuable:
When People Are Using It: If your side project has actual users—even just a few—then yes, you have a responsibility to make it work properly and maintain it. This is different from building something just for yourself.
When You're Building a Business: If the goal is to make money or build something sustainable, then obviously you need to finish it. Half-built products don't generate revenue.
When It's Teaching You About Shipping: Sometimes the valuable lesson is learning how to deploy, maintain, and support a real application. In that case, going through the "boring" parts is the point.
When It's for Your Current Job: If you're building a tool or library that your team will actually use, finish it properly. This isn't really a side project at that point—it's work.
But for pure learning? For exploring new technologies or ideas? Finishing is optional.
If you're like me, sitting on a pile of unfinished projects and feeling guilty about it, let me give you permission: it's okay to abandon them.
That React Native app you started learning mobile development with? You learned what you needed to learn. Archive it and move on.
That experimental state management library? You figured out why the existing solutions work the way they do. That was the point. You don't need to publish it.
That SaaS idea you prototyped? You validated (or invalidated) the core concept. Whether or not you build it into a real product is a separate decision.
Not every project needs to cross the finish line. Sometimes the value is in the journey, not the destination.
These days, I'm upfront with myself about what each side project is for. Before I start, I ask:
What do I want to learn from this?
What does "done" look like for this specific project?
Am I building this to learn, to use, or to share?
If it's for learning, "done" might mean "I understand how this technology works now." If it's for using, "done" might mean "it solves my problem, even if it's rough around the edges." If it's for sharing, then yes, I need to put in the work to make it polished and usable by others.
This clarity has made me way more productive and way less guilty. I'm learning faster because I'm not wasting time polishing things nobody will use. I'm having more fun because I'm spending my time on the interesting problems, not the tedious cleanup.
Your GitHub doesn't need to be a portfolio of polished, completed projects. It can be a playground. A laboratory. A place where you try things and learn and experiment.
Some of those experiments will turn into something real. Most won't. And that's not just okay—it's exactly how learning works.
So if you've got a graveyard of unfinished projects, don't feel bad. Feel proud. Each one of those projects taught you something. Each one made you a better developer. The fact that they're not "finished" doesn't diminish that value.
Build things. Learn from them. Move on when you've learned what you needed to learn. And don't let the guilt of unfinished projects stop you from starting new ones.
The developers who learn fastest aren't the ones who finish everything. They're the ones who aren't afraid to start something new, extract the learning, and move on.
Your side projects don't need to be finished. They just need to make you better.