Back to blog
product·June 17, 2026·8 min read·By Yehonatan Saadia

How to Validate Your Idea Before You Build It

How to validate a startup idea before building: why validation saves money, talking to real customers, the smoke test, pre-sales, a manual concierge version, and the signals that justify building.

The most expensive thing you can do with a new idea is build it before you know anyone wants it. I have watched founders spend months and tens of thousands of dollars turning an idea into a polished product, launch it, and hear silence. The painful part is that almost every one of those failures was avoidable. The market would have told them no much earlier and much more cheaply, if only they had asked before building. Learning how to validate a startup idea before building is the single highest-return skill a founder can have, and it does not require any code at all.

I work with founders across the US, Europe, and Israel, and the ones who succeed share a habit: they treat their idea as a hypothesis to be tested, not a truth to be defended. In this guide I will walk you through exactly how I help clients validate before we write a line of code, from talking to real customers to running a smoke test, asking for actual money, and delivering a manual version by hand.

Why validation saves money

Building software costs real money. Even with timelines compressed by modern tools, a first version is typically a few thousand to tens of thousands of dollars, as I lay out in my guide on how to build an MVP. Validation, by contrast, costs almost nothing: a few weeks, a landing page, some conversations, and maybe a small ad budget of $100 to $500 (roughly 370 to 1,850 ILS).

The math is simple. If your idea is going to fail, you want it to fail for $300 and three weeks, not $25,000 and three months. Validation is not a delay that slows you down. It is insurance against building the wrong thing, and it usually makes the eventual product better, because by the time you build, you know exactly what people will pay for. Founders who skip it are not moving faster. They are just spending more to learn the same lesson later.

Talk to real potential customers

The first and most important step costs nothing but courage: talk to the actual people who would use your product. Not your friends, not your spouse, not other founders. Find ten to twenty people who genuinely have the problem you want to solve, and have real conversations with them.

The trap here is pitching. The moment you describe your brilliant idea, people get polite, and polite feedback is worthless. Instead, ask about their behavior. How do you handle this today? How much time or money does it cost you? What have you already tried, and why did it not work? You are listening for evidence of real, painful, expensive problems, the kind people are already spending money or effort to solve. If nobody is currently doing anything about the problem, that is a warning sign, not an opportunity. People do not pay to fix things that do not bother them.

The smoke test: a landing page

Conversations tell you whether the problem is real. A smoke test tells you whether your specific solution gets attention. The classic version is a simple landing page that describes your offer as if it already exists, with one clear call to action: join the waitlist, get early access, request a demo.

Then you drive a small amount of targeted traffic to it, often $100 to $300 (about 370 to 1,100 ILS) in ads aimed at your real audience, and you measure. Do strangers, not friends, actually click and sign up? A landing page that converts visitors into sign-ups at a healthy rate is real evidence of demand. A page that gets traffic and crickets is telling you something important and cheap to learn. The key discipline is honesty: this only works if the visitors are real prospects who have never heard of you, because friends and family will sign up to be nice and teach you nothing.

Pre-sales and letters of intent

A free signup is a weak signal. A wallet coming out is a strong one. The single most convincing form of validation is someone committing something that costs them, before the product exists.

  • Pre-orders or deposits. Ask people to pay, even a small amount, to reserve early access. Money changing hands is the clearest possible proof that the problem is worth solving.
  • Letters of intent. For business-to-business ideas, a signed letter saying "we will buy this when it exists, at roughly this price" is gold. It is not a contract, but it puts a name and a number on the demand.
  • Paid pilots. Offer to solve the problem for a small group of paying customers as a pilot, even before the software is built.

Yes, asking for money before you have a product feels uncomfortable. That discomfort is exactly why it works. Anyone can say they love your idea. Far fewer will pay for it, and those who do are telling you the truth. If you cannot get a single person to commit anything, that is the cheapest and most valuable lesson you will ever get.

Build a manual concierge version first

Here is a step founders almost always skip, and it is one of the most powerful. Before you automate anything, deliver the outcome by hand. This is the concierge approach: for your first handful of customers, you personally produce the result your software would eventually produce, using spreadsheets, email, manual work, and whatever duct tape it takes.

