Without a product, how do I show value?

Use disposable artefacts: clickable mockups, narrated walkthroughs, manual concierge, or pre-sales — anything that forces an honest reaction without compiling.

How many interviews before I can conclude?

There is no magic number: aim for saturation (the same themes repeat) and unexpected quotes; in practice, 5–15 focused interviews often beat a month of specs.

Is launching a landing page enough?

A landing measures shallow interest; pair it with interviews or a costly action (qualified signup, pre-order, calendar commitment) for behavioural signal.

When do I know I can finally code?

When a risky hypothesis (who buys, why now, how much) is backed by recent facts — not only by your conviction.

How to validate a startup idea without writing a single line of code

Interviews, throwaway artefacts, and behaviour signals: a practical path to test an idea before the repo — and avoid paying for engineering to learn what five conversations would have told you.

The problem: confusing building with learning

Most founders start coding too early because code feels like progress. It is visible, addictive, and emotionally safer than hearing “this is not urgent enough to buy.”

But code is a terrible place to discover basic truths about demand. Once the repo exists, assumptions harden into UX, scope, and technical debt. You are no longer learning cheaply — you are paying engineering to ask questions that five sharp conversations could have exposed in a week.

Validating without coding is not procrastination. It is how serious founders buy clarity before complexity.

Why it fails: decks, likes, and fake proof

Pre-validation usually breaks for one simple reason: founders mistake interest for commitment.

Classic traps:

The pretty mockup trap — people compliment the interface, not the pain.
The supportive network trap — friends and followers reward courage, not market truth.
The “we need one more feature to test properly” trap — scope expands because the team is avoiding direct evidence.

Until somebody changes behaviour — pays, books a second call, shares internal data, or stakes reputation on the outcome — you do not have validation. You have polite noise.

A concrete method: four layers without production

Bet clarity — one sentence: “We believe [segment] will pay [price] for [outcome] because [recurring pain].” If it does not fit one line, sharpen before any artefact.
Problem-first interviews — 20 minutes, their workflow, not your pitch. Listen for vocabulary, frequency, implicit budget, current workarounds.
Throwaway artefact — Figma, narrated call, Wizard of Oz, shared sheet: enough to trigger a specific objection (“that does not fit our process”).
Costly signal — letter of intent, symbolic pre-order, light paid pilot, or repeated calendar commitment (not a single polite call).

Iterate layer by layer: if the bet holds, interviews confirm pain, the artefact creates useful friction, costly signal filters chatter.

Example: two teams, same idea, two learning budgets

Team A — six weeks of MVP. Week seven, first serious buyers: the problem was “nice” but not budgeted; partial rebuild.

Team B — ten days: ten interviews, a mockup, three manual pilot offers at a reduced price. Two companies expose a real procurement path; one drops after budget talk — free signal.

The story does not promise B wins; it shows learning can precede build without fairy tales.

What to do now

This week, force reality to answer you.

Write one brutal hypothesis in one sentence.
Run five problem-first conversations with no demo.
Show one throwaway artefact to three qualified people.
Ask for one costly signal: time, budget, data, or a pilot commitment.

If nobody pays a cost, your next step is not to code faster. It is to sharpen the bet.