How I Turn Random Ideas Into Projects I Can Actually Build

I stopped treating every idea like a project

For years, my default reaction to a good idea was opening a code editor. I would register a fresh domain, set up database tables, and start writing endpoints. Two weeks later, I would be staring at a half-finished repository with no users, no distribution plan, and zero energy left to market it.

Capturing ideas is no longer my bottleneck. As I wrote in how I use cluing to catch ideas, quick notes keep good thoughts from slipping away. But once your capture inbox holds dozens of concepts, you hit a harder wall: execution time is strictly finite, and you cannot build everything.

Every unfinished side project on your hard drive carries an emotional tax. Treating every interesting thought like a project burns months on things nobody asked for. You need a fast, blunt way to evaluate project ideas and kill dead weight before writing code.

The four questions I ask every idea

For ideas that survive my initial capture filter, I skip the spreadsheets and ask four direct questions:

1. Is there real pain or demand?

Are people already searching for it, complaining about it, or paying for a shitty alternative? If I have to convince people they need it, I usually skip.

Market education is a game for venture-backed companies with millions to burn. As an independent builder, you want to step in front of pre-existing momentum. Look for public proof: active search keywords, angry community threads complaining about incumbent tools, or ugly spreadsheets teams duct-tape together because nothing clean exists.

In The Mom Test, Rob Fitzpatrick points out that real intent shows up in current behavior, not theoretical interest. If people are not already spending time or money hacking together a workaround, the pain is not sharp enough to justify building.

2. Can I build an ugly V1 fast?

Weekend or 1 to 2 weeks max. If it needs a marketplace, network effects, a mobile app, heavy content, or 6 months of work before it is useful, it goes back in the pile.

Long build cycles are traps. The more hours you invest before showing a product to users, the harder it is to admit when you built the wrong thing. You polish CSS margins and optimize database queries just to delay hearing a blunt "no."

An ugly V1 forces ruthless simplicity. A single landing page with a payment button, a simple webhook script, or a focused HTML template is enough. You do not need automated billing portals or multi-tenant workspaces. You just need to solve the core problem for one person.

3. Can I charge from day one?

Who pays, how much, and why now? If the plan is "get traffic first, figure out money later," I am out.

Free users consume endless support time, demand edge-case features, and disappear the moment you ask for five dollars. Paying customers tell you the truth because they have real skin in the game.

I'd rather have 100 people who desperately need it than 10,000 who kinda like it.

A hundred users paying twenty-nine or forty-nine dollars a month gives you an actual business that sustains your time. Ten thousand casual users who think your tool is "cool" are just server bills and support tickets.

4. Do I know where the first 10 to 100 users come from?

A subreddit, Slack group, SEO keyword, X niche, cold email list, existing audience, whatever. If I have no distribution idea, I do not build it.

Build it and they will come is how you waste three months.

If you cannot name the exact communities, search queries, or outreach lists you will tap on day one, you do not have a product; you have an afternoon hobby. As we explored in why distribution beats ideas, mediocre products with clear channels beat brilliant software built in hiding. Know your distribution path before opening your editor.

My 20-point scoring system (and why 16/20 is my cutoff)

To keep my evaluations honest, I score each candidate idea from 1 to 5 across those four criteria:

• Pain and Demand (1 to 5): 1 means nobody cares; 5 means people are visibly begging for a fix or paying for clunky workarounds.
• Build Speed (1 to 5): 1 means six months of infrastructure; 5 means a working V1 shipped in a weekend.
• Day-One Revenue (1 to 5): 1 means vague ad revenue or free tier hopes; 5 means clear upfront willingness to pay.
• Distribution Clarity (1 to 5): 1 means zero reach; 5 means direct access to active buyers today.

Then I score them 1 to 5 on those four. Anything below about 16/20 goes back.

Why 16? Because clearing 16 requires averaging at least a 4 across all categories. An idea might score a 5 on build speed and a 5 on revenue, but if distribution clarity is a 2, its score lands at 14. That reflects reality: a fast product with a payment button is useless if you have no way to reach customers.

What I do when two ideas tie

Occasionally two completely different ideas both hit a 17 or 18. When that happens, analyzing them further is a waste of time.

If two tie, I pick the one I can show to a real person tomorrow and won't hate after two weeks.

If idea A requires complex third-party API approvals, but idea B lets me send a rough prototype to a founder I know tomorrow morning, idea B wins. Fast customer contact beats theoretical upside every time.

Build the smallest thing, talk to 10 users, give it 2 to 4 weeks

Once an idea clears the 16-point cutoff, the build begins. But keep the scope absurdly tight.

Then I build the smallest thing that can take money or get a signup. Launch it rough. Talk to 10 users. If nobody cares after 2 to 4 weeks, I kill it and move on.

Talking to ten users means direct outreach. Message people who publicly complained about the problem. Email operators who run the workflow manually. Do not ask if they like the concept; ask them to use it and see if they will pay twenty-nine dollars to keep access.

If two to four weeks of honest outreach yields only polite compliments and zero paying signups, kill it without regret. As covered in our guide on validating product ideas before building, killing a dead project quickly is how you protect time for ideas that can actually work.

Why I bias toward boring, niche, painful, and small

I bias toward boring, niche, painful, small.

Boring problems have paying customers because businesses want their daily headaches gone. When an agency loses three hours every week wrestling CSV formatting, client intake forms, or messy data pipelines, they do not want a flashy platform. They want an aspirin. They will happily pay twenty-nine dollars a month to make that pain stop.

Niche focus removes brutal competition. If you build a general task manager, you compete against Notion and Asana. If you build a client feedback tool specifically for boutique newsletter creators, you have almost no direct rivals. You speak their language, charge fair rates, and dominate that corner.

Small scope lets you finish. Finishing creates momentum, generates real feedback, and brings in the first dollar. In our review of early product launch lessons, shipping small was the single biggest factor separating projects that made money from projects abandoned in private.

What goes straight into the trash pile

I avoid cool, broad, social, marketplace, and "AI for everyone" ideas unless I have some unfair distribution advantage.

Here is what goes straight into the trash pile:

• Consumer social apps: Anything requiring thousands of active members before delivering value.
• Two-sided marketplaces: Products where you have to balance buyer and seller acquisition simultaneously.
• Generic AI wrappers: Prompts on top of an API with no proprietary workflow, data, or audience moat.
• Broad consumer utilities: Habit trackers or recipe apps reliant on tiny app-store subscriptions.
• Heavy compliance spaces: Ideas requiring banking licenses or legal certification before launch.

The project idea evaluation checklist

Before buying a domain or opening an editor, run your idea through this seven-point checklist:

Stop looking for a genius startup idea. Find a boring, painful, specific problem, build the smallest thing that solves it, and put it directly in front of people who already have their wallets out.