I Have 47 Unfinished Side Projects. Here's Why I Don't Feel Bad About It.
Source: Dev.to
Overview
Last week I ran ls ~/projects and actually counted the folders.
47.
Forty‑seven projects. Let me show you some highlights:
~/projects
├── todo-app-v1/
├── todo-app-v2/
├── todo-app-final/
├── todo-app-FINAL-final/
├── social-network-app/ # just a login screen lol
├── crypto-tracker-2023/ # mass grave of API keys
├── fitness-app/ # ironic given my lifestyle
├── weather-app-but-cool/ # it was not cool
├── tinder-for-dogs/ # don't ask
├── my-portfolio-site-v7/ # v1 through v6 also in here
├── chat-app-realtime/ # real‑time for about 10 minutes
├── ai-wrapper-startup/ # before everyone else did it
├── expense-tracker/ # $0 tracked, $0 earned
├── recipe-app/ # I can't cook
├── markdown-editor/ # abandoned in favor of VS Code
└── … 32 moreI’m Daniil, 19, and I build iOS apps for a living. My projects folder looks like a digital cemetery. Every single one of those folders started with “this is THE ONE” energy and ended with me opening a new Xcode project two weeks later.
Sound familiar?
The Guilt Is Real
Open Twitter right now. I guarantee that within three scrolls you’ll see someone posting “just shipped!” with a screenshot of their perfect little app. There’s a whole culture built around finishing things. Productivity gurus will tell you the secret to success is following through:
“Finish what you start.”
“Ideas are worthless, execution is everything.”
“The last 10 % is what separates winners from losers.”
Cool. So I’m a loser 47 times over, I guess.
There was a time when my unfinished projects genuinely bothered me. I’d look at that folder and feel a weird mix of shame and frustration. Why can’t I just FINISH something? Am I lazy? Am I a bad developer? Do I have the attention span of a goldfish with ADHD?
I’d see people on Reddit showing off their polished apps and think, “That person is better than me because they shipped.” Meanwhile I have four todo apps and none of them actually track my todos.
The productivity internet has turned not finishing projects into a moral failure. If you abandon a side project, you’re basically admitting you don’t have what it takes.
That’s garbage. And I’ll tell you why.
But Every Dead Project Taught Me Something
Every single one of those 47 corpses in my projects folder gave me something. Not a portfolio piece, not a single user, but actual skills I use every day at my job.
The todo app(s) that taught me SwiftUI
All four of them.
- The first one was a list with checkboxes; it took me two days to figure out why
@Statewasn’t updating my view. - The second one tried to add Core Data and collapsed.
- By the third attempt I actually understood data flow in SwiftUI.
- The fourth one I abandoned because I realized I didn’t need a custom todo app.
Result: I walked away knowing SwiftUI cold. I didn’t finish the app; I finished learning the framework.
The chat app that taught me WebSockets
I was going to build “the next Discord.” (Pause for laughter.) I got as far as two users sending messages in real time—no voice, no channels, no file sharing. I spent a week learning:
- How WebSocket connections work
- How reconnections behave on flaky Wi‑Fi
- What happens to queued messages when the server goes down
Six months later a client needed real‑time features in their iOS app. I already knew how to do it. Got paid for that knowledge. Thanks, dead chat app.
The e‑commerce site that taught me payment APIs
Supposed to be a store for custom phone cases. I never designed a single case, but I spent three days integrating Stripe, figuring out webhooks, handling edge cases like failed payments and refunds. The project died with zero products listed, yet later I added in‑app purchases to a real project without starting from zero.
The CLI tool that taught me how to publish packages
I built a command‑line tool that formatted Swift code. It worked, kind of. It wasn’t better than SwiftFormat, but I learned:
- How to structure a Swift package
- How to write a decent README
- How to publish to a registry and handle versioning
The tool has zero downloads; the knowledge has been useful dozens of times since.
The game that taught me state machines
I tried to build a 2D platformer. I got a character that could run and jump. When I needed to handle “running + jumping + attacking + taking damage,” I realized I needed state machines. I spent a week learning about them. The game never shipped, but now I use state machines in literally every complex UI I build.
The AI wrapper that taught me API rate limiting
Peak 2023 energy: “I’ll just wrap GPT‑4 in a nice UI and become a millionaire.” The millionaire part didn’t happen. I burned through $40 in API credits in one afternoon because I didn’t understand rate limiting, token budgets, or caching. Expensive lesson, but I never made that mistake again.
None of these projects shipped. All of them made me a better developer.
Why “Finish Everything” Is Bad Advice
The advice to “always finish what you start” is actually harmful for developers—especially early in your career.
If I had forced myself to finish that first todo app before moving on, I would have spent weeks polishing something nobody would use, learning nothing new, just grinding through UI tweaks and edge cases for an app the App Store already has ten thousand versions of.
Instead, I moved on when I stopped learning. And that’s the key.
There’s this thing called the sunk‑cost fallacy. You’ve probably heard of it: “I’ve already put 40 hours into this, I can’t quit now.” Yes, you can. Those 40 hours are gone whether you continue or not. What matters is the knowledge you keep and the new skills you acquire by moving on.
Bottom line: Unfinished projects aren’t failures; they’re stepping stones. Embrace the learning, let go of the guilt, and keep building.
Knowing When to Quit a Side Project
If the next 40 hours won’t teach you anything new or produce something valuable, you’re just burning time to avoid feeling like a quitter.
Knowing when to abandon a project is a really important skill. In my day job I’ve watched teams spend months on features that should have been killed in week 2. They kept going because “we’ve already invested so much.” That’s not persistence—it’s stubbornness dressed up as work ethic.
Quitting a side project is prioritization. You’re choosing to spend your limited time and energy on something with a better return. That’s literally what senior developers do all day: they decide what NOT to build.
Every time you kill a project you get better at recognizing when something isn’t worth the effort. That skill pays off far more than a finished todo‑app ever would.
When to Quit vs. When to Push Through
I’m not saying abandon everything the moment it gets hard—that’s the opposite extreme and it’s just as bad. Some projects deserve your persistence; the trick is knowing which ones.
I’ve started asking myself four questions when my motivation starts to die. If I answer “no” to most of them, it’s probably time to move on.
-
Am I still learning something new?
If every day on the project teaches you something you didn’t know yesterday, keep going. The moment you’re just doing repetitive work (connecting the same screens, writing the same CRUD operations, copying patterns you already know), you’ve extracted the value. The project has served its purpose. -
Would anyone (including me) actually use this?
Be brutally honest. Not “could someone theoretically use this,” but “would I install this on my own phone and open it more than once?” My four todo‑apps fail this test hard. The world does not need another todo‑app. If you’re building something that already has 500 alternatives and yours isn’t meaningfully different, that’s a sign. -
Is this fun or has it become a chore?
Side projects are supposed to be the fun part of being a developer—the part where you build whatever you want without a product manager breathing down your neck. If your side project feels like a second job, something is wrong. Either the project itself isn’t interesting anymore, or you’re forcing yourself to continue out of obligation. Neither is a good reason to keep going. -
Am I quitting because it’s hard or because it’s pointless?
This requires honest self‑reflection. “Hard” is not a reason to quit. I’ve abandoned exactly zero projects because they were too difficult. I’ve abandoned 47 because they were no longer useful to me. There’s a massive difference between “I can’t figure out networking” (push through, you need this) and “I’ve figured out networking but this chat app is still just two people talking” (move on, you got what you came for).
If you score 0 or 1 out of 4, walk away. No guilt. You’ve graduated from that project.
My ONE Finished Project (And Why It Worked)
Out of 47 attempts, one project actually made it across the finish line: a finance‑tracking app. Not glamorous, not “revolutionary,” but it survived for good reasons.
- Real problem: I was terrible with money. I needed a tool to see where my cash went. This wasn’t a “what if people wanted…” idea; it was a “I literally need this tomorrow” necessity.
- Immediate user: I was my own user from day one. Every morning I opened it; every annoyance was fixed that evening. The feedback loop was instant—no guessing what users might want.
- Hard deadline: “Have it working before the start of next month so I can track a full month of expenses.” Three weeks. Not enough time to over‑engineer, add a social feed, an AI assistant, or any shiny distraction.
- Absurdly small scope: Three screens—add expense, view expenses, see a monthly summary. No categories at first (added later), no charts at first (added later), no export feature (still don’t have one). The smallest possible thing that was useful.
The difference between this project and the other 46 wasn’t talent or discipline; it was context. I had a real problem and a real deadline. The other 46 were “what if” projects. This one was a “I need this right now” project.
Your ~/projects Folder Isn’t a Graveyard
I used to think of my projects folder as a graveyard—a sad collection of abandoned dreams and broken promises. Now I see it more like a training ground.
Every project in there was a workout. Some were sprints (the AI wrapper lasted three days). Some were long runs (the game took two months before I stopped). All of them built muscle I still use.
If you’re staring at a folder full of half‑finished apps and feeling guilty, stop. Open that folder and, instead of seeing failures, list what each project taught you. You’ll be surprised.
- That “failed” weather app? It taught you API integration.
- That “abandoned” blog engine? It taught you authentication.
You didn’t fail those projects; you studied them and moved on when the lesson was over.
The developers who actually scare me aren’t the ones with 47 unfinished projects. They’re the ones with zero—because that means they’re not experimenting, not curious enough to start things they might not finish.
So yeah, I have 47 unfinished side projects. And honestly? I’m probably going to start number 48 this weekend: a Pomodoro timer. I’ll give it two weeks, tops.
If you found this useful, I share more stuff like this on Telegram and sell developer toolkits on Boosty.