How to validate an AI SaaS idea before you build it

Why AI ideas fail differently than regular SaaS ideas

AI SaaS ideas fail through a specific set of traps that don't apply to a normal CRUD app, and recognizing them early saves months of building the wrong thing well.

The most common trap is the thin wrapper problem: a founder puts a prompt in front of a chat interface, calls it a product, and discovers that the actual value delivered is closer to what a user could get by pasting the same prompt into ChatGPT themselves. The wrapper adds convenience, not defensibility, and convenience alone rarely supports a price above a few dollars a month once a free alternative exists.

The second trap is model commoditization risk. Whatever clever prompt or fine-tune gave you an edge six months ago is often absorbed into the base model's next release, for free, to every user of that model. If your entire pitch is "we do X well with GPT," the vendor can and sometimes does ship X as a native feature, and your product loses its reason to exist overnight.

The third is variable inference cost, which regular SaaS founders don't have to think about at all. A normal SaaS product costs roughly the same to serve a light user and a heavy user, hosting is cheap and mostly fixed. An AI product's cost per user can vary by 50x depending on how long their documents are, how many retries a bad output triggers, and whether they're on a cheap model tier or a frontier one. Founders who price like a normal SaaS company, flat monthly fee, unlimited usage, often find their heaviest users are the ones destroying their margin.

The fourth is the feature not a product trap: many AI ideas are genuinely useful but small enough that an existing tool in the user's stack will absorb the capability as a feature within a year. "Summarize my meeting notes" is useful, but it is also the kind of thing a note-taking app, a calendar app, and a CRM will all ship natively, which means the standalone version needs a reason to survive that isn't just doing the one thing well.

Rule of thumbIf you can't describe your product without saying "powered by GPT-4" or "using AI to," you haven't described the product yet, you've described the ingredient.

Demand signals you can check in a week without writing code

Before building anything, you can gather real demand evidence using tools you already have open in a browser, and it should take a focused week, not a quarter.

Do all five in the same week and write down what you find in one document, with links. The goal isn't a polished report, it's forcing yourself to look at actual evidence before you fall in love with the idea in your head.

• ▸Search demand: use a free keyword tool to check whether people are searching for the problem, not the solution category. "How to summarize sales calls" has more signal than "AI meeting summarizer" because it shows the underlying job, not just interest in the buzzword.
• ▸Existing paid alternatives: if three or more products already charge money for something adjacent, that is a good sign, it means someone has proven people will pay to solve this class of problem. Zero paid alternatives after years of the underlying technology being available is a yellow flag, not a green one, it usually means the willingness to pay isn't there.
• ▸Complaint mining in subreddits and Discord servers: search for your target user's community and look for recurring complaints about the manual version of the task. A complaint repeated by different people across months is worth more than a single detailed rant.
• ▸Competitor pricing pages: read the pricing pages of the two or three closest existing tools. Their tier structure tells you what buyers already accept as normal, and their feature gating tells you what they consider valuable enough to charge extra for.
• ▸Job posts: search job boards for the exact task you want to automate. If companies are hiring humans, often overseas contractors, to do the task manually, that is a strong signal the job is real, valuable, and currently expensive to do without software.

How to size a niche without a spreadsheet fantasy

Sizing a niche means counting real people who have the problem and a budget, not multiplying a total addressable market figure by a hopeful conversion percentage.

The spreadsheet fantasy looks like this: "there are 30 million small businesses in the US, if we capture just 0.1% at $50 a month, that's a $15 million business." This math is fake because it assumes uniform demand across a wildly non-uniform population, and it tells you nothing about whether a single one of those businesses has ever searched for your solution.

A grounded version starts from the other direction. Find a specific, countable list: companies that use a certain tool, people with a certain job title on LinkedIn, subreddits with a known member count, directories of businesses in a niche. Count how many of them plausibly have the problem at a frequency and severity worth paying for. If that number is in the low thousands and each is worth $50 to $200 a month, you have a real, if modest, business, and modest is fine at the start.

