I’ve shipped a lot of side projects. Most of them went nowhere.
Not because the code was bad. The code was fine. Cursor and Claude Code made the code the easy part. They went nowhere because I built the wrong thing, confidently, for six weekends in a row, and only let myself notice after I’d already sunk the time.
That’s the trap nobody warns you about when building gets cheap. Marc Lou shipped 35 startups. Thirty flopped. Five pay his bills. The lesson everyone misreads from that is “ship more things.” It isn’t. It’s “stop babysitting the one that isn’t moving.” Getting emotionally attached to one idea is the most expensive habit in this game, because the cost of being wrong is no longer the code. It’s the months you refuse to walk away.
So I changed the order of operations. Now, before I open the editor, I make myself answer nine questions in sequence. Each one has to be grounded in something I can actually point to, not a vibe and not a confident paragraph from a model that wants to please me. If an idea can’t survive the nine, it doesn’t get a repo. That kill is not a failure. It’s the quarter I get back.
Here are the nine.
Is it worth building?
Not “is it cool.” Is there a real market with a real, unmet need. 42% of startups still die from no market need, in an era where you can build anything. Building faster does not fix a demand problem. This is the gate. If the honest answer is “I’m not sure anyone needs this,” everything downstream is decoration.
Who actually pays?
Your target market is a hypothesis. Your buyer is data. “Developers” is not a buyer. “Solo technical founders who’ve already shipped one product that flopped and are staring at the next idea” is closer. Name a specific person, describe when they feel the pain badly enough to pull out a card, and estimate what they’d pay. If you can’t name them, you don’t have a product problem. You have a buyer problem.
What actually hurts?
The Mom Test is necessary and not sufficient. Talking to users stops you inventing pain, but it doesn’t rank the pain. You need to know which problem is a hair-on-fire “I’d pay today” and which is a “yeah that’s annoying I guess.” Build for the first kind. The second kind is where good weekends go to die.
How do you win?
Every space has incumbents now, including the AI-built ones. So where’s the gap? Blue-ocean framing without the two-day workshop: list what everyone in the category competes on, then find the axis nobody’s serving. If your only answer to “why you” is “mine’s a bit nicer,” that’s not a wedge, that’s a coin flip.
What’s actually V1?
Scope creep is how you turn a two-week test into a two-month cathedral. Pick the smallest thing that tests the actual hypothesis from decisions 1 through 4. Not the smallest thing you can build. The smallest thing that would change your mind if it failed. Everything else is a feature you’re adding to avoid launching.
How do you charge?
“Charge what you’re worth” is not pricing. Van Westendorp for micro-SaaS gets you a defensible number without a $10k study: find the price where it feels too cheap to trust and the price where it feels too expensive to justify, and work the band between. Have tiers, have a reason for each, and know your rough unit economics before launch, not after.
Will they pay?
Intent is not revenue. The cheapest way to find out if people will pay is to ask them to, before you’ve built the thing. A smoke test: a landing page, a real price, a checkout that captures the click. If nobody clicks buy at $X, you just saved yourself the build. If they do, you’ve got the only validation that counts.
How do you launch?
There are maybe five traction channels that work for a solo founder and about a dozen that quietly waste your time. Pick your channels before you build, not the night before you ship, because the channel shapes the product. A thing you launch on Product Hunt is not the same thing you grow through SEO.
What do you export?
This is the one that’s specific to how we build now. The output of all that thinking shouldn’t live in your head. It should live in the config files your coding agent reads. The named buyer, the scoped MVP, the pricing, the positioning, the thing you’re actually testing, written into a .cursorrules or a CLAUDE.md so the agent builds the right thing instead of a technically-correct wrong thing.
Your agent is only as good as the context you hand it. Half of .cursorrules files I see are lint rules and formatting. The other half of the context, the half that decides whether you’re building the right product at all, never makes it into the file.
The point isn’t the nine questions
The point is the order. Build first, ask whether it was worth building second, is how you end up six weekends deep in something you can’t bring yourself to kill. Decide first and the kill happens cheaply, on a Tuesday, before there’s any code to feel attached to.
When I run ideas through this properly, a decent chunk don’t make it. That’s not the system failing. That’s the system working. The expensive path is the one where you find out after you’ve built.
So: what do you decide before you build? And what’s the last idea you should have killed a month earlier than you did?
I got tired of doing this in a messy Notion doc, so I built ShipFit to force the nine decisions in sequence and ground each one in real data — real competitor sites, sourced prices, actual reviews — instead of a confident guess. It spits out the config files at the end. It starts at $5 if you want to try it on your next idea.
답글 남기기