How to Validate a Startup Idea Before Building It

Most startup ideas feel obviously good to the person who had them. That feeling isn't evidence. Validation is the process of replacing that feeling with something closer to proof, ideally before you've spent months or thousands of dollars building something nobody asked for.

Start by writing down what has to be true

Every idea rests on a handful of assumptions. Someone has a problem, the problem is painful enough that they'll pay to solve it, your solution actually solves it better than what they're doing now, and you can reach these people at a reasonable cost. Write these down explicitly. Most founders have never done this, and it's often the single most useful step in the entire process, because it turns a vague idea into a list of specific, testable claims.

Talk to the people who'd actually use it

Before building anything, talk to potential customers directly. Not friends who'll be encouraging regardless, actual people who fit the profile of your target user. Ask about their current process, what frustrates them about it, and what they've already tried. Avoid describing your solution too early in the conversation. The goal is to understand the problem as it exists today, not to get someone to politely agree your idea sounds nice.

A useful filter: if someone describes the problem with real frustration and mentions workarounds they've cobbled together themselves, that's a strong signal. If they shrug and say it's "not a big deal," that's a signal too, just not the one you were hoping for.

Test willingness to pay, not just interest

Interest is cheap. Almost everyone will say an idea sounds good if you ask them directly. What separates real demand from politeness is whether people will commit something, money, time, or a real action, before the product exists.

A landing page describing the product with a "pre-order" or "join the waitlist" button, paired with a small ad budget to drive traffic to it, tells you a lot. So does asking someone to pay a deposit for early access. If people won't commit anything small now, they're unlikely to become paying customers once the real product ships.

Build the smallest thing that tests the riskiest assumption

Once you've got some signal from conversations and a landing page test, the next step for a lot of ideas is a narrow, working version aimed at the single riskiest assumption left. If you're not sure whether people will actually use a service daily, build the thinnest possible version that lets a handful of real users try it and see what they do, not what they say they'd do.

This is where the platform choice matters. For products involving bookings, reminders, or any repeated interaction, a Telegram bot can be a fast way to get something real in front of people without the cost and delay of a full app. It's minimal enough to build quickly and real enough to produce honest behavioral signal.

Watch behavior, not feedback forms

Once something is live, even in a rough form, resist the urge to rely only on surveys and feedback forms. What people do tells you more than what they say. Do they come back a second time without being prompted? Do they tell a friend unprompted? Do they get annoyed when it's unavailable? Those are the signals that separate real validation from polite encouragement.

One thing that helps here in practice: working directly with whoever builds your validation MVP means the test can change quickly based on what you're actually seeing, instead of waiting on a change request to move through a larger team. If day three of testing shows people dropping off at a specific step, that step can be adjusted the same day, not after a meeting.

Know what would change your mind

Before you start testing, decide what result would make you stop or pivot. It's tempting to interpret every ambiguous signal as encouraging, especially once you're emotionally invested. Writing down your own bar for success, and being honest about it, protects you from talking yourself into a bad idea after the fact.

Getting help with the testable version

If you've done the talking and the landing page test and you're ready to build the smallest real version to validate an idea properly, describe what you're testing and get a straight read on what the minimum working version actually needs to include.

See SolaLab's services: what I build and what it costs