Validate Demand Before You Write Code
Product validation - 7 min read
A practical pre-build checklist for solo founders who want to use search demand, competitor signals, and user behavior before committing weeks to a new product idea.
The expensive mistake usually happens in a familiar order: a domain, a login flow, a polished interface, and then the late question: was anyone already looking for this?
Code makes an idea feel real. It does not show whether the problem was already real for someone else.
Before you give the next several weeks to a product, look for traces of the problem outside your head: search terms, competitor pages, support threads, manual workarounds, and pricing pages.
What made this a real pre-build problem
| Signal | What it means |
|---|---|
| Founder demand is visible | SaaS and indie-founder discussions keep returning to the same fear: spending weeks building before demand was checked. |
| Competitors already package this workflow | Tools such as NicheCheck and IdeaScanner position around pre-build market checks, which shows the category is already commercially legible. |
| The ShipOrStop wedge is narrower | The page is not trying to do full market research. It helps answer whether this idea deserves the next 12 weeks. |
Read the first signals this way
| Signal | Strong | Weak | Misleading |
|---|---|---|---|
| Search intent | The query describes an action, error, integration, comparison, or paid workflow. | The query is mostly a broad topic, definition, trend, or curiosity search. | High volume for a term that means several unrelated things. |
| Visible pain | Users repeat the problem in reviews, forums, support threads, or workaround guides. | Only one founder, friend, or internal stakeholder says the idea is interesting. | Positive comments that do not include time, money, risk, or workflow pressure. |
| Reachable wedge | A specific audience, platform, file type, industry, or workflow gap is visible. | The idea is a broad platform with no first user or first channel. | A competitor exists, but you cannot explain why a user would switch. |
Start with the words people already type
A useful product idea often leaves traces before the product exists. People search when an existing tool fails, when a workflow is unclear, when a platform does not cover the exact edge case, or when they need a faster way to finish a task.
Action-heavy search terms are usually more useful than broad idea terms because they show a user trying to complete a task.
- notion export to pdf not working
- airtable import api data
- youtube video summary
- figma to html
- shopify bulk edit variants
- chrome extension keyword tracker
Do not let one search term make the decision
Finding a promising search term is not enough. Before building, check whether search demand, visible pain, and existing alternatives appear together.
If you only have search terms, you have a lead. If you also see complaints and workarounds, you have a stronger reason to keep investigating.
- Search demand: users search for a task, failure, comparison, template, integration, export, import, or conversion.
- Visible pain: users ask about the same problem in forums, reviews, support threads, or communities.
- Existing alternatives: users solve the problem with plugins, templates, services, spreadsheets, scripts, tutorials, or competing products.
A competitor is a map, not a stop sign
Many founders stop when they find competitors. That can be too early. A competitor may show that someone already educated the market and that users know the problem can be solved.
Do not ask whether you can copy the product. Ask whether you can serve a narrower case more clearly.
- simpler onboarding
- lower setup work
- better support for one file format
- clearer output for non-technical users
- a workflow built for one role or industry
- pricing that matches a smaller user's budget
Find the first path to users before the build
Do not save distribution for after launch. Before writing code, ask where the first users could come from and what the smallest validation step should be.
The point is not to avoid building. It is to build after the demand signal is strong enough to deserve the time.
- search pages for action-heavy terms
- tutorials that solve the exact workflow
- comparison pages against manual workarounds
- Reddit or community posts where users already describe the pain
- browser extension stores, app marketplaces, or template galleries
Before you write code, answer these
1. Who has the problem?
Name a specific role, business type, creator type, team size, or workflow owner.
2. What would the user search?
List 5-10 real terms that include actions, failures, comparisons, integrations, or file formats.
3. What alternatives already exist?
Include competitors, plugins, templates, scripts, tutorials, agencies, spreadsheets, and manual workflows.
4. Why would someone pay?
Connect payment to time saved, money recovered, risk reduced, work completed, or a recurring business need.
Sources that show the pre-build problem
- Reddit SaaS validation discussion
Founders in the thread compare landing pages, competitor reviews, user calls, and small paid tests before writing product code.
- NicheCheck
A live example of packaging demand, competition, revenue potential, and channel checks before a founder commits to a build.
- IdeaScanner
A live example that treats search demand, competitor activity, pricing clues, and risks as pre-build work.
Read next if the idea still looks promising
Move from notes to a Phase 0 call
ShipOrStop is useful after you have a candidate idea, a few demand phrases, and known alternatives. Phase 0 turns those inputs into a scorecard you can accept, edit, or reject.