How to Validate a Startup Idea Before Writing Any Code

Writing code before validating an idea is the most expensive mistake a founder can make. Every line of code commits you to a specific solution before you know whether the problem is real, whether users care enough to pay, and whether your specific take is different enough to matter. Validation is not about proving your idea is right; it is about disproving it cheaply enough that you have runway left for the next attempt. This post walks through the specific validation methods that produce honest signal before you write a single component, when to use each, and how to interpret the results. Every method here can be done in a week for under 500 dollars, which is a fraction of what it costs to build the wrong product. The founders who validate consistently ship products that fit. The founders who skip validation ship products that die quietly. This is the discipline.

Talk to 20 People Before You Do Anything Else

The first validation is not a landing page or a prototype; it is 20 conversations with people in your target segment. These are not pitch meetings. They are learning conversations where you ask about the problem you think you are solving, listen to how the person describes their current situation, and try to disprove your assumptions. If 15 of the 20 people say they have never had the problem, your idea has no market. If 15 say they have the problem but are not currently paying anyone to solve it, you have a validation gap. If 15 say they have the problem and are paying, you have a signal worth building on.

The mechanics are simple. Recruit through LinkedIn, targeted Slack groups, or cold email. Offer a 30-minute Zoom call with no pitch, just curiosity. Take notes with timestamps. By interview 10, patterns emerge; by interview 20, you have a clear read on whether the problem is real and how it is currently being solved (or ignored). This step alone eliminates 40 to 50 percent of founder ideas that would otherwise be built and shipped to no one.

Ask about behavior, not opinion. Have you tried to solve this before, and what did you do tells you more than would you use a tool that does this. Users lie about future intentions and tell the truth about past behavior. Every interview question should be about the past. If a user has never invested time or money in trying to solve the problem you propose, they will not pay you to solve it either.

Follow up specifically about workarounds. What spreadsheet do they maintain. What manual process do they run every Friday. What does their VA do on their behalf. Workarounds are the strongest possible signal that a problem is real and painful enough to spend time on. A user with a five-tab spreadsheet solving your problem manually will pay for software that automates it; a user with no workaround usually will not.

Build a Landing Page Before Building a Product

Once you have validated the problem through interviews, build a landing page that describes the solution and asks for signups. This costs a day using Framer, Webflow, or Carrd, and it produces a real conversion signal. Drive traffic to it from LinkedIn posts, targeted subreddits, Product Hunt teasers, or a small ad budget (200 to 500 dollars on Google or LinkedIn ads). Measure signup rate against traffic.

The signal is not just the raw signup number; it is the conversion rate relative to a benchmark. Landing pages for real products typically convert at 2 to 8 percent of qualified traffic. If you drive 500 qualified visitors and get 15 to 40 signups, you have interest. If you get 3 or 4, you either have a bad landing page or a weak concept. Iterate on the landing page copy and design once before concluding the concept is weak; often the problem is presentation, not premise.

Track email opens and replies on the signups. If people who signed up respond to a follow-up email asking about their use case, you have engagement. If they signed up and never open your emails, the signup was performative. Real validation requires that users take a second action after the first. The landing page filters interest; the follow-up email tests conviction.

Write the landing page copy in the words of your interview subjects, not in your own founder framing. Quotes from real users become headlines and section text. This is why doing interviews before the landing page matters; you build the page around language that already resonates rather than guessing at the words that might land. Founders who write landing copy from imagination underperform founders who write it from transcripts.

Charge Money Before You Have a Product

The single strongest validation signal is a credit card charge. If someone will pre-order or pay for a beta seat before you have built anything, you have found real demand. If they will not pay, no amount of interview or landing page signal will overcome the fundamental question of whether people care enough to open their wallet.

Pre-sell using a simple Stripe payment link on your landing page. Frame it as early access at half price, founding member pricing, or reserve your spot with a deposit. Set the price at what you actually plan to charge, or slightly discounted. Refund every dollar if you decide not to build. This is not fraud; it is honest pre-selling that gives you real commitment data. Users who pay money are 10x more engaged than users who just leave an email.

The threshold I use: if you cannot get 10 pre-orders in 30 days at your target price, your concept is not validated. Do not build. Either the segment is wrong, the pricing is wrong, or the concept itself is weak. This is the hardest test to pass and the most valuable one to run. It is also where the startup and MVP discipline earns its keep: money changing hands is the truest possible validation.

Communicate a clear timeline with pre-orders. Delivery within 60 days or full refund guaranteed if we do not ship by X date sets expectation and builds trust. Users who pre-order want to know when to expect the product; vague timelines look sketchy and undermine the trust you built through interviews and landing page copy. Under-promise the timeline and over-deliver, but always give a specific date.

Build a Clickable Prototype in Figma

For validation questions that require the user to see how the product works (specific UX flows, complex workflows, new interaction patterns), a Figma prototype gives you a testable artifact without any engineering. A 10-screen prototype takes two to three days to build using off-the-shelf components (shadcn Figma kit, Untitled UI). Test it with 5 to 10 users via unmoderated tools like Maze or Useberry.

