Idea and demand: build what someone is waiting for
Products die not from bad code but from 'nobody needs it'. We learn to find ideas in personal pains and niches, validate demand in an evening (search, competitors, a landing test) and pick a first-product-sized idea.
In 2021 the analyst firm CB Insights read through the post-mortems of more than a hundred dead startups. The number one cause of death: "no market need" — 35% of cases. Not broken code, not a weak team, not money. A product nobody was waiting for. That's why this course opens with a question, not a keyboard: who is actually going to use this?
The story worth starting with: Dropbox
It's 2007. Drew Houston wants to build file sync, but building the real thing means months. So instead he records a three-minute demo video: here's how it will work — even though it doesn't work yet. The video hits Hacker News and Digg. Overnight the waiting list jumps from 5,000 to 75,000 addresses. Demand proven before most of the code exists. That's the logic of this lesson: signal first, construction second.
Where working ideas come from
- Your own pain: what do you do the clumsy way, over and over? You're user number one and an expert in the problem. That's how Basecamp was born: the agency 37signals got sick of running projects out of their inbox and built a tool for themselves.
- The pain of a niche you know: your job, your hobby, your community. "A CRM for tutors" beats "a CRM for everyone", because you speak their language, know their fears and know where they hang out.
- Complaints about what exists: your competitors' one- and two-star reviews are a ready-made order list. People are literally writing your spec for you: "great app, but there's no PDF export and it dies on big files."
A Socratic pause
Before you read on, sit with this: if your idea has no competitors at all — is that a good sign or a bad one? Instinct shouts "brilliant, I'm first!" More often an empty field means plenty of people got there before you and hit the same wall: nobody pays for this.
Validating demand in one evening (before you build!)
- Is anyone looking for a fix? Deep research: "how do people solve [problem] today, what do they search for, what do they complain about" (the method from our research course). If people are actively googling and arguing about it, the demand is alive.
- Are there competitors? Competitors are GOOD news: they already proved people pay for this. The bad cases are zero competitors (maybe there's no demand) or giants giving it away free, who you can't out-punch head on.
- The landing test: a page describing the product (an evening's work — you can do this) plus an "I want access" button with an email field. Show it in two or three places where your audience lives. A dozen real emails from the right people means: build it.
That's how Joel Gascoigne tested Buffer in 2010: he put up a landing page with pricing before there was a product. Clicks on "Plans and Pricing" showed people were willing to pay. Only then did he sit down to write code.
Beginner myths
- "Build first, show later." It's backwards: showing is cheap, building is expensive. Do the cheap thing first.
- "Someone will steal my idea." Ideas are nearly worthless — execution and getting to customers is what costs. Secrecy kills more products than thieves ever did.
- "I need a brilliant new idea." You don't. You need a known pain, solved a little more neatly, for a narrow audience.
What a first-product idea looks like
- A narrow audience you can actually reach (you know where they are)
- One core function, not a platform
- An obvious reason to pay (it saves time or money, or brings in customers)
- The MVP fits into 2–4 weeks of evenings
Telling a signal from politeness
The trap in demand validation is mistaking politeness for intent. "Great idea, I'd definitely try it!" from a friend carries zero information — people hate disappointing you. Real signals cost something: an email address, money up front, time spent (they filled in a long form, they showed up to a call). Rob Fitzpatrick's book "The Mom Test" put the rule plainly: don't ask "would you buy it?", ask about the past — "how do you handle this problem today, and what does it cost you?" Past behaviour doesn't lie; promises lie constantly.
How this links to other courses
Validating demand is really a small research project: how people solve a problem, what they search for, what they complain about. Our AI research course goes deep on that skill, and you'll build the landing test itself with the technique from the vibe coding course. Here we tie them together into one product step.
Do this now (10 minutes)
Write down 3 ideas from the sources above → run each through the four criteria → for the best one, draft a single landing sentence: "[Product] helps [who] [do what] without [the pain]." That's your demand-test draft. We start building in the next lesson — but only what passed the test. One evening now saves months later.
Short questions on the lesson — with an explanation for every answer.