Seven quick tests to know if your startup idea is worth pursuing

A short grid to decide without a repo: buyer, pain, frequency, alternative, distribution, risk, and signal — before you commit engineering.

The problem

Many founders collect ideas, pitches, and decks, but still cannot tell which ideas deserve another week of focused effort. The issue is not a lack of ambition; it is the absence of fast filters that survive real stress-testing. Without guardrails, internal enthusiasm is mistaken for market signal, "differentiation" is overrated because it is obvious to the team, and the hidden cost of chasing a dead end is underestimated. The outcome is months of exploration with little net learning, roadmaps that shift without measurable cause, and decision fatigue that pushes teams to accelerate at the wrong time. An "interesting" idea is not a tested hypothesis; at best it is a starting point. The core problem is methodological: how can you decide quickly, with limited budget, whether an idea merits the next validation steps without falling into analysis paralysis or confirmation bias. A common twist is friendly feedback loops: peers validate to be supportive, which creates false confidence. The seven quick tests act as a counterweight by demanding reproducible external cues, not compliments. They also help when several ideas look "good": you compare evidence strength, not pitch polish.

Why it fails

Founder time is the only non-dilutable asset. Every week spent on an unstressed idea is a week you are not building the proof you will need to hire, raise, or sell. Investors and early customers rarely reward effort; they reward signal clarity. If you do not separate noise from signal early, you end up with a product that looks coherent on paper yet collapses under simple objections: why now, why you, why pay. Seven quick tests are not a substitute for exhaustive market research; they exist to prevent expensive early mistakes: targeting the wrong buyer, promising unverifiable value, ignoring satisfactory alternatives, or overestimating problem frequency. In startups, decision quality often depends on how fast you can correct course. Short, demanding checks increase learning cycles per quarter. That is the Lumor-adjacent mindset: less storytelling, more realistic constraints, and an obsession with what can be observed or measured, even roughly. They also make team debates healthier: you argue missing evidence instead of aesthetic taste. Finally, they protect internal trust: a reasoned "no" beats a directionless sprint.

A concrete method

The seven tests in practice

1. Verifiable problem test — State the problem in one sentence a stranger can understand without jargon. Then list three observable proofs it exists today (behaviors, costs, workarounds). If you only have opinions, you do not yet have a testable problem.

2. Who pays test — Identify who authorizes budget, not only who complains. If end user and buyer diverge, write two distinct profiles and check which one will support real payment or contractual commitment.

3. Current alternative test — What do people do without you? Excel, internal staff, status quo, indirect competitor: value must beat total substitution cost, not just list price.

4. Why now test — Regulatory shifts, cost pressure, competitive moves, or tooling changes: without credible urgency, sales cycles stretch and runway dies quietly.

5. Minimum promise test — What is the smallest claim you would defend in front of a skeptical buyer? If it is vague ("optimization", "time savings"), tighten until the outcome is observable.

6. Repeatability test — Does the problem recur often enough to justify a product, or is it a rare incident? Use short interviews and public data to estimate frequency without self-persuasion.

7. Real integration test — Which workflows, tools, or teams does your solution touch? The heavier the integration, the earlier you must simulate friction (procurement, IT, compliance).

Scoring without self-deception

For each test, allow "weak evidence" (internal email, screenshot, anonymized snippet) but reject purely narrative proof. If two tests are orange, check whether they compound: a strong alternative plus weak urgency is often worse than a single isolated red.

For each test, record a verdict: red (blocking), orange (risk), green (evidence-backed). One serious red can be enough to pivot or refine before expensive build. The goal is not a perfect score but an honest risk map.

Example

Picture a B2B team that wants to "automate ESG reporting for SMBs". The mission sounds compelling; the seven tests surface tensions fast. Verifiable problem: many SMBs still export CSVs to an external firm—clear behavioral proof. Payer: often the CEO or CFO, not the sustainability lead who feels the manual pain—budget validation must target the economic buyer. Alternatives: a shared Excel model and occasional consultants; switching cost is easy to underestimate. Why now: regulation eighteen months out creates mixed urgency; without a near deadline, deals stall. Minimum promise might be "produce a compliant report in thirty minutes from existing sources"—demoable in a session. Repeatability: monthly for some firms, yearly for others; pricing should reflect that reality. Integration: accounting connectors and access controls; a POC without SSO or roles proves little in the field. Consolidating these tests, the team either narrows to a tighter segment with nearer obligations or shrinks MVP scope to prove only report generation. Without this pass, they might code for six months against a fuzzy ICP. A second useful case: a local "Uber for handymen" marketplace fails payer tests (who funds quality guarantees?) and repeatability (episodic need). The tests force either a B2B model for agencies or embedded insurance with clear pricing—otherwise the idea stays attractive but untenable.

What to do now

Run your current idea through the seven tests in under two hours: no deck, one sheet per test with evidence and sources. Where you see red, design the smallest validation experiment for the coming week: five targeted interviews, a landing page with a commitment criterion, a throwaway prototype, or a comparative scan of alternatives. Share the grid with a co-founder or a blunt peer to fight bias. If Lumor or a similar approach is in your stack, use it to force realistic objections before you invest in build. The discipline is simple: better to kill a fragile idea fast than feed it because it feels comfortable. Your hypothesis pipeline becomes an asset: every documented rejection moves you closer to a market that will pay. Hold a biweekly review: untreated red is strategic debt; green without follow-up is aging evidence. Archive grids to compare what you believed six weeks ago—often more instructive than marketing dashboards.

Related reading


Lumor puts your idea in front of 13 AI roles to stress-test assumptions, surface blind spots, and deliver a verdict, scores, and an execution plan.

Frequently asked questions

Does one red test mean stop?
Not always — but it must become **priority zero** before build: a fuzzy channel with a perfect product still fails distribution.
Can a survey replace interviews?
Surveys capture stated intent; keep some interviews for real language and workflows.
Do the seven tests apply to B2C?
Yes—adapt buyer (user vs payer) and costly signal (retention, share, prepayment).
Where to deepen idea lucidity?
See [idea dead before code](/en/blog/is-your-startup-idea-dead-before-you-code) and [validate without coding](/en/blog/validate-startup-idea-without-coding).