Then check the willingness-to-pay ceiling by looking at what this exact audience already spends on adjacent tools. A niche full of solo freelancers rarely supports $300 a month contracts, no matter how good the product is, because the budget simply doesn't exist in that segment.

The smoke test ladder

The smoke test ladder is a sequence of increasingly costly commitments you ask a prospect to make, each rung filtering out people who were only being polite about the last one.

• ▸Rung 1, landing page: a single page describing the outcome, not the AI mechanism, with an email capture. This tests whether the pitch is compelling enough to make a stranger give up their email.
• ▸Rung 2, waitlist with a qualifying question: instead of just collecting emails, ask one question that only a real prospect could answer, like "what tool are you using for this today?" Empty or vague answers here mean the traffic isn't your buyer.
• ▸Rung 3, manual concierge delivery: deliver the outcome by hand, using existing tools, spreadsheets, and your own labor standing in for the product you haven't built. This is slow and unscalable on purpose, its only job is to prove the outcome is valuable enough that someone will go through the process to get it.
• ▸Rung 4, paid pilot: ask for money before the product is fully built, even a small deposit or a discounted first month in exchange for being an early customer. Money moving is the only rung that fully separates real demand from curiosity.

Rule of thumbSkipping straight to building because rung 1 got 200 email signups is how founders end up with an email list and no customers three months later.

What a real validation signal looks like versus politeness

A real signal costs the other person something, money, time, or a piece of their own workaround data, while a polite signal costs them nothing and commits them to nothing.

The rule of thumb is that anything a person can say while doing something else, half-listening on a call, scrolling past a tweet, is polite. Anything that requires them to stop, open a file, or pull out a card is closer to real.

• ▸Polite: "This looks really cool, I'd definitely use something like this." Real: they send you the actual spreadsheet or document they currently use to do the task manually.
• ▸Polite: "Yeah, I'd probably pay for that." Real: they ask when they can start paying, or they actually put in a card number for a waitlist deposit.
• ▸Polite: a warm reply in a DM thread. Real: they introduce you to a colleague who has the same problem, unprompted.
• ▸Polite: filling out your waitlist form with a generic answer. Real: filling out the qualifying question with specific, frustrated detail about their current process.

Running the Mom Test on AI workflows specifically

The Mom Test says a good validation question is one that can't be answered with a comforting lie, and applying it to AI products means asking about the current manual workflow instead of the future AI feature.

Because AI tools are novel enough to feel exciting in the abstract, people are especially prone to giving optimistic, hypothetical answers about them. Anchoring every question to a specific past event, not a future intention, is the single most effective defense against that optimism bias.

• ▸Bad: "Would you use an AI tool that drafts your client emails?" Anyone can say yes to this with zero cost.
• ▸Good: "Walk me through the last client email you wrote. How long did it take, and what part did you rewrite three times?"
• ▸Bad: "Do you trust AI-generated output for this task?"
• ▸Good: "Have you ever used any AI tool for this before? What happened, did you keep using it or go back to doing it manually?"
• ▸Bad: "Would this save you time?"
• ▸Good: "What do you currently pay a person, a tool, or an agency to do this, and how much?"

Validating willingness to pay before you build anything

Willingness to pay is a different question from willingness to use, and confusing the two is how founders end up with active free users and no revenue.

The cleanest way to test willingness to pay pre-build is to sell the manual concierge version from rung 3 of the smoke test ladder at the price you intend to eventually charge for the automated product. If ten people pay $99 for a hand-delivered version of the outcome, you have real evidence for a $99 price point. If nobody will pay $99 for the hand-delivered version, no amount of AI polish is going to fix that, the price or the value proposition is wrong, not the delivery mechanism.

A second useful test is offering a founder's rate discount in exchange for a longer commitment, three or six months paid upfront, before the product exists in full. People who take that deal are telling you something a survey response never could.

Avoid the trap of validating willingness to pay with a single low-friction dollar, a $1 pre-order or a heavily discounted lifetime deal. These convert too easily to tell you anything about your real price point and can leave you supporting underpriced customers indefinitely.

