Everyone has a side project graveyard. That folder on your desktop called projects/ with 47 half-built apps, 12 "revolutionary" SaaS ideas, and one landing page that's been "coming soon" since 2022.
Here's the uncomfortable truth: your side project isn't failing because you lack time. It's failing because you lack constraints.
The Trap of Infinite Possibility
When you start something new, the dopamine hits hard. You scaffold the project. You pick the perfect stack. You debate whether to use Next.js or Astro for three days. You configure CI/CD pipelines before writing a single feature. You redesign the logo five times.
This isn't building. This is procrastination with extra steps.
The problem with side projects is they have no deadlines, no stakes, and no external accountability. You can "work on it" for two years and have nothing to show. Contrast this with a hackathon: 24 hours, a demo that either works or doesn't, and a panel of judges ready to roast your broken authentication flow.
Constraint creates clarity.
The 48-Hour Rule
I have a simple rule for any new project: something useful must exist within 48 hours. Not a scaffold. Not a design system. Something that does one thing end-to-end.
For a web app, that's a form that saves to a database and displays the result. For a tool, that's a CLI that takes input and produces output. For a content site, that's one published post with real traffic.
If you can't get there in 48 hours, your scope is wrong. Cut features until you can.
Ship Ugly
Your first version should embarrass you. If you're not slightly ashamed of the code quality, the design, or the jankiness of the deployment, you waited too long to ship.
Perfect is the enemy of shipped. Polished is the enemy of tested. I've seen founders spend six months building features nobody asked for, only to launch to crickets. Meanwhile, the team that shipped a broken MVP in two weeks learned what users actually wanted and pivoted into something that mattered.
Users don't care about your stack. They care that the thing solves their problem. If it does, they'll tolerate jank. If it doesn't, your perfect TypeScript types won't save you.
The Real Metric
Stop measuring progress by commits, lines of code, or hours spent. Measure it by conversations with users. Zero users talking to you? You're building in the dark.
Ship something small. Tell five people. Watch them use it. The awkward silence when they can't figure out your "intuitive" navigation is worth more than 100 hours of guessing what they want.
Kill Your Darlings
Most side projects should die. Not because you failed, but because you learned what doesn't work. The goal isn't to save every project — it's to learn faster than anyone else.
Ship small. Ship often. Ship ugly. The graveyard will still exist, but at least some of those projects will have been tested before they died, not just imagined.
Now close this tab and go push that repo. Or better yet, delete it and build something smaller.
Top comments (0)