Validate a business idea before you spend a dollar

Most ideas that fail do not fail because the person building them was lazy or unskilled. They fail because nobody wanted the thing badly enough to pay for it, and the founder did not find that out until the product was finished and the money was gone. This is the quiet tragedy of small online businesses: months of careful work, a clean checkout, a logo someone actually liked, and then a launch that lands in total silence. The execution was fine. The demand was never there. What we want to do instead is buy the cheapest possible evidence about demand before we commit anything that is hard to get back, which mostly means money and months. The whole discipline of validation is just that trade, made on purpose and made early.

It is worth being precise about what validation means, because it is often misread as building a small version and seeing if people like it. It is the opposite: you start from the assumption that the idea is probably wrong, and you go looking for reasons to kill it cheaply. That sounds bleak, but it is the most respectful thing you can do for your own time. A test designed to confirm what you already believe will always confirm it. A test designed to expose a fatal flaw, run before you have spent real money, is the difference between losing a weekend and losing a year. Everything that follows is a sequence of small, honest experiments arranged from cheapest to costliest, each one buying a little more evidence, each one with permission to stop.

When people say an idea is good, they almost always mean it sounds clever or that it solves a problem they recognise. Neither of those is demand. Demand is a specific, narrow thing: a group of people who feel a problem sharply enough that they are already spending time, money, or attention trying to make it go away. If they are not already doing something about it, even something clumsy, the problem is probably not painful enough to build a business on. So the first reframe is to stop asking whether your idea is good and start asking whether the problem is real and expensive for someone. Those are different questions, and only the second one predicts whether anyone will pay you. You can have a brilliant solution to a problem nobody is losing sleep over, and it will sell exactly as well as a bad solution to the same non-problem.

This is why a quick look at search behaviour is a fair first move, not as proof but as a temperature check. If you glance at Google Trends and the interest in the problem you are solving is flat or fading, that is not a death sentence, but it should make you more skeptical and more careful with the next tests. If it is rising, you still have to confirm that the searchers will pay, because attention and willingness to pay are not the same. The point of this stage is humility. You are trying to find the version of reality where you are wrong, because that version is sitting out there whether you look at it or not, and it is far cheaper to meet it now than after the build.

The single most common validation mistake is to describe your idea to people and listen for encouragement. Friends, family, and polite strangers are wired to be kind, so they tell you it sounds great, that they would totally use it, that you should definitely build it. None of that is information. The fix has a name in the literature, the mom test, and the rule behind it is simple: ask only about things the person has actually done, never about what they might do in the future or what they think of your idea. People are unreliable narrators of their own future behaviour and reliable reporters of their own past. So you steer every conversation toward the last time they hit this problem, what they did about it, what it cost them, and how they felt about the workaround they settled for.

In practice this means you never pitch. The moment you say here is what I am thinking of building, the conversation turns into theatre and the other person starts performing approval. Instead you ask them to walk you through the last time the problem bit them. When did it happen, what were you doing, what did you try, what did you end up paying for, what still annoys you about it. If they get animated, if they have already cobbled together a spreadsheet or paid for a tool they half-hate, you have found real pain. If they shrug and say it is not a big deal, believe them. The best outcome of these talks is not a yes; it is a precise, unglamorous picture of how people currently cope, because that tells you what you would have to beat and whether the gap is big enough to matter.

Once you start testing, the hardest skill is reading the results honestly, because the encouraging signals are usually the worthless ones and the meaningful signals are usually quieter and more uncomfortable. A vanity signal is anything that costs the other person nothing: a like, a kind comment, an enthusiastic I would absolutely use that, a poll where people vote for the option that makes them look good. These feel wonderful and predict almost nothing, because there is no cost to being wrong about them. A real signal is anything that costs the other person something they would rather keep: a deposit, a pre-order, a place on a paid waitlist, an unprompted repeat request, a referral to a colleague, time spent filling in a real form. Cost is what makes a signal trustworthy. The more it cost them to give it, the more it is worth to you.