Cost of goods reality check for LLM calls

Cost of goods for an AI product is the cost of every model call, retry, and embedding lookup needed to deliver one unit of value, and it needs to be modeled before pricing, not after.

Start by writing down the actual sequence of API calls a single customer action triggers, including calls you didn't originally plan for, like a verification pass on the model's own output or a retry when the first response fails validation. Multiply each call's token count by the current price per token for the model tier you intend to use in production, not the cheapest demo tier you tested with.

Then model this at the 95th percentile of expected usage, not the average. A support-ticket summarizer priced around an average of 50 tickets a month falls apart financially the moment a customer with 2,000 tickets a month signs up on the same flat plan, and in practice that customer usually does sign up, because heavy users are disproportionately drawn to tools that promise to save them time.

Build in a usage-based ceiling or an overage tier from day one rather than promising unlimited usage on a flat fee. It is far easier to launch with sensible usage limits than to claw back an unlimited promise from existing customers later.

Rule of thumbIf you can't say, within a dollar, what it costs to serve your heaviest realistic user, you don't have a price yet, you have a guess.

When to kill an idea

Killing an idea means stopping active investment in it, and the right trigger is a pattern of failed asks after genuine outreach, not the first rejection you receive.

• ▸Kill it if ten or more qualified prospects, people who match your niche and have the problem, decline the paid pilot after a real ask, not a soft mention.
• ▸Kill it if the manual concierge version takes so long to deliver that no automation could plausibly make the unit economics work, even at scale.
• ▸Kill it if every complaint thread you find about the problem is old and dormant, with no recent activity, which usually means the pain faded or a solution already won quietly.
• ▸Kill it if your cost of goods at realistic usage exceeds what the market has shown it will pay, and no plausible pricing tier closes the gap.
• ▸Do not kill it just because the first five people you asked said no, or because building feels harder than you hoped, those are normal parts of every idea, not signals specific to this one.

How a public launch works as cheap validation

Launching on a founder directory like LaunchLoop is a low-cost way to get your product in front of real people who click, upvote, and leave structured feedback, and it works best as one validation input alongside direct outreach, not as a replacement for it.

The value of a launch is that the traffic is not hypothetical. People visiting from a launch page actually click through to your site, and the founders who leave feedback have usually built something themselves, which tends to produce more specific, structural comments than a general audience would give you, things like a confusing pricing page or an onboarding step that buries the value.

Because LaunchLoop supports relaunching after an update, you can treat each launch as a checkpoint rather than a one-time event: launch with the smoke test landing page, see what clicks and what feedback comes in, fix the sharpest issue, and relaunch once you've shipped the manual concierge or the first real version. Each round gives you another sample of reactions from people outside your existing network, which matters because your own network's opinions get stale and biased toward encouragement the more times they've seen your idea.

It is worth being honest about what a launch cannot tell you. Upvotes measure interest in the pitch on that day, not sustained willingness to pay, and a strong launch day says nothing about retention six weeks later. Treat launch traffic and feedback as one more data point to log alongside your outreach and pilot results, not as the final verdict on the idea.

Rule of thumbA launch tells you if the pitch lands with founders who look at products for a living. It does not tell you if your actual target buyer will renew in month three.

Turning validation into a build decision

A build decision is the point where you commit real engineering time, and it should be made on accumulated evidence from multiple sources, not on a single strong reaction.

Before writing production code, you should be able to point to at least a few things: a documented demand signal from search or complaint threads, a handful of people who went through the manual concierge process, one or more actual payments or deposits collected, and a realistic cost of goods estimate at heavy usage that still leaves room for a healthy margin at your intended price. None of these individually is sufficient, together they make a build decision far less of a bet.

It's also fine to build a narrower version than your original idea. Often the validation process reveals that the real, provable demand is for a smaller slice of the original vision, one specific workflow for one specific segment, rather than the broad platform you first imagined. Building that narrow, proven slice first and expanding after is almost always cheaper than building broad and hoping the market catches up to the vision.