To find a side project idea worth your evenings, stop browsing idea lists and start noticing problems. Keep a short annoyance log for two weeks, add the manual workarounds you see in communities you're already part of, then score every candidate against side-project constraints: can you build it in evenings, can you reach the first 20 users without ads, would you use it yourself, does it survive a two-week break, and is anyone already spending time or money on a workaround. Pick the top scorer, write it as a one-sentence problem statement, and only then go and validate it.
This guide is for developers, designers and other builders with a day job and roughly five to ten hours a week. It covers the step before validation: where ideas come from and how to throw most of them away quickly. Paul Graham's essay quoted below was read in October 2026. The example builder near the end is made up, and so are her ideas and scores.
Why don't "side project ideas" lists work?
Search for side project ideas and you get the same list every time: a to-do app, a weather app, a habit tracker, a recipe finder. Fine as practice. As something to spend six months of evenings on, they fail for three reasons.
No unfair insight. The list writer doesn't know your life, your hobbies or the odd problems in your corner of the world, so the ideas are generic by design. Hundreds of other people are reading the same list.
Crowded with free options. If an idea is obvious enough for a listicle, someone has already shipped it, often for free and often better than you can in evenings.
No reachable buyer. "People who want a to-do app" isn't a group you can find, talk to or post in front of.
In his essay How to Get Startup Ideas, Paul Graham calls these "made-up" or "sitcom" ideas. His example is a social network for pet owners: it sounds plausible, and friends with pets say they could maybe see using it, but nobody wants it urgently. He's writing about startups, not side projects, but the trap is the same. An idea that sounds reasonable to everyone is usually wanted badly by no one.
The fix isn't a better list. It's a habit: generate your own ideas from things you actually see, then filter them hard.
Where do good side project ideas actually come from?
Graham's essay opens with the line that matters most: "The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself." The verb, he says, is not "think up" but "notice." These are the places worth noticing.
Your own repeated annoyances
The best source is whatever has bugged you more than twice this month. Once is bad luck. Twice is a pattern. You also get your first user for free, and you'll know straight away whether the product is any good.
Communities and hobbies you're already in
Your climbing gym, choir, five-a-side league, allotment society, open-source project, tabletop club. You know how these groups really work, who does the boring admin and where things break. And you're already in the room, which is what makes the first 20 users reachable without ads.
Spreadsheets, copy-paste rituals and manual workarounds
Watch for anyone retyping data from one place to another every week, keeping a shared spreadsheet that one person "owns", or pasting the same message into five chats. A manual workaround is evidence. Someone is already paying for the problem in time.
Questions people keep asking
Pick a forum, Discord server or subreddit where your kind of people hang out and read the last month of posts. Look for the same question asked again and again, with answers like "I just use a spreadsheet" or "there isn't really a good tool for this."
Boring niche jobs next to your skills
Graham describes two filters that hide good ideas: the "schlep filter", which steers you away from tedious, messy problems, and the "unsexy filter", which steers you away from problems you find unglamorous. Most developers want ideas that are pure code, and that space is crowded. Small tools for people who run sports leagues, book tutoring sessions or track a club's kit often have nobody serving them well, because nobody wanted to look.
Tools that got worse, shut down or raised prices
When a tool people rely on is discontinued, drops its free plan or changes in a way its users hate, you'll see it in those same communities: threads asking for alternatives, people sharing exports. That's a moment when people are actively looking. Don't rebuild the whole old tool. Build the small piece the frustrated users actually miss, if you can run it in evenings.
How do you run a two-week annoyance log?
Graham suggests something close to this in a footnote: keeping a journal and each night making "a brief entry listing the gaps and anomalies you'd noticed that day. Not startup ideas, just the raw gaps and anomalies." That's the habit. You're not writing ideas, you're writing what happened. Ideas come when you read it back.
Keep it wherever you already write things down. Each entry gets five short fields (this one is made up, to show the format):
Date: Thursday
What happened: 20 min matching the club's bank export to the member list by hand
Who else hits this: Every volunteer treasurer I know
Current workaround: Spreadsheet and a lot of scrolling
Anyone paying or spending time on it: Yes, time. Every month.Write it the same day. By the weekend you'll remember only the dramatic annoyances, which aren't always the frequent ones.
Log other people's annoyances too, with their name. That's someone you can talk to later.
Don't solve anything yet. Sketch a product on day two and you'll stop noticing and start defending one idea.
Two weeks, then stop. My rule of thumb: long enough to catch the repeats, short enough that you'll finish.
When the two weeks are up, read the whole log in one sitting. Circle anything that showed up more than once, cost someone real time, or genuinely irritated you. Those circled lines are your raw ideas.
What about ideas from your day job?
Your day job is full of annoyances, and it's tempting to build the fix on the side. Be careful: ideas taken from your employer's problems, internal tools or customers are the ones most likely to collide with your employment contract, through IP assignment, confidentiality or non-solicitation clauses. Read the contract before you write a line of code. Our guide to charging for a side project while you have a day job covers which clauses to look for. In the scoring below, treat "this came from my employer's problems" as a flag to check, not a bonus.
How do you filter side project ideas?
A good startup idea and a good side project idea aren't the same thing. You're working with tired evenings, no sales budget and long gaps when life gets busy. Run every circled idea through these questions.
Can you build and run it in evenings?
Can one person with an hour or two after work build a first version and keep it running? Warning signs:
It needs sales calls or demos during business hours.
Customers would expect live support while you're at work.
Something breaking at 3am is your problem, like bookings or payments between users that can't fail.
It handles regulated or sensitive data from day one, like health records or financial account data.
Can you reach the first 20 users without ads?
Name the place: a specific Discord server, a club mailing list, a subreddit you've posted in for years, your league's group chat. If you can't name where the first 20 people are, and you're not already there, the idea needs marketing time you don't have. This question kills most listicle ideas, and it should.
Do you care enough to use it yourself?
Graham writes that he often asks founders "Would you use this thing yourself, if you hadn't written it?" and that you'd be surprised how often the answer is no. On a side project nobody pays you to push through month three. If you wouldn't open it, you won't keep building it.
Does it survive a two-week break?
You'll get sick, go on holiday, have a crunch at work. A tool that quietly keeps working is fine. Something that needs fresh content every day, daily moderation or a community you have to keep entertaining will fall over the first time you step away, unless that daily work is the part you enjoy.
Is there any sign people pay or spend time on the workaround?
You don't need revenue proof yet. You need a sign the problem costs someone something: hours in a spreadsheet, a clunky tool they put up with, a volunteer who dreads the monthly admin. "It's fine, we just use the group chat" is a weak signal, however clever your solution.
Do you know something others don't?
This is the unfair insight idea lists can't give you. You're on the committee, you've done the job for years, or you've seen the problem from both sides. You don't need a secret, just a better understanding than someone reading about it.
A simple scoring sheet
Score each candidate 0, 1 or 2 per question. Be honest and quick: minutes per idea, not an evening.
Criterion | Question to ask | 0 | 1 | 2 |
|---|---|---|---|---|
Evening-buildable | Can I build and run a first version alone, in evenings, with async support? | Needs calls, live ops or regulated data | Possible with cuts | Yes, comfortably |
Reachable first 20 | Can I name where the first 20 users are, and am I already there? | No idea where they are | I know where, but I'm an outsider | I'm already in the room |
Would use it | Would I use this if someone else had built it? | No | Sometimes | Every week |
Survives a break | Does it keep working if I disappear for two weeks? | Needs daily attention | Some things pile up | Runs fine |
Workaround signal | Is anyone spending time or money on this now? | Nobody bothers | Mild grumbling | Clear time or money spent |
Insider view | Do I understand this problem better than an outsider? | Read about it once | Seen it up close | Lived it |
Rule of thumb (mine, not a law): 9 or more out of 12, with no zero on "Evening-buildable" or "Reachable first 20", is worth taking to validation. A zero on either of those two is a stop, however well it scores elsewhere. Anything from your employer's problems stays on hold until you've checked your contract.
A made-up example: Dagny scores five ideas
Everything here is made up: the person, her ideas and every score. Dagny is a QA engineer at an insurance company. Outside work she's on her allotment society's committee and plays in a pub quiz team on Tuesdays. After two weeks of logging, she circled five lines:
Watering rota swaps. Plot holders who go away in summer swap watering duty in a group chat that runs to hundreds of messages, and the secretary retypes the rota into a spreadsheet every Sunday.
Quiz team "who's in" tracker. Every Monday she chases six people to find out who's coming.
Flaky test dashboard. At work, nobody knows which failing tests are flaky.
AI fridge-photo recipes. Everyone's talking about this kind of thing.
Reading tracker. She wants nicer stats than her current app gives her.
Idea | Evenings | Reach 20 | Would use | Survives break | Workaround | Insider | Total | Verdict |
|---|---|---|---|---|---|---|---|---|
Watering rota swaps | 2 | 2 | 2 | 2 | 2 | 2 | 12 | Pick this |
Quiz "who's in" | 2 | 1 | 1 | 2 | 0 | 1 | 7 | Chat polls already do this for free |
Flaky test dashboard | 1 | 0 | 2 | 1 | 2 | 2 | 8 | Employer's problem, buyers want demos: on hold |
AI fridge recipes | 1 | 0 | 0 | 1 | 0 | 0 | 2 | Trend-chasing, she rarely cooks |
Reading tracker | 2 | 0 | 2 | 2 | 0 | 0 | 6 | Fun to build, nobody to reach: learning project |
The flaky-test dashboard scores respectably, but it came straight from her employer's problems and its buyers are engineering teams who'd want demos in office hours. The score isn't the only gate. The reading tracker is the one she's most excited to code, and it's a fine project to learn on. It just won't find users.
The watering rota wins, and one wrinkle makes it better: it's seasonal. Nobody needs it in winter, which gives her quiet months to build before the people who need it come back in spring. The first 20 users are already in that group chat. She gave it a working name, Canrota, and moved on.
Is this a learning project or an earning project?
Decide before you start, because the filter above is for projects you want people to use. If you mostly want to learn a new language or framework, reach and workaround signals don't matter, and a reading-tracker kind of idea is perfect. Just don't judge a learning project by an earning project's scoreboard. Our post on choosing a side project tech stack you can still maintain covers keeping the two apart.
How do you turn the winning idea into a problem statement?
Before you build or talk to anyone, write the idea as one sentence about a problem, not a product:
[Specific people] struggle to [do a job] because [current workaround], which costs them [time, money or stress].
Dagny's (still made up): "Allotment plot holders who go away in summer struggle to swap watering shifts because it all happens in a long group chat the secretary retypes into a spreadsheet every Sunday, which costs the secretary an evening a week and still leaves plots unwatered."
If you can't fill every bracket, you don't know the problem well enough yet. Go back to the log or the community. Notice what's missing from the sentence, too: features, tech, a logo. That's on purpose.
The next step is checking the problem is real for people other than you, and it's a separate job. Our guide to validating a side project idea with five conversations before you build picks up exactly where this sentence leaves off.
A one-evening exercise
If you already have old notes or half-forgotten ideas, run a compressed version tonight. Timings are suggestions.
Dump (15 minutes). Every idea from the last year, plus every annoyance you remember from the last month. No judging.
List your rooms (10 minutes). Every community, club or online group you're genuinely part of, with one awkward or manual thing next to each.
Read one forum (20 minutes). Scroll back a month in one of those groups. Note repeated questions and spreadsheet answers.
Circle five (5 minutes). The ones that repeat, cost someone time, or annoy you personally.
Score (20 minutes). Run them through the sheet. Flag anything from your employer's problems.
Write one sentence (10 minutes). Turn the top scorer into a problem statement. If it won't fit, try the second.
Book the next step (10 minutes). Message two people from the right room and ask to talk about the problem this week. Don't pitch.
That's about an hour and a half. Then start the two-week log anyway. Tonight's winner might hold up, or the log might hand you something better.
Common traps
Building for "everyone". If your problem statement starts with "people who", name a narrower group you can actually find.
Solving a problem you've never had. You'll guess what matters, guess wrong, and have no instinct for "good enough".
Picking only by what's technically fun. Great for a learning project. For something people should use, it's a tiebreaker at most.
Chasing this month's trend. By the time you ship in evenings, the people who went full-time on it are months ahead.
Copying a viral indie product without its distribution. It probably came with an audience or years of posting. Copy it and you get the code without the reasons it worked.
Waiting for an original idea. A better version of an existing thing, for a narrow group the big tools ignore, is a perfectly good side project.
FAQ
What makes a good side project idea?
One you can build and run alone in evenings, for a group you can reach, solving a problem you'd want solved yourself, where people already spend time or money on a workaround. Bonus if it keeps working while you take two weeks off.
Should my side project be original?
No. Most good side projects are a narrower, simpler version of something that exists, made for a specific group. What matters is understanding that group's version of the problem better than the general tools do.
Can I build a side project in a crowded market?
Yes, if you can say what the existing tools miss for your people. Graham, writing about startups: "You don't need to worry about entering a 'crowded market' so long as you have a thesis about what everyone else in it is overlooking." For a side project the thesis can be small, like "the big tools are too complex for volunteer-run clubs." "Mine will be nicer" isn't a thesis.
How many ideas should I consider before picking one?
There's no magic number. Scoring around five real candidates side by side is usually enough to make the strong one obvious and stop you falling for your first idea. If none pass, keep logging for another couple of weeks rather than lowering the bar.
Start the log tonight
You don't need a brilliant idea to start a good side project. You need two weeks of paying attention, an honest scoring sheet and one clear sentence about a problem real people have. The building part you already know how to do.
And once your project is live, list it on SideHunt so other builders and early users can find it.