The clean way to hold this in your head is to ask, for every encouraging thing that happens, what did this actually cost the person who did it. If the answer is nothing, file it as noise and move on, no matter how good it felt. People paying beats people praising, every single time, and it is not close. This is also why you should be suspicious of your own excitement. The signals that flatter you are the ones designed by human politeness to flatter you. Train yourself to feel a small flicker of distrust when a test goes suspiciously well on the cheap signals, and a small flicker of attention when someone does something mildly inconvenient to get what you are offering.

A few quick examples make the line concrete, because in the moment it is genuinely easy to mistake one for the other.

A smoke test, sometimes called a fake-door test, is the cheapest way to measure whether strangers will reach for something that does not exist yet. You put up a single simple landing page that describes the offer honestly, you give it one clear action such as a notify-me button or an email signup or even a pre-order button, and you send a small amount of real traffic to it. The traffic can come from a tiny paid ad, a post in a community where your buyers already gather, or an email to a list you already have. Then you watch what fraction of people who land actually take the action. That conversion rate, crude as it is, is a far better predictor of demand than any number of conversations, because the people clicking do not know they are part of an experiment and have no reason to be polite.

The honesty matters here, both ethically and practically. If you take pre-order money or deposits, you have to be able to deliver or refund, and you should say plainly that the thing is coming soon rather than implying it is ready. A notify-me button is the gentlest version and asks for nothing but an email, which makes it a weaker signal than a deposit but still a real one, since giving an email is a small cost. Keep the page boring and specific: who it is for, what problem it kills, what it will cost, one button. Resist the urge to make it pretty before you know anyone wants it. The whole value of this stage is that it costs a landing page and maybe twenty to a hundred dollars in ads, and it can save you the months a full build would have eaten.

If a smoke test measures interest, pre-selling measures conviction, and conviction is what you actually need. Pre-selling means asking people to pay, in full or with a deposit, before the product exists, in exchange for being first in line and usually a better price. It feels uncomfortable to ask, which is exactly why it works: the discomfort is the price of getting an honest answer. When someone hands over real money for something they cannot use yet, they are telling you, in the only language that does not lie, that the problem is worth solving and your version is worth waiting for. No amount of survey enthusiasm comes close. We have used this on our own stores, where what we chose to stock at Novus Supply was decided as much by who would put money down early as by what we personally liked.

The mechanics need to be clean and fair so that a pre-sell is validation rather than a liability. Set a clear delivery window, make refunds easy and obvious, and pick a threshold in advance, such as a minimum number of pre-orders, below which you refund everyone and quietly stop. That last part is what keeps pre-selling honest rather than reckless. If you would like the full operational version of this, including how to handle deposits, deadlines, and the awkward case where you fall just short of your number, the dedicated guide on pre-orders and pre-selling walks through it carefully. The headline, though, is simple: when you are unsure whether to build, try to sell it first, and let the wallets vote before you write a line of code or order any inventory.

The concierge or manual minimum viable product is the most underrated test of all, because it lets you sell the outcome before you have built the machine that produces it. The idea is to deliver the service entirely by hand, behind the scenes, for your first handful of customers. They pay for a result; they do not care that you are doing the work manually rather than through slick automation. If you are thinking of building a tool that does a thing, do that thing for people yourself first, by email, in a spreadsheet, over a call, however clumsily. This does two priceless things at once. It confirms that people will pay for the outcome, and it teaches you the actual shape of the work, including all the messy edge cases that you would never have guessed from the outside and that would have broken your automated version anyway.

This is more or less how a couple of our own products came to exist. Before we built Novus BG Remover as an automated tool, the underlying need showed up as people simply wanting backgrounds cleaned, and the manual version of meeting that need made it obvious which parts were worth automating and which were noise. The discipline here is to resist building the system until the hand-delivered version is so clearly in demand, and so clearly painful to keep doing by hand, that automation becomes the obvious next move rather than a hopeful bet. If you cannot find even a few people willing to pay for the manual outcome, no amount of automation will save it; you have simply learned that cheaply, which is the whole point.

Here is the rule that separates real validation from validation theatre: you must write down, before the test runs, the exact result that would make you stop. If forty people land on the page, how many signups or pre-orders mean continue and how many mean drop. If you interview ten people, how many have to describe real, current, expensive pain before you take the next step. Decide it in advance and in writing, because the moment results come in, you will be emotionally invested and you will find a way to read almost any number as encouraging. A founder without a pre-set threshold does not run experiments; they collect reasons to keep going. The threshold is what gives the test the power to actually change your mind, which is the only thing that makes it worth running.