The prototype is not a design deliverable; it is a validation instrument. Its job is to answer whether users understand the product and can complete key tasks with only visual guidance. If 8 of 10 users complete the task successfully in under two minutes, the concept is understandable. If fewer than 5 complete it, the concept has communication problems that will not be fixed by code. Redesign the prototype first, then re-test.

What a Validation Prototype Should Include

• The landing page and pricing (to test message-market fit)
• The signup and onboarding flow (to test friction)
• The core value delivery screen (to test comprehension)
• One or two secondary screens (to test navigation)
• The upgrade or payment moment (to test intent)

Skip settings pages, admin flows, and edge cases. The prototype is not a comprehensive design; it is a validation tool focused on the questions that matter for the go/no-go decision.

Run the prototype test with users from your interview cohort when possible. They already understand the problem context, so they can evaluate the solution without needing extensive setup. Users cold to the concept produce noisier signal because their confusion mixes real UX problems with baseline unfamiliarity. Reserve fresh users for later usability testing after fit is established.

Ship a Fake Door Test

A fake door test is when you put a feature or product on your existing site (or on a fresh landing page) that does not exist yet, and measure clicks. If your feature idea gets 100 clicks in a week when placed prominently, users want it. If it gets 5, they do not. This is the cheapest way to validate specific features before building them.

The mechanics: add the feature to your navigation or dashboard with a real-looking link. When clicked, show a modal or page that says this feature is coming soon, join the waitlist. Collect email signups from clickers. If waitlist signups exceed 20 percent of clicks, the feature is validated. If they fall below 5 percent, the feature is a distraction from something more urgent.

The ethical rule with fake door tests: never lie about product capability, and always follow up with users who signed up. A fake door test that never delivers erodes trust. A fake door test that delivers within a reasonable timeline (or communicates transparently that the feature was deprioritized) builds trust because users see the transparency. Use this method sparingly; too many fake doors and your users learn to distrust your navigation.

Fake doors also work on marketing sites for validating new product concepts. Add a section to your homepage describing the new capability, measure clicks, and follow up with waitlist signups. This lets you test concepts adjacent to your current product without touching the product itself. If the click rate on the section beats your existing product sections, you have found an adjacent opportunity worth exploring.

Interview Existing Competitor Users

If competitors exist in your space, their users are your best research subjects. They have already validated that the category is real and that people will pay for a solution. Your job is to understand why they use the current solution, what they wish it did better, and what would make them switch. Ten interviews with competitor users tell you almost everything you need to know about how to position your product.

Recruit through LinkedIn (search for people who post about the competitor), through review sites like G2 and Capterra, and through targeted communities. Offer a 20-dollar gift card if response rates are slow. Read every G2 and Capterra review of the top three competitors; the reviews themselves are free research data that tells you what users love and hate about existing solutions.

The insight to look for: what are users using the competitor for that the competitor does badly, and what are users cobbling together outside the competitor to get the full job done. Both of those gaps are opportunities for a new product to serve better. Founders who ignore competitor research often build features competitors already have while missing the gaps competitors created. This kind of research complements our broader growth and marketing approach for positioning against incumbents.

Do not obsess over feature parity with competitors. A new product succeeds by doing one thing dramatically better than the incumbent, not by matching every feature. Pick the sharpest wedge, ignore the peripheral features, and build a product that a specific user segment prefers strongly rather than one that tries to serve everyone weakly. Wedges beat suites for early-stage products every time.

Set a Go/No-Go Deadline

Validation without a deadline is procrastination. Set a specific date (four to six weeks out) by which you will decide whether to build or shelve the idea. On that date, look at all the validation data (interview signal, landing page conversion, pre-orders, prototype test results, fake door clicks) and make an honest call. Do not extend the deadline unless something material changes.

The deadline creates urgency and forces decisions. Without one, founders drift for months collecting more signal and never committing. With one, the validation process compresses into the shortest possible window and produces a clear decision. This aligns with the QwiklyLaunch 45-day build philosophy: after validation, the actual build happens in a focused sprint. Validation feeds directly into build; drift feeds nothing.

If the answer at the deadline is go, book your build kickoff for the following week. Momentum matters. If the answer is no-go, take a week off, then start validation on your next idea. Founders who validate and rebuild produce more successful products over their careers than founders who commit prematurely to a single unvalidated idea.

Document the validation results honestly, even the failures. Every no-go decision is a lesson about your market, your judgment, or your process. Founders who track their own validation history get sharper each attempt because they see the patterns in what convinced them incorrectly before. Keep a running Notion doc of validation sprints and their outcomes; it becomes the most valuable strategic asset you own over your career.

If you want a partner to run the validation sprint with you and then build the SaaS in 45 days, get in touch and we will map the specifics for your idea. You can also see examples of validated builds on our projects page. Validate honestly, build fast, and let the market decide. That combination is what separates founders who ship products people want from founders who ship products people ignore.