Many people validate demand by building the product first. Once an idea appears, they buy a domain, set up the project, add login, build an admin panel, connect payments, polish pages, and implement many features. After launch, they post it to friends and communities. Then they discover nobody signs up, nobody pays, and nobody responds. Only then do they ask: maybe the demand was not real?
This order is expensive. For indie builders, the scarcest resources are not coding ability, but time and attention. The most dangerous part of a project is not that you cannot build it. The real danger is spending a month building it and then learning that users do not care. The faster you code, the faster you lose when the demand is wrong.
Early validation is not about proving the product is perfect. It is about proving three things at minimum cost: whether someone has the problem, whether someone is willing to take action for a better solution, and whether someone is willing to pay with time, email, conversation, trial effort, preorder, or money. Until these are proven, do not rush into building the full product.
Validation Is Not Asking “Would You Use It?” It Is Watching Whether Users Act
Many founders do user research by asking directly, “If I built this product, would you use it?” Most users politely say yes. The question costs them nothing. Saying yes does not require them to actually use or pay. Hearing ten people say yes can easily make you believe demand has been validated.
The valuable signal is not verbal support. It is action. A user leaving an email is a weak action. Filling out a form is stronger. Booking an interview, sending real data, joining a waitlist, or trying a rough version is stronger still. Paying a deposit, preordering, or paying for manual delivery is a very strong signal.
Shift your validation goal from “get a positive answer” to “make the user take a small action.” The closer the action is to real usage and real payment, the stronger the signal. In the early stage, do not chase large numbers. Chase high-quality actions. Ten people willing to test with you are more valuable than one hundred people saying “sounds nice.”
Validating without code is not laziness. It is a more honest way to judge demand. You are not asking users to evaluate your idea. You are asking them to show, through action, whether the problem matters.
Method One: Use Problem Interviews to Validate Pain, Not Pitch Ideas
The simplest validation method is talking to target users. But an interview is not a pitch. You should not explain your idea and ask users to judge your solution. You should ask how they handled the problem in the past, what substitutes they use now, what loss the problem creates, and whether they have paid for similar solutions before.
Good questions focus on past behavior, not future promises. Do not ask, “Would you use a tool that automatically generates reports?” Ask, “When was the last time you made this report?” “How long did it take?” “What was the most annoying part?” “What tools did you use?” “Have you tried paid solutions?” “Why did you stop using them?” Past behavior is more reliable than future imagination.
Listen for concrete details. If users can clearly describe the scenario, frequency, frustration, workaround, and cost, the problem may be real. If they only say “sometimes,” “maybe useful,” or “I might need it later,” the signal is weak. When a problem is painful, users usually do not need much prompting. They can tell you many details on their own.
An interview does not need to be long. Twenty to thirty minutes is enough. Start with 10 target users. If 6 out of 10 mention a similar problem, and at least 2 or 3 are already using clumsy workarounds, the idea deserves the next validation step. If everyone describes a different problem, or only gives generic support, you should narrow the audience and scenario.
Method Two: Use a Landing Page to Validate Messaging and Conversion
A landing page is not a full product website. It is a test page for your demand hypothesis. It only needs to explain four things: who it serves, what problem it solves, what result it promises, and what the user can do next. You do not need a product or backend. A simple page plus a form can test whether users are willing to take the next step.
Specificity matters most. Do not write “use AI to improve efficiency.” Write “help Shopify sellers generate 20 product descriptions in 5 minutes.” Do not write “intelligent analytics platform.” Write “get a weekly alert when your website traffic drops and see which pages to fix.” Users only judge relevance when they can see their own scenario.
The call to action matters too. A weak action is “join the waitlist.” A stronger action is “apply for beta,” “book a demo,” “submit your data for one test run,” or “reserve the first-month discount.” If few people even leave an email, something is wrong with the messaging, channel, or demand itself. You do not need to abandon the direction immediately, but you should review whether the audience is specific, the pain is clear, and the traffic source is matched.
Do not judge landing page validation only by visits. One thousand visits with five emails means something very different from one hundred visits with twenty applications. In the early stage, pay more attention to conversion rate and user quality. Are the people who leave emails your target users? Do they reply to follow-up emails? Are they willing to share more information? Are they willing to wait for launch?
Method Three: Use Fake Door Tests to Prioritize Features
A fake door test means the feature is not built yet, but the entry point is visible. You observe whether users click it, fill out a request, or are willing to wait. This is useful when you have many possible features and do not know which one matters most.
For example, suppose you are building an SEO tool but are unsure whether users want keyword monitoring, page audits, content suggestions, or backlink alerts. You can build a simple page that lists these features as cards. When users click one, show a message: “This feature is in early access. Leave your email to get priority access.” Click and signup data can tell you which feature is more attractive.
Fake door testing needs clear boundaries. It is not about deceiving users. It is about validating interest early. After the click, be honest that the feature is not ready yet. Do not make users believe it is already available, and never charge for something you cannot deliver. A good fake door test is transparent: we are validating this feature, and if you need it, you can join the early access list.
The value of this method is that it helps you avoid building useless features. Many products die because they try to build too much at the beginning. Founders think completeness reduces risk, but early products need one painful, frequent, conversion-driving feature. Fake door testing lets users tell you priority through behavior, not imagination.
Method Four: Use Manual Delivery to Validate the Result
If your product is supposed to help users achieve a result, you can deliver that result manually before automating it. If you want to build an AI report generator, let users submit materials and manually create the report with existing tools. If you want to build a product image optimization tool, manually improve 10 images first. If you want to build a competitor monitoring tool, manually send a weekly monitoring email.
Manual delivery may not feel like a product, but it is a strong validation method. Users do not really buy automation. They buy the result. If users are willing to pay for or repeatedly use a manually delivered result, the result itself has value. Once the workflow repeats, demand is stable, and users are willing to pay, you can automate the most time-consuming parts.
Manual delivery also exposes real details. You may discover that user input is messy, requirements are unclear, the result users care about is different from what you expected, or the part they are willing to pay for is not the feature you planned to build. These insights rarely appear in surveys. They appear when you actually help users complete the task once.
Many early SaaS products are essentially “manual service plus a little tooling.” Do not chase full automation from day one. Full automation is good for scaling a validated workflow. It is not good for validating an uncertain demand. Walk the path manually first, then use code to lock in the repeated steps.
Method Five: Use Presales to Validate Willingness to Pay
If you want to validate payment, the most direct method is not asking whether users would pay. It is asking them to pay something. Presales can be simple: one explanation page, an early-bird price, a clear delivery date, and a refund promise. You do not need to charge a large amount. Even $9, $19, or a small deposit is more real than verbal support.
Presales work best when the result is clear, the delivery boundary is defined, and you can fulfill the promise. Examples include template packs, courses, reports, beta access, manual services, or a plugin first-year membership. It is not suitable for high-risk, uncertain, or compliance-heavy directions. Presales should not mean taking user money to gamble. It means validating the market within a clear promise you can keep.
If users do not preorder, it does not always mean demand does not exist. Maybe you lack trust, the price is wrong, the promise is unclear, the audience is wrong, or the product is not suitable for advance payment. But if users are not willing to pay a small deposit, book a demo, or join a waitlist, be careful. At minimum, your current message has not made the problem feel important enough.
The biggest value of presales is that it forces you to face the business question early. Many ideas can get likes and bookmarks. But when payment appears, the room gets quiet. Facing that silence early is much cheaper than facing it after building the full product.
A Simple Signal Strength Table
You can classify validation signals by strength:
Weak signals: likes, bookmarks, “nice idea” comments, friends saying they would use it
Medium signals: email signup, form submission, waitlist join, survey reply
Strong signals: interview booking, real data submission, beta participation, manual trial
Strongest signals: deposit, preorder, paid manual delivery, referral to similar users
Do not settle for weak signals. Weak signals show attention, but they do not prove the demand is worth building. Medium signals show users are willing to learn more. Strong signals suggest the problem may be real. The strongest signals get close to business validation.
A practical threshold is this: within two weeks, can you get 10 medium-or-better signals, or 3 strong signals, or 1 real payment signal? If you cannot, you do not necessarily need to quit, but you must adjust the hypothesis: change the audience, scenario, message, channel, or make the problem more specific.
Validation is not a one-time exam. It is repeated calibration. Every failed validation should answer one question: does the demand not exist, or did I talk to the wrong users, use the wrong message, choose the wrong channel, or set the barrier too high? If you can distinguish these reasons, you will not abandon good directions too early or stubbornly hold onto bad ones.
When Is It Time to Start Writing Code?
Not every project must wait for paid users before you write code, but you should have strong enough action signals. Maybe you have interviewed 10 target users and found a repeated problem. Maybe your landing page gets steady applications. Maybe people are willing to provide real data for a test. Maybe you manually delivered the result several times and users want more. Maybe you got early-bird presales. At that point, writing code is no longer blind building. It is amplifying demand that has already appeared.
Even then, do not build the full product at once. Build the smallest usable version around one validated action. If users mainly want reports, build reports first. If batch export is the painful part, build export first. If reminders are what users will pay for, build reminders first. Do not pile on login, admin panels, points, memberships, teams, and complex settings at the beginning.
The goal of an early product is not completeness. It is helping users complete one core task and want to come back. Only after this loop works should you talk about expansion. If the loop does not work, more features only make it harder to see what is wrong.
Summary
Validating demand without writing code is not avoiding development. It is protecting your development ability from being wasted on the wrong demand. Real validation is not hearing users say “I would use it.” It is watching whether users take action: leave information, accept an interview, submit materials, try a rough solution, wait for beta, pay a deposit, or pay for a manual result.
For indie builders, the best sequence is not idea first, code immediately. It is problem interviews to confirm pain, landing pages to test messaging, fake doors to test priorities, manual delivery to validate results, and presales to validate payment. Once signals are strong enough, then write code. Every line you write should amplify a demand users have already proven.
Homework
- Choose 1 project idea and write your core demand hypothesis: who has what problem in what scenario.
- Design 3 no-code validation actions: interview, landing page, fake door test, manual delivery, or presale.
- Define a pass threshold for each action, such as 10 emails, 3 interviews, or 1 paid manual order.
- Execute 1 validation action within two weeks and record real user actions, not verbal opinions.
Next Lesson
Landing Page Validation: use one page to test whether users are truly willing to take the next step.