I have a graveyard of unfinished projects. Seriously. If you looked at my old repos you'd find half-built dashboards, abandoned CLIs, and at least three "starter templates" that I spent weeks perfecting and never used for anything.
The pattern was always the same. I'd get excited about an idea, spend two days setting up the perfect folder structure, add linting, CI, Docker, maybe even a design system. And by the time I was "ready to start building" I'd already lost interest.
Sound familiar?
The trap is feeling productive
Setting up tooling feels like progress. You configure ESLint, set up Prettier, add path aliases, create a beautiful README, maybe even write a contributing guide. For a project that only you will ever touch.
It's comfortable because it's familiar. You know how to do it. And it gives you that satisfying feeling of "doing things right."
But you're not building anything yet.
I've done this so many times that I started recognizing the pattern. The moment I catch myself spending more than 30 minutes on config for a side project, I know I'm just procrastinating.
What actually worked for me
When I built GymDose I did the opposite of what I normally do. I didn't plan the architecture. I didn't set up a monorepo. I didn't even think about scalability.
I just opened Flutter, created a screen, and started building the thing I needed.
The first version looked rough. The state management was all over the place. I had hardcoded strings everywhere. But it worked. I could open the app, tap my supplements, and close it. That was enough.
And because it worked I kept using it. Because I kept using it I kept improving it. Small fixes here, a better layout there. Over a few months it turned into something I was actually proud of, and I eventually published it.
None of that would've happened if I started with a "proper" architecture.
You don't need most of what you think you need
For a side project you probably don't need:
- A monorepo setup
- Docker in development
- CI/CD pipelines (just deploy manually at first)
- Separate staging and production environments
- A custom component library
- 100% test coverage
- TypeScript strict mode on day one
I'm not saying these things are bad. They're great in the right context. But for a side project you're building alone on weekends? They're just overhead that slows you down before you even know if the idea is worth pursuing.
You can always add them later. You almost never need them at the start.
The real goal is to find out if the idea works
Side projects aren't about code quality. They're about answering one question: does this thing solve a problem?
If yes, you'll naturally clean up the code because you'll keep working on it. If no, you just saved yourself weeks of planning something that was never going to matter anyway.
I wasted months building "proper" projects that nobody, including me, ever used. The one I actually shipped was the messiest one I ever started.
Some rules I try to follow now
One file is fine. If you can build the first version in a single file, do it. Split later when it actually gets painful, not before.
Skip the abstractions. Don't create a utils/ folder with three functions in it. Don't write a custom hook for something you use once. Copy-paste is completely fine for a prototype.
Deploy the ugly version. Put it out there. Use it yourself. Show it to one friend. The feedback from a working prototype is worth more than a month of planning in your head.
Give yourself a time limit. I try to get something working in one weekend. If I can't get a usable version in two days, either the scope is too big or I'm overcomplicating it.
Don't optimize what doesn't exist yet. You can't improve something you haven't built. Ship first, optimize later. The bottleneck is almost never performance, it's the fact that the project doesn't exist yet.
This isn't about writing bad code
I want to be clear. I'm not saying write garbage and call it done. What I'm saying is lower the bar for starting and raise it gradually as the project proves itself.
The best code I've written came from projects that started messy and got cleaned up over time. Because by that point I actually understood the problem well enough to make good decisions, instead of guessing upfront.
Just build the thing
If you have an idea sitting in your notes right now, here's what I'd do:
- Open your editor
- Create one file
- Build the core feature, nothing else
- Use it yourself for a week
- Then decide if it's worth investing more time
That's it. No boilerplate, no template, no setup ritual.
The projects that matter are the ones that exist.
Top comments (0)