Say your idea is an app that matches small businesses with the right grant programs. Before building it, you manually research grants for five real businesses, send them a tidy list, and see if they find it valuable, or even pay for it. You are doing the job the software would do, by hand, at tiny scale. This proves two things at once: that people get real value from the outcome, and exactly what the software needs to do, because you have now done it yourself. It is the difference between guessing at requirements and knowing them. When you do eventually build, you build with precision instead of assumptions, which is the whole point of a true minimum viable product.

Signals that justify building

Validation is only useful if you decide in advance what a yes looks like. Define your threshold before you run the tests, so you are reading evidence rather than rationalizing. The signals I look for, in rough order of strength:

SignalStrengthWhat it tells you
People pay before it existsStrongestReal demand, worth building now
Signed letters of intentVery strongNamed buyers at a known price
Repeat use of the manual versionStrongThe outcome delivers ongoing value
Healthy landing-page sign-up rateModerateThe offer gets real attention
Customers describe sharp, costly painModerateA problem worth solving exists
People say they like the ideaWeakAlmost nothing on its own

If the strong signals are there, build the smallest real version with confidence. If they are not, you have two good options that both beat building blindly: pivot the idea based on what you learned, or stop and save your money for a better bet. Walking away from a weak idea early is not failure. It is exactly what validation is for, and it frees you to find the idea that actually works. From there, the path to a built product is the one I cover in my idea to MVP guide.

The honest truth about validation

Validation will not give you certainty. Nothing does until real customers use a real product. But it dramatically improves your odds and slashes the cost of being wrong. The founders I respect most are not the ones with unshakable conviction. They are the ones humble enough to test their assumptions cheaply before betting their savings on them. Modern tools have made building faster than ever, which makes it tempting to skip straight to code. Resist that. The fastest path to a successful product still runs through proving someone wants it first.

If you have an idea and want help figuring out the cheapest way to test it before you build, that is a conversation I genuinely enjoy. Book a call and walk me through it, or reach out through the contact form. I would rather help you validate for a few hundred dollars than build you the wrong thing for twenty thousand. When the evidence is there, I can also help you turn it into a real first version, and if you are still weighing who should build it, my guide on hiring a developer to build your MVP covers that next step.

#validate your idea before building#startup idea validation#mvp#product development

Frequently asked questions

How do I validate a startup idea before building it?

Test your riskiest assumption cheaply before writing code. Talk to 10 to 20 real potential customers about their behavior, run a smoke test with a landing page and a small ad budget, ask for a real commitment like a pre-order or letter of intent, and deliver the outcome manually to your first customers. If the signals are strong, build; if not, pivot or stop.

How much does it cost to validate an idea?

Almost nothing compared to building. Plan for a few weeks, a simple landing page, some customer conversations, and a small ad budget of roughly $100 to $500 (about 370 to 1,850 ILS). The whole point is that if the idea will fail, it fails for a few hundred dollars and a few weeks instead of $25,000 and three months of building.

What is a smoke test?

A smoke test is a simple landing page that describes your offer as if it already exists, with one clear call to action like join the waitlist or get early access. You drive a small amount of targeted traffic to it, usually $100 to $300 in ads aimed at real prospects, and measure whether strangers actually click and sign up. It is a cheap way to see if your specific solution gets real attention.

What signals tell me an idea is worth building?

The strongest signal is people paying before the product exists, through pre-orders, deposits, or signed letters of intent. Repeat use of a manual concierge version is also strong. A healthy landing-page sign-up rate and customers describing sharp, costly pain are moderate signals. People simply saying they like the idea is weak and means almost nothing on its own. Set your threshold before you test.

Should I still validate now that AI makes building fast?

Yes, more than ever. Faster building makes it tempting to skip straight to code, but speed does not change the core risk: building something nobody wants. Validation still costs far less than even an AI-accelerated build, and it makes the eventual product better because you build exactly what people have shown they will pay for. The fastest path to a successful product still runs through proving demand first.

Keep reading

Have a project like this?

Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.