How to Actually Finish Your Side Projects
Prologue: My GitHub Graveyard
Honestly, my GitHub has far more abandoned projects than finished ones.
habit-tracker-v2, my-blog-v3, productivity-app, korean-vocab-flashcard... Each with 3-15 commits. Projects that blazed to life on some energetic weekend, then got stuck in "I'll come back to this someday" purgatory two weeks later.
Then I actually finished a side project for the first time. It was a small, simple tool. But the first time I deployed it and saw someone else actually use it, something felt completely different.
I went back and asked what was different that time. This post is that answer.
Why 90% Die
The Gap Between Vision and Reality
The biggest reason side projects die is the gap between your initial excitement and the actual work.
When the idea strikes, you see:
- A polished, beautiful UI
- A feature-rich app that covers everything
- People coming and loving it
When you actually build it, you encounter:
- Authentication alone consuming two days
- A "simple feature" with dozens of edge cases
- Nobody knowing it exists after you finish
- Never wanting to ship because you keep wanting to polish
The wider the gap between the idealized vision and the reality of the work, the faster motivation burns out.
Common Death Patterns
Perfectionism death:
Idea → 3 days debating tech stack → 1 week designing architecture →
Optimizing DB schema → Refactoring component structure →
...interest has died
Scope creep death:
"I'll make a todo app" → "It needs categories" → "Recurring tasks" →
"Calendar view" → "Team collaboration" → "Notifications" →
[abandoned]
Shipping anxiety death:
Features complete → "But this is still missing" → Build more →
"I'd be embarrassed without this" → Can't ship →
Interest gone → Abandoned
Tech rabbit hole death:
"Let me try the new hotness" → 2 weeks learning a framework →
1 week fighting bugs → No real progress → Motivation gone
The MVP Mindset: Not Minimum, But First Usable
MVP (Minimum Viable Product) is often misunderstood as "the bare minimum."
The correct definition:
"The simplest version that actually solves one core problem in a way a real person can use."
How to Define Your MVP Scope
When an idea hits, answer these questions:
1. The core problem this app solves in one sentence:
"Helps people who struggle with ___ to ___ more easily"
2. How are people solving this without my app right now?
→ If mine is 10% better, that's enough
3. If you could only keep one feature?
→ That's your MVP
4. Would someone use it with just that?
→ If YES, start
Concrete Example
Bad MVP plan:
v1.0 feature list:
- User auth (3 social logins)
- Todo CRUD
- Category tags
- Priority sorting
- Date/time scheduling
- Recurring tasks
- Notifications
- Collaboration/sharing
- Mobile app
- Dark mode
Good MVP plan:
v0.1 (shippable today):
- Save todos to localStorage, check them off
- That's it
v0.2 (if I keep using it):
- Simple categories
v1.0 (if real users want it):
- Cloud sync
Scope Management: Fighting Feature Creep
The "Later Features" List
Every time a new idea surfaces, implement it and you'll never finish. Instead, maintain a "later features" list.
# my-app TODO
## MVP (do now)
- [x] Basic layout
- [ ] Add todo
- [ ] Check off todo
- [ ] Local save
## Backlog (after MVP ships)
- Categories
- Search
- Sorting
- Stats
## Maybe Someday
- Mobile app
- Collaboration
- AI suggestions
When "I NEED this!" hits you, put it in backlog. Finish what's already there first.
The 72-Hour Rule
When a new idea surfaces, wait 72 hours. If you still think "I really need this" three days later, add it to backlog. If it was just an impulse, 72 hours will dissolve it.
The Feature Gate Questions
1. Without this feature, does the MVP not function at all?
2. Have my first 10 actual users explicitly asked for this?
3. Does building it take more than a day?
All NO → Don't build it now
1 is YES → Build it now
2 is YES → Add to backlog
Choose Boring Technology
The urge to use new tech is natural. But if you want to finish a side project, sometimes you need to suppress it.
The Case for Boring Tech
New technology brings:
- Learning curve → stagnant period → motivation loss
- "Is this my bug or the framework's bug?" confusion
- No Stack Overflow answers, small community
Known technology brings:
- Fast progress → dopamine → sustained motivation
- Immediate solutions to problems
- Your brain focuses on "what to build" instead of "how this works"
❌ "Let me try Rust + WASM for this side project"
(low completion probability)
✅ "Ship with Next.js + TypeScript in two weeks"
(known stack, focus on shipping)
Exception: When learning the technology IS the goal. Set "understanding this tech" as the objective and lower your expectations around shipping. The goal isn't "deploy," it's "understand."
Stack Decision Framework
Can I ship with a stack I already know in two weeks?
├── YES → Use that stack
└── NO → Why not?
├── Stack is the problem → Pick from what you know
└── Two weeks is too short → Cut scope further
Public Accountability
It's easy to procrastinate alone. Announcing it publicly changes things.
Effective Public Commitment
Announce on Twitter/X or LinkedIn:
"Shipping [project name] MVP by next week.
Features: [exactly 3]
Will post weekly updates"
Build in Public:
- Post a one or two sentence progress update every week
- Share where you're stuck (you'll get help)
- Announce the ship
Write a dev blog series:
- Writing forces continued building
- Becomes a portfolio piece later
- Readers become early users
Share in Discord or Slack communities:
- People start waiting for it
- You can ask for help when stuck
- They might become your first users
Personally, the weekly tweet format worked best for me. You need actual progress to write even one tweet, so it pushes you to do at least something each week.
Celebrate Small Wins
Staring only at the big goal ("finish the app") makes the middle boring. Set small milestones and genuinely treat each completion as a win.
Example Milestones
## Development Milestones
### Week 1
- [ ] Create repo, deploy Hello World
- [ ] Basic layout complete
- [ ] Data model designed
### Week 2
- [ ] Core feature 1 working
- [ ] Core feature 2 working
### Week 3
- [ ] Basic UI complete
- [ ] Deployed (Vercel/Railway)
### Post-launch
- [ ] Share link with first 5 people
- [ ] First real user feedback received
"Create repo and deploy Hello World" counts as a milestone. Once a real URL exists, things feel real.
Ship Even When It's Not Perfect
Many side projects stall on "it's not done yet." But shipping generates real feedback, and that feedback fuels the next round of development.
"If you're not embarrassed by the first version of your product, you've launched too late." — Reid Hoffman
An embarrassing v1 that exists is 100x better than a perfect version that never ships.
Deployment vs Completion
Defining what "done" means for your side project matters.
Bad Definitions of Done:
- "When all the features are built"
- "When the design is perfect"
- "When there are no bugs"
- "When the code is clean"
Good Definitions of Done:
- "When there's a first real user"
- "When I'm using it myself every day"
- "When the core problem is solved"
Set a minimum bar for shipping:
Shipping checklist:
- [ ] One core feature actually works
- [ ] No critical bugs (visible errors)
- [ ] README has usage instructions
- [ ] I've used it myself and found it useful
→ All four checked? Ship it.
My Finished Projects vs Abandoned Projects
An honest comparison.
What Finished Projects Had in Common
- Small scope (1-2 core features)
- Technology I already knew
- Solving a problem I personally had
- A "just ship it" mindset
- Deployed within 1-3 weeks
What Abandoned Projects Had in Common
- Too many features (10+)
- Trying to learn new tech along the way
- Started with "people will probably like this"
- Waited for it to be perfect
- Stretched past a month without shipping
The Biggest Lesson
"An ugly version that exists today > a perfect version that never comes"
An ugly version with an actual URL:
- Can be sent to a friend right now
- Can receive real feedback
- Can go on a resume with a link
- Changes "I'm working on something" to "I built something"
When to Quit vs When to Push Through
Not every side project needs to be finished. Sometimes letting go is the right call.
OK to Quit:
- You've learned what you wanted to learn from the tech
- You discovered something better already exists
- You realized you don't actually care about solving this problem
- Something more important needs your attention
Keep Going:
- You personally feel this pain right now
- You found alternatives but none do what you want
- Real potential users are waiting
"Quitting ≠ failure." Better to quit quickly and focus on the right project than to grind on the wrong one indefinitely.
Action Plan: Start Right Now
Reading this and closing the tab changes nothing. Try this now.
30-Minute Action
1. Pick exactly one side project you want to build (5 min)
2. Define the core feature in one sentence: "A tool that ___" (5 min)
3. List the MVP features — maximum 3 (10 min)
4. Set a ship date: two weeks from today (1 min)
5. Create the repo (9 min)
If you've done step 5, you've started.
Weekly Routine
20 minutes every Friday:
- What did I build this week? (5 min recap)
- What will I build next week? (exactly 3 things)
- Post a progress update somewhere (5 min)
When You're Stuck
When blocked:
1. 30-minute timer → try to solve it alone
2. If not solved → ask StackOverflow/Claude/GPT
3. Still stuck → can the app work without this feature?
YES → skip it, do something else first
NO → is there a simpler approach?
Summary: Finishing as a Meta-Skill
Finishing a side project is a skill separate from being a good developer.
- The ability to narrow an idea down
- The courage to ship imperfect work
- The discipline to keep going when excitement fades
- The focus to resist shiny new ideas
These skills grow with practice. The more small projects you finish, the easier the next one becomes.
Build it now. Fix it later.