I used to pick side projects based on excitement.
That sounds good in theory, but in practice it meant the same pattern every time: I would build fast for two weeks, polish the UI for one more week, and then realize nobody really needed it.
The problem was not effort. The problem was project selection.
After repeating this enough times, I started using a simple filter before writing real code. Nothing fancy, just a few questions that force clarity.
The filter I use before building
I only start a project if I can answer these clearly:
- Whose problem is this?
- How painful is it today?
- How will users discover it?
- Can I ship a useful version in 1-2 weeks?
If one answer is weak, I pause.
Most ideas fail on discovery, not implementation. Building is usually the easy part.
The biggest lesson: distribution is part of the product
I used to treat distribution as “later”.
Now I treat it as part of the core design. If I don’t know where the first 20 users will come from, I don’t start.
For me, good distribution signals look like:
- I already have direct access to the audience (friends, clients, communities I am active in)
- The problem appears repeatedly in places I read every week
- I can explain the value in one sentence without sounding clever
If I need a long explanation, the product is probably too vague.
My 7-day validation sprint
Before committing to a full build, I run a short validation sprint.
Day 1-2: Define a narrow job
Not “productivity app”.
Something like: “help iOS freelancers share clean progress updates with clients in under 2 minutes.”
Day 3-4: Put a rough version in front of real people
Not perfect UI. Just enough to test the core job.
I ask a small set of users to try it and I watch where they hesitate.
Day 5-7: Check behavior, not compliments
Nice feedback is cheap.
What I care about is:
- Did they use it twice?
- Did they ask for it without a reminder?
- Would they be annoyed if it disappeared?
If those signals are weak, I kill it or reduce scope.
How I decide to kill a project
Killing a project used to feel like failure. Now it feels like protecting time.
I shut projects down when:
- users like the idea but don’t return
- the value depends on too many “if they also…” conditions
- maintenance cost grows faster than usage
A clean kill is often a win.
You keep the lessons, free your attention, and avoid months of slow frustration.
What changed after I adopted this
I ship fewer projects, but each one has a better reason to exist.
I also feel less pressure to “finish” everything. Some ideas are only meant to teach you what not to build.
That shift made side projects more sustainable for me:
- less random coding
- more intentional bets
- faster feedback loops
- better long-term motivation
Final thought
If you’re building solo, your scarcest resource is not code quality. It’s attention.
Pick ideas that can earn that attention back quickly.
Everything else is just an expensive hobby project in disguise.