I get the same DM almost every week. It opens with "I have an idea" and ends with "should I build it?" The person on the other end is usually a lawyer, a teacher, a sales rep, an operations manager — someone with a full-time job and a real problem they keep bumping into at work. They've been chewing on the idea for weeks. They've sketched out screens in their head. They've maybe even bought a domain.
And every single time, they want me to give them a yes or no.
I almost never do. Not because I'm being coy, but because they don't actually need my opinion — they need a sharper question. Over the last year I've had this conversation more than a hundred times, and the same seven questions surface most of the answer before I say a word.
The "Should I Build This?" Question Stack
1. Who specifically has this problem?
Not "small business owners." Not "busy professionals." Name the human. "Independent paralegals at firms with under 10 attorneys who handle immigration cases." If you can't name the person at that level of precision, you don't have a target — you have a market category. We dig into why that matters in Niche Down or Die: Why "Everyone" Is the Worst Audience for a First App.
2. How often do they hit the problem?
Daily? Weekly? Twice a year at tax time? Frequency drives willingness to pay almost more than severity. A monthly headache that costs an hour is harder to monetize than a daily annoyance that costs ten minutes. If the answer is "rarely," the idea probably belongs in the kill pile.
3. What do they do about it today?
This is the most underrated question in all of validation. If your target user is currently solving the problem with a weird stack of spreadsheets, a Google Form duct-taped to a Zapier workflow, and a lot of swearing — you have something. If they're not doing anything about it, they don't actually feel the pain.
4. Have they ever paid to make it go away?
Past purchase behavior is the single best demand signal you can get without writing a line of code. Paying a freelancer, buying a course, subscribing to a tool that almost works — all of these prove the problem is worth real money to them. We cover the full set of demand signals in 7 Cheap 48-Hour Experiments to Test Demand Before Writing Code.
5. Why you?
This isn't a self-esteem question. It's a moat question. What do you know about this audience or this problem that a generic developer with the same AI tools doesn't? If the answer is "nothing," you're racing people with twenty years of head start. If the answer is "I lived this problem for a decade and I know exactly which corners they cut," you already have a structural advantage. More on that in Domain Expertise Is the New Technical Moat.
6. How will they find you?
Distribution kills more first apps than bad code ever will. Before you get excited about the product, write down the literal first 50 users — names, communities, channels. If your plan is "post on Twitter and hope," you don't have a plan. We unpack this in Distribution-First Thinking.
7. Will you still care about this in six months?
Most of the apps I've watched die didn't fail because the idea was bad. They died because the founder got bored. If you can't honestly say you'll still care about this exact audience and this exact problem in six months, the answer to "should I build this?" is no — even if every other answer is yes.
The honest reason most people ask
Most people don't actually want validation. They want permission. They want someone with a title to bless the idea so they can either feel safe building it or guilt-free abandoning it. Neither is useful.
The point of asking these seven questions is to make the answer self- evident. If you can answer all seven crisply, you don't need my opinion — you have a real shot. If you can't, you don't need my opinion either — you have homework.
What a "yes" actually looks like
Here's a real example from a recent conversation, edited only for privacy. A veterinarian wanted to build "a tool for vets." Vague. We ran the stack:
- Who: Solo-practice small-animal vets in suburban U.S. clinics, ages 35–55.
- How often: Every single appointment, when writing up SOAP notes after the visit.
- What they do today: Dictate into Apple Notes, then retype into the practice management system after hours.
- Have they paid? Yes — many already pay $30/month for generic dictation tools that don't understand veterinary terms.
- Why her: She's been a vet for 14 years and has watched five colleagues quit because of the documentation burden.
- Distribution: She runs a 4,000-member Facebook group of solo vets. She's been giving them advice for free for years.
- Six months from now: "I will care about this until I retire."
That's a yes. Not because the idea is brilliant — it's not, dictation tools are a crowded category — but because the founder is positioned to win in a way no outsider could replicate. Same product built by a random YC team would lose this race.
What a "no" actually looks like
Same week, different conversation. A finance manager wanted to build "an AI tool that helps everyone with their personal budget." The stack:
- Who: "Anyone with a budget." (See the problem.)
- How often: "Whenever they think about money."
- What they do today: "Probably nothing? Or maybe a spreadsheet?"
- Have they paid? "Some people use Mint or YNAB."
- Why him: "I'm good with money."
- Distribution: "I'd post on Reddit."
- Six months from now: Long pause. "Maybe. I have a few other ideas too."
That's a no. Not because personal finance is a bad space — it's actually huge — but because this person can't compete in it. He has no specific audience, no insight a competitor doesn't have, no distribution channel, and no obsession. He'd be three months in before realizing he was building Mint, badly.
If you're stuck between yes and no
Most ideas land in a fuzzy middle — some questions get strong answers, others get weak ones. That's the most common case, and it's where the ShiporDrop quiz is designed to help. It walks you through these same questions in a structured way and gives you a score per dimension, so you can see exactly where the idea is strong and where you have homework to do.
If you've been chewing on an idea for weeks waiting for permission, this is it: stop asking other people whether your idea is good and start answering the seven questions above as honestly as you can. That's the whole game.