And why that half-built todo app might land you your next job
Hey dev community š
Let me ask you something uncomfortable.
How many repos are sitting in your GitHub right now, dusty, half-finished, last committed to "6 months ago", that you're secretly ashamed of?
A weather app that never got a UI. A CLI tool you built for a weekend, then forgot. A Discord bot that almost worked. A SaaS idea that made it to the landing page and then... nothing.
Yeah. Me too. We all have them.
But here's the thing nobody talks about: those unfinished projects are not failures. They might actually be your most powerful asset.
Let me explain.
The "Graveyard" Problem
Most developers have what I call a GitHub Graveyard, a collection of repos that were born with ambition and died with a half-written README.
The reasons are always the same:
- Life got busy
- The problem turned out to be harder than expected
- A shinier idea came along
- You learned what you needed and moved on
- The scope kept expanding and you never shipped
Sound familiar? Of course it does. Because this is just how developers learn.
The mistake is treating these repos as embarrassments to hide rather than evidence to showcase.
Why Recruiters and Hiring Managers Actually Care
Here's a secret from the other side of the hiring table: a thoughtful, incomplete project tells a better story than no project at all.
When a recruiter or senior engineer looks at your GitHub, they're not checking if everything is polished and production-ready. They're asking:
"Does this person write real code when nobody's watching?"
An unfinished project that shows:
- Real problem-solving thinking
- Clean commit history with meaningful messages
- A proper README explaining the why, not just the what
- Honest documentation of where it stands and what's next
...is worth 10x more than a repo with one commit that says "initial commit" on a todo app copied from a tutorial.
What hiring managers actually look for:
| Signal | What it says about you |
|---|---|
| Consistent commits over time | You're a builder, not just a learner |
| Multiple tech stacks explored | Curiosity and adaptability |
| README with context | Communication skills |
| Issues / project boards | Engineering maturity |
| Branches and PRs (even solo) | You understand workflows |
An abandoned project with 47 commits, a proper README, and an open TODO.md screams "this person builds things."
The Personal Project Angle: Ship the Damn Thing
Now, let's flip this around.
Some of your unfinished projects deserve to be finished. Not because someone is watching, but because the problem you were solving was real.
Ask yourself this about each repo in your graveyard:
- Did I build this because I actually needed it? ā High potential.
- Would I use it if it worked? ā Ship it.
- Did other people ask for it? ā Definitely ship it.
- Did I learn something that could help others? ā Write it up and open-source it.
The bar for "launching" a personal project is lower than you think. You don't need:
- ā A perfect UI
- ā Full test coverage
- ā A marketing strategy
- ā A monetization plan
You just need:
- ā It solves a real problem
- ā A clear README
- ā A way for someone to run it or use it
- ā
A
v0.1tag pushed to GitHub
Done beats perfect. Every time.
Real Talk: How to Revive a Dead Project (Without Losing Your Mind)
Before you doom-scroll through your repos feeling overwhelmed, here's a practical system:
Step 1: The Audit (30 minutes)
Go through every repo. For each one, ask: "Is the core idea still interesting?" If yes, add it to a shortlist.
Step 2: The One-Line README Fix
For every shortlisted repo, write one sentence that explains what it does and why you built it. Add that to the README today. Just that. Nothing else.
Step 3: Pick ONE to Finish
Not five. Not two. One. The one that's closest to done, or the one you'd actually use.
Step 4: Define "Done" (for real this time)
Write down the three features that would make this thing usable. Not impressive. Not scalable. Just usable. That's your v1.
Step 5: 20 Minutes a Day
Set a recurring calendar block. 20 minutes. No context switching. Just that project. You'll be amazed what happens in two weeks.
The Community Power Move
Here's something almost nobody does: talk about your unfinished projects publicly.
Write a dev.to post that says "I'm building X, here's where I am". Post a thread on Twitter/X. Share in a Discord. Even just update your README with a "current status" badge.
Why? Because:
- Someone might offer to contribute
- Someone might tell you they have the same problem
- Accountability makes you actually ship
- The process story is often more interesting than the final product
The dev community loves a builder who shares their journey, not just their wins.
The Mindset Shift
Stop thinking of your GitHub as a portfolio of finished products.
Start thinking of it as a log of your thinking and growth.
Every repo, finished or not, represents a problem you cared about, a skill you were developing, a curiosity you followed. That's the resume. That's the story. That's what makes you interesting to work with.
The developer with 50 half-finished repos who's constantly building and shipping things in public will always outcompete the developer who's waiting until their code is "ready" to show anyone.
Now I Want to Hear From You
I'm genuinely curious about the dev community here on dev.to:
What's sitting in YOUR GitHub graveyard that deserves to be finished?
Drop a comment with:
- The repo (or just describe it)
- What it does / was supposed to do
- Why you stopped
- Whether you think it's worth reviving
I'll personally check out every project linked in the comments and leave feedback. Let's turn some of these graveyards into launch pads.
And if this post helped you look at your old repos differently, give it a , share it with a dev friend who needs to hear it, and let's build more stuff in public.
Top comments (0)