Idea validation

How to validate a software idea before you build it

Most software ideas do not fail because the code was bad. They fail because nobody confirmed the idea was worth building. Validation is how you find that out cheaply.

Guide · 6 min read

"Validation" gets thrown around loosely. It does not mean asking friends if your idea sounds cool. It means gathering evidence that real people will change their behavior to use what you are proposing. Here is a sequence that works whether you are a founder, a product manager, or a team lead with a backlog of bets.

1. Write down the riskiest assumption

Every idea rests on a stack of assumptions. One of them, if false, kills the whole thing. Usually it is not "can we build it" — it is "does anyone care enough to switch from what they do today." Name that single assumption in one sentence. If you cannot, you do not understand your idea well enough yet.

A good riskiest assumption sounds like: "Service-business owners will approve AI-drafted replies instead of writing them, because their inbox is the bottleneck."

2. Decide what evidence would change your mind

Before you test anything, decide what a pass and a fail look like. If five of seven target users complete the core action without prompting, that is signal. If they nod politely and never return, that is a fail. Writing the threshold down in advance stops you from rationalizing weak results later.

3. Build the smallest clickable test — not the product

You do not need a database, authentication, or payments to learn whether the core workflow lands. You need a believable, clickable version of the single most important journey, with realistic copy and mocked data. This is the difference between a clickable prototype and a static mockup: a prototype lets people act, so you observe behavior instead of opinions.

• Pick one user, one workflow, one outcome.
• Make it feel real enough that a stranger could use it without you narrating.
• Cut everything that does not test the riskiest assumption.

4. Put it in front of real users

Five well-chosen target users tell you more than fifty random survey responses. Watch where they hesitate, where they get excited, and where they quietly give up. Do not explain — let the prototype do the talking and take notes on behavior, not compliments.

5. Decide: build, revise, or drop

Compare what you saw against the threshold you set in step two. A clear pass justifies real engineering investment. A clear fail just saved you months. A murky result usually means the test was too broad — tighten the workflow and run it again.

How long should validation take?

Days, not months. If validating an idea takes a quarter, you have built the product instead of a test. A focused prototype and evaluation can be ready in about a week, which is the entire premise behind how Promptlaiy works and why an MVP prototype should not cost like a full build.

← Back to Promptlaiy