The Project Graveyard in My Github
I have a lot of unfinished projects in my GitHub. They are digital tombstones of grand ambitions that died somewhere between “revolutionary idea” and “hmm, maybe I need user authentication AND real-time chat AND AI integration AND…” everything I can think of during the planing phase and only have kanban boards or todo lists for them never got to be real.
Sound familiar?
For years, I was that developer who’d start projects with a mental feature list longer than a CVS receipt. I’d spend weeks architecting the perfect system, planning for edge cases that might never happen, and building features “just in case.” The result? A graveyard of half-built applications and a growing sense that I couldn’t finish anything.
Then I discovered the MVP mindset. Not just as a business concept, but as a personal productivity philosophy. And it changed everything.
What MVP Actually Means
Most people think MVP means “build something basic and hope for the best.” That’s wrong.
MVP means building the smallest thing that solves a real problem and gives you real feedback. It’s not about being lazy or cutting corners—it’s about being ruthlessly focused on what actually matters.
The skateboard-to-car analogy gets thrown around a lot, but here’s what it really taught me: each iteration should be a complete, working solution. A skateboard gets you from point A to point B. So does a car. But you learn different things from each version. The way you maintain balance on a skateboard is not the same as gearing up in a car.
My mistake for years was trying to build the car from day one. Spoiler alert: it doesn’t work and after this realization I belive it will never work projects built from ground up should be treated like wheels without wheels skateboard or cars are just not possible.
The Project That Actually Shipped
Last year, I had an idea for a expesne management app specifically for me. My initial plan was insane:
- GitHub integration
- Passbook integration
- Accounts managemnet
- Todo Apps
- Custom admin dashboard
- AI-powered suggestions
- Native Mobile app
- Dark mode (obviously)
- Kanban boards
- Budget system
- Reports and analytics
I spent three weeks just setting up the database schema. Then I realized I was doing it again—building the app which is only needed by me or maybe few others when I launch
So I stopped. Started over. Built the dumbest version possible: a single page where you could add expenses only no balance maintence nothing. That’s it. No database, just localStorage. No user accounts, no fancy UI. Just a working app for tracking transactions and exporting them
I shipped it in two days.
And you know what? People used it. My friends started asking for the link. I got feedback I never expected. Some wanted categories. Others wanted due dates. A few asked about multiple accounts features
But here’s the key: I learned what people actually need, not what my delusional brain thought they needed.
How I Apply MVP Thinking Now
1. The “One Problem” Rule
Every project starts with one question: What’s the ONE problem this solves? Not five problems. Not “it could also do this and that.” One problem. My current project is expense tracker. The one problem it solves: I keep forgetting just stroing expense and nothing more than that.
That’s it. Not “social media for sharing things” or “Bank account passbook” Just “store and generate csvs of your transactions.”
2. The 80/20 Feature Cut
I list every feature I can imagine, then cross out 80% of them.
The remaining 20% becomes version 1. The crossed-out features? They go in a “maybe later” file. Most of the time, “later” never comes—and that’s perfectly fine that feature may not be worth that time and effort maybe it will become a feature that is just there and only you use it and no one else which is obviously bad.
3. The Two-Week Test
If I can’t build a working version in two weeks, the scope is too big. This isn’t about rushing or cutting quality. It’s about being realistic. Two weeks forces me to focus on what’s actually essential versus what’s just nice to have and not waste time in thinking peculiar edge cases which may be only hypothetical.
4. The “Embarrassing” Launch
I launch when I’m slightly embarrassed by how basic it looks. This was hard to learn. I’m a perfectionist since I’ve been in my mind. But I realized that “slightly embarrassing” to me is often “perfectly adequate” to users what I seem imprefect everyone using my app is fine with like I still think the UI could be way better but it works and helps me focus on features first. And shipping something imperfect beats not shipping anything perfect.
The Compound Effect of Small Wins
Here’s what I didn’t expect: shipping small things consistently builds momentum faster than planning big things perfectly. When you plan things you get into a world where everything seems like ideal like the bodies in physics they do not apply in real world and maybe are too redundent for users like I told earlier some features may seem apealing to you but may not be useful for the users.
Every completed project teaches you something. Every launch gives you confidence. Every piece of feedback makes the next version better and if you only plan and plan you will only plan and gain no expeirence in theory everything seems very easy like only I have to push it to vercel or netlify and the project is deployed but what if the time comes and you have to run it on a custom VPS how will you be able to do that.
My unfinished projects taught me nothing except how to start things. My finished MVPs taught me how products actually work in the real world and what to expect when deploying them instead of thinking this feature would be a great thing or like make my app seem better to users as a solo developer you can not know if what are you thinking will be appealing to users hence you need to launch the bare minimum to get the things your users think what they actually need and what are just nice to have.
Final Thoughts
The MVP mindset isn’t just about building products faster (though it does that). It’s about building products that people actually want what makes your core idea speak rather than a polished ui of a similar kind of app.
Every feature you don’t build is a feature that can’t break, can’t confuse users, and can’t distract from your core value proposition. Constraints force creativity. Limitations inspire focus. It helps you to be more productive and a better person in hitting the deadlines better.
Your first version doesn’t need to be your final vision. It just needs to be the first step toward it. So what’s your skateboard? What’s the simplest thing you can build that solves a real problem for real people?
Stop planning the car. Start building the skateboard it will then lead to better car than you expect your car to be it will not just run it will break all the records
TL;DR: MVP isn’t about building cheap products—it’s about learning fast and building what people actually want. Start small, ship quickly, iterate based on real feedback.