Be honest that the numbers here are ranges, not laws, and they depend on your traffic and your price. As a rough feel, a notify-me landing page that converts cold traffic in the low single digits of percent is weak, the mid single digits is interesting, and ten percent or more is a strong pull worth chasing. Pre-orders are harder and the bar is lower, so even a handful of paying strangers from a small test is a meaningful yes. Interviews are qualitative, so the threshold is about pattern: if most of the people you talk to are not already paying to cope with the problem, that is a no. The exact figures matter less than the commitment to set them first and then obey them. Pick numbers you can defend to a skeptical friend, then let the result do its job.

All of these tests form a ladder, and the only sane way to climb it is from the bottom, spending the least money and time on the earliest rungs and only paying for the next rung once the current one has earned it. Conversations cost you nothing but a few hours, so they come first and they kill the most ideas. A landing-page smoke test costs a little money and a day of setup, so it comes next, once the interviews have given you the language to describe the offer. Pre-selling raises the cost and the conviction together. The concierge build costs real time per customer but no engineering, so it comes before any automation. And building the actual product, the most expensive rung by far, comes dead last, only after the cheaper rungs have all returned a yes.

The reason for this ordering is that each rung uses what the one below it taught you, and each one gives you a fresh chance to stop before the costs jump. The interviews give you the words for the landing page. The landing page tells you whether the words pull. The pre-sell tells you whether the pull is real money. The concierge work tells you whether you can actually deliver and what it really costs. Only then does building make sense, because by that point you are not betting on demand; you are responding to it. If you find yourself wanting to skip straight to building because the early tests feel beneath the idea, treat that impulse as a warning sign. The desire to skip validation is usually fear that the idea would not survive it.

It is fair to ask when all of this is theatre rather than diligence, because validation can be overdone, and a founder can hide inside endless testing to avoid the scarier work of actually shipping. The clearest case where you can skip most of it is when you already have a paying audience asking you, unprompted and repeatedly, for the exact thing. If existing customers keep requesting a feature or a product, are already trying to pay you for it, and you have the means to make it, then running a smoke test on demand you can already see is just procrastination dressed as rigour. The repeat unprompted ask from people who already pay you is itself the strongest validation signal there is, and you do not need to manufacture a colder, weaker one to confirm what real money is already telling you.

The other case for moving fast is when the cost of being wrong is genuinely tiny. If you can build the real thing in a weekend and it costs you almost nothing, the build itself is your cheapest test, and elaborate validation just delays the only experiment that matters. Validation earns its keep when the cost of being wrong is large, which for most online businesses means weeks or months of work and real money for inventory or tools. So scale the validation to the stake. Big, slow, expensive idea: climb every rung of the ladder and obey your kill thresholds. Small, fast, cheap idea you can reverse easily: spend less time proving it and more time learning from the live version. The discipline is not to validate everything forever; it is to never spend money you cannot get back on demand you have not seen.

If you want something concrete to do rather than a philosophy to admire, the next seven days are enough to move an idea a long way down the ladder. Spend the first few days finding five to ten people who plausibly have the problem and asking them, mom-test style, about the last time it bit them, never pitching, only listening for whether they are already paying to cope. If a clear pattern of real, current, expensive pain shows up, spend an afternoon building a single honest landing page with one action and write down your kill threshold before you turn on any traffic. Then send a small, cheap stream of visitors at it and read the conversion against the number you committed to in advance. That is a complete, defensible validation cycle, and it costs a week and pocket change rather than a quarter and your savings.

What you are really building with all of this is a habit of buying evidence before commitment, and that habit compounds across every decision you make as an operator. The founders who last are not the ones with the best ideas; they are the ones who waste the least time and money on the wrong ones, because they made the wrong ones reveal themselves early and cheaply. Treat every idea as guilty until the evidence makes it innocent, set the threshold before you look, and let people paying outweigh people praising. Do that consistently and you will not need to be right more often than anyone else. You will simply be wrong far more cheaply, and over enough rounds that is the entire game.