Validate Before You Build (Seriously This Time)

Last winter I watched a developer friend ship a polished SaaS in nine days. Auth, Stripe, a dashboard that looked better than half the funded startups I have seen. He posted a launch thread, got a hundred likes, and told me he felt like he was finally onto something. Three weeks later I asked about revenue. He had two free signups and zero dollars. The product worked fine. He had skipped the part where you find out whether anyone wanted it badly enough to pay.

I have been on both sides of that story more times than I care to admit. I have also been the guy who spent a month validating something that turned out to be a dead end, felt stupid for a day, and then felt grateful for the next year because I did not build it. Validation is not glamorous work. It is the work that decides whether your next month is an investment or a write-off.

If you are trying to figure out how to validate a micro-SaaS idea before building, you probably already know the theory. Talk to users. Build a landing page. Do not fall in love with your solution. Fine. The hard part is not knowing what to do. It is doing it when building has never been easier, when every tool in your stack wants you to open an editor and ship, and when your brain would rather write code than hear a stranger say "interesting" and mean "no."

This is the whole article, really. Not how to build faster — that is Part 2. How to find out, cheaply and early, whether the thing you want to build deserves your time. This post is Part 1 of the Micro-SaaS From Zero series: validate first, build second. I will walk through the exact moves I use today: narrowing the problem, defining who has it, running a fake door, having the uncomfortable conversations, asking for money before the product exists, and reading the signals without lying to yourself. Some numbers below are made-up examples to show what good and bad outcomes look like. I will say when they are hypothetical.

One belief sits under all of it, same as everything else I write on Micro-SaaS Insider. Revenue is validation. Traffic is not. Likes are not. A friend saying "you should totally build that" is not. If you want a profitable micro-SaaS, you need strangers to hand you money, or a credible promise of it, before you treat the idea as real. Everything below is micro-SaaS validation in practice, not theory.

How to validate a micro-SaaS idea when building got cheap

Here is what changed, and why validation matters more now, not less. The cost of turning an idea into working software collapsed. What used to take three weeks of auth, billing, and database wiring is an afternoon with Cursor and a clear head. I use AI every day. It is one of the best productivity tools I have ever touched. It does not tell you what people will pay for. Those are different skills, and the second one is the whole game.

When building is cheap, building stops being a moat. If you can spin up your idea this weekend, so can the next developer, and the one after that. The barrier that used to protect early movers, the sheer annoyance of getting something to work, is mostly gone. What is left is demand. Do people have this problem often enough, painfully enough, and with enough budget, that they will pay you to make it go away?

That is the question validation answers. Not "is this a clever idea?" Not "could I build this?" Those are easy questions in 2026, dangerously easy. The question is whether a specific group of people will pay a specific price for a specific outcome. Validation is the process of collecting evidence for that claim before you commit a month of your life to code.

Think about the failure mode that got more common, not less. People build beautifully, fast, and constantly, and they build the wrong things faster than ever. My friend's nine-day SaaS is the pattern. The code was never the problem. He skipped the slow, annoying, deeply human work of confirming demand because the tools made it so easy to skip. I have felt that pull myself. Building is more fun than asking strangers whether they would pay. AI makes building even more fun. So the discipline you need now is the willpower to validate before you build, exactly when building has never been more tempting.

There is a useful reframe. In 2015, shipping something that worked was an achievement. In 2026, shipping is the cover charge. The achievement is being the one product in the flood that a specific person actually needs and remembers. Validation is how you find out whether you might be that product, or whether you are about to add another well-made thing to the pile nobody asked for.

What validation actually means (and what counts as fake progress)

People use the word "validation" loosely, and that looseness costs them months. Validation is not a vibe. It is not momentum. It is not the feeling that you are finally doing the startup thing. Validation is evidence that a real person with a real problem will give you real money, or a binding commitment to money, for the solution you propose.

Everything else is research at best and self-deception at worst.

The vanity metrics trap

Likes do not validate. Retweets do not validate. "Great idea, you should build it" from a friend does not validate, especially when that friend will never be your customer. Traffic to a landing page does not validate by itself. Ten thousand curious visitors who bounce in eight seconds teach you almost nothing except that your headline was intriguing or your ad targeting was broad.

I have seen founders treat Product Hunt upvotes like proof. I have seen them count Discord members, newsletter subscribers, and beta waitlist emails as if those numbers were revenue in disguise. They are not. They are top-of-funnel curiosity, and curiosity is cheap. The only upgrade that matters is when curiosity converts to payment or a credible promise of payment.

Here is a composite example, not a real company. Say you launch a waitlist and get 400 emails in a week from a viral post. Feels amazing. You build for two months. You email the list at launch and three people convert to paid. That is not validation that happened late. That is validation that never happened, and the email list was mostly people who wanted to cheer you on or collect free tools. The number that should have gated your build was not 400. It was three.

Revenue is the only finish line

I say this constantly because founders keep trying to negotiate with it. Revenue is validation. A paid pre-order validates. A deposit on a founding-member spot validates. Someone saying "invoice me when it is ready" and then replying to your follow-up validates. An email on a free waitlist validates a little, as a weak leading indicator, but it is not the finish line.

For a micro-SaaS aimed at solo founders and small businesses, my personal bar before I build is simple. I want clear evidence that a handful of strangers will pay real money, or put down a real deposit, for the thing I am proposing. Not "might pay someday." Not "would use if it were free." Pay, or commit to pay, with the price visible and the product unfinished.

That bar is not a law of physics. It is a risk-management rule from someone who has eaten the other outcome too many times. You can choose a lower bar if you are doing a weekend throwaway experiment. Raise the bar if you are quitting a job or spending serious savings. The point is to pick a finish line before you start, so you cannot move the goalposts when the weak signals roll in.

Why most builders skip validation (and what it costs them)

Validation is uncomfortable in a very specific way. It forces you to risk hearing "no" before you have the emotional armor of a shipped product. When you have code, a logo, and a landing page you stayed up until 2am polishing, a rejection feels like someone insulting your craft. When you have a half-page description and a question, rejection is just information. Cheaper information. Less ego attached.

Developers skip validation for reasons that sound reasonable. "I already know the problem because I have it." "Talking to users is sales, and I got into this to avoid sales." "A landing page will not show the real product, so the data will be wrong." "I need to build a prototype or nobody will understand what I mean." Sometimes those reasons are partly true. They are still expensive excuses if they keep you from learning cheaply.

The cost shows up later, when it is maximally painful. You have sunk a month or three into code. You have told friends and Twitter you are building something. Stopping feels like failure, so you keep going, adding features, hoping the next launch will be the one. That is how you turn a one-week validation miss into a six-month burial.

I once spent three weeks building a tool I was certain every developer needed, because I needed it badly. Turns out I was the market. The whole market. Fantastic tool for exactly one person, and that person does not pay himself. A week of conversations would have saved me the other two weeks. I did not have those conversations because building felt like progress and talking felt like stalling. I was wrong about which one was which.

The other reason people skip validation is that the indie hacker culture celebrates shipping. "Just ship it" is good advice when you are procrastinating on fear. It is terrible advice when you are procrastinating on demand. Shipping is not the hard part anymore. Shipping the wrong thing quickly is a new way to waste time, just with better GitHub green squares.

Start with a problem narrow enough to test

Validation starts before the landing page, before the interviews, before the clever domain name. It starts with a problem statement tight enough that you could explain it to a stranger in one sentence and they would either nod because they live that pain, or stare at you because it sounds like nothing.

Broad problems are not testable. "Help small businesses with marketing" is not a validation target. It is a category. "Alert Shopify store owners when a competitor changes prices on a specific product page" is a problem. You can find those store owners. You can ask whether they check competitor prices manually. You can measure whether they click a waitlist button for an alert tool at $29 a month.

Where real pains hide

Good problems are boring, specific, and a little tedious. They do not sound exciting at a party. The richest source I know is work people already hate doing. Repetitive tasks. Copy-pasting between tools that should talk to each other. Spreadsheets that became load-bearing infrastructure without anyone admitting it. Go where people complain: niche subreddits, profession-specific Slack and Discord servers, replies under frustrated tweets, support forums where users beg for features the platform will never ship.

When you see the same gripe three times from three different people, pay attention. When you see it once and it is your own gripe, be suspicious until you find the other two.

The search-volume trick I use for content works for products too. Guess how someone would describe the problem in Google, then check whether anyone searches for it. You are not hunting for fifty thousand monthly searches. You are hunting for a few hundred with weak results on page one. That pattern means demand exists and nobody good has bothered to serve it properly.

The three filters before you commit

Not every real problem is a good micro-SaaS business. I run three quick filters before I invest validation time.

First, do the people with this problem have money, or control a budget? Enthusiasm without budget is a dead end for paid software. Second, can you reach them somewhere specific, a community, a forum, a job title on LinkedIn, a tool they all use? Vague audiences validate poorly because you cannot find them cheaply. Third, is the pain frequent enough that monthly billing makes sense? A problem that stings once a year is a brutal sell no matter how real it is.

Plenty of honest frustrations fail one of those tests. Far cheaper to fail them on a notepad than after you have built the thing.

Define who you are building for before you pitch anyone

"Small businesses" is not an audience. "Marketing teams" is not an audience. An audience you can validate is a person you can describe well enough to know where they hang out and what they already spend money on.

The one-page ICP sketch

ICP sounds corporate, but the exercise is simple. Write down who feels the pain personally, not who might approve a budget someday. Their role. Their context, the tools they use daily, the industry if it matters. The trigger that makes the pain urgent this week, not someday. The workaround they use today, manual process, spreadsheet, VA, duct-taped Zapier, whatever it is.

If you cannot fill in those fields, you are not ready to validate. You are ready to brainstorm. That is fine, but call it what it is.

Say you are exploring a tool for freelance bookkeepers who reconcile a specific kind of Stripe payout mess every month. That is validatable. You can find bookkeepers in accounting subreddits and Facebook groups. You can ask how they handle Stripe payouts today. You can estimate whether $39 a month is trivial compared to the hours they burn.

Compare that to "a tool for anyone who uses Stripe." That is not validatable in a week. That is a platform fantasy.

Where those people actually gather

Validation fails when founders build a page and then spray it at the internet. You need a channel where your ICP already exists and you can show up without being spam.

Before you write copy, name two places your person congregates. A subreddit. A Slack community. A Facebook group. A hashtag people use when they complain about the problem. A conference where they actually talk shop, not just watch keynotes. If you cannot name two, you have a distribution problem before you have a product problem.

This connects to something I care about for solo founders: micro-SaaS distribution usually has to work organically because your LTV is too small to buy growth at scale. Validation is where you discover whether organic reach exists. If you cannot find ten people to talk to, you will not find a hundred to pay.

Run a fake door test before you write code

My favorite micro-SaaS validation move costs almost nothing and takes an afternoon. Build a landing page for the product before the product exists. Describe the problem, who it is for, what the tool does, and a price. Add a button that says "Start free trial" or "Join waitlist" or "Get early access." When someone clicks, capture their email and tell them it is launching soon.

You built a fake door. Now you measure how many people try to walk through it.

What to put on a fake door landing page

Keep it ugly and clear. One headline that states the outcome, not your product name. Three bullets that describe concrete behavior, not abstract benefits. A price anchor, even if you plan to change it later. "Starting at $29/month" on a page for a nonexistent product is a willingness-to-pay test for free.

You do not need a backend. Carrd works. A single Next.js page works. I have done this with nothing but a form that emails me submissions. The page is not your moat. The signal is.

Here is what a minimal fake door includes: painful headline tied to the problem, specific promise, three feature bullets written as outcomes, visible price, one CTA, email capture on click. Optional second CTA for people who want to talk: "Book a 15-minute call" with a Calendly link. That second path is gold for early interviews.

Drive traffic from the places you identified, not from your personal Twitter unless your followers match the ICP. Post in the relevant subreddit with value first, not a naked link. DM people who complained about the problem. Run a small ad test if you want faster data and can spend $50 without drama.

What conversion rates mean (and do not)

There is no universal benchmark because traffic quality dominates. A page that converts 15% of targeted visitors from a bookkeeping forum is a strong signal. A page that converts 0.5% of random Product Hunt browsers is noise.

Use rough guides, not gospel. For targeted traffic, email capture above 8-10% is encouraging. Between 3-8% is worth iterating on headline and offer. Below 2% from a relevant audience is usually a no unless you have a clear hypothesis for what is wrong.

Watch behavior, not just counts. Do people read the page and leave immediately? Do they click pricing but not the CTA? Do they submit emails and ignore your follow-up? Each pattern suggests a different fix. High bounce might mean wrong audience or vague headline. Email with no reply might mean weak pain or trust gap.

Made-up but realistic numbers: you send 250 targeted visitors from two forum posts and a handful of DMs. Twenty-two submit emails. That is roughly 9%. You follow up and eight reply. Three agree to a call. That is a yes to keep going, not proof of a business, but enough to earn the next week of work.

Compare to 250 visitors, four emails, one reply that says "cool, keep me posted." That is a no with politeness wrapped around it.

Customer interviews beat a hundred guesses

Numbers tell you whether people click. Conversations tell you why. You need both, and most builders skip the second because it is uncomfortable.

Customer interview questions that cut through politeness

Find five people who have the problem. Not friends. Not your mom. Strangers who match the ICP and will tell you the truth if you ask correctly.

Do not pitch on these calls. Ask how they handle the thing today. Ask what they have tried, what they hated, how much time or money it costs them monthly. Ask what happens if they do nothing. The magic question is some version of: "If a tool did X for you, what would make it worth paying for, and how much?"

Then shut up and listen. Take notes. Look for specifics.

"Yeah, that sounds useful" is noise. People are nice. "I pay a VA $200 a month to do this by hand" is gold. "We tried three tools and quit because of Y" is gold. "My boss would never pay for that" is gold even though it kills your B2B angle, because it saves you from building the wrong thing.

What gold sounds like versus noise

Gold sounds like recurring pain with a current cost. Time, money, risk, embarrassment, whatever form it takes. Gold sounds like workarounds that embarrass them a little when they describe them. Gold sounds like urgency, not "maybe someday when we scale."

Noise sounds like compliments, hypotheticals, and feature requests from people who will never buy. Noise sounds like you doing 80% of the talking. If you are selling on a validation call, you are doing it wrong.

Five honest conversations will reshape your product more than a hundred assumptions. They will also reshape your fake door copy, your price, and sometimes your entire ICP. That is the point.

I treat calls as evidence collection, not mini-pitches. When someone describes their workflow, I repeat it back to check I understood. When they mention a cost, I write the number down even if it is approximate. When they say they would never pay, I thank them and ask what would need to be true for payment to make sense. You are not trying to win the call. You are trying to leave with a clearer picture of reality.

Pre-sell your micro-SaaS before you write a line of code

Email signups are weak signals. Money is a strong one. If you can get someone to pay before the product exists, even a small amount, you have something worth building.

Paid waitlists and early-bird offers

Stripe makes this embarrassingly easy. Create a payment link for a founding-member rate, half off the planned price, or a refundable deposit that converts to credit at launch. Put it on the fake door page as an option above the free waitlist. "Join free" and "Lock in $19/month forever, pay $19 today" on the same page tells you who is serious.

You are not scamming anyone if you are honest. State clearly the product is not built yet. State what they get, early access, input on features, discounted rate, refund policy if you cannot deliver. People who pay under those terms are telling you something real.

For a micro-SaaS, you do not need fifty pre-sales. You need a handful. Three paying founding members from a niche audience is a stronger signal than three hundred free emails from nowhere.

When a deposit is worth more than a signup

Deposits filter for intent. $20 or $50 is enough to hurt slightly if someone is just being polite. Not enough to fund your retirement. Enough to separate "sure, add me" from "I want this solved."

If nobody will put down a deposit among people who verbally loved the idea, believe them. They loved the idea as a concept, not as a purchase.

One pattern I have seen work: offer a paid 30-minute onboarding call where you manually solve their problem once, using spreadsheets and scripts, while you build the product. Charge $100. If nobody pays for the manual version, they will not pay for the software version. If several pay, you have revenue, testimonials, and a blueprint for the automated product.

That is validation and early cash at the same time. Boring. Effective.

How to read the signals without fooling yourself

By now you have conversations, page metrics, maybe a few payments. The failure mode shifts from skipping validation to misreading it.

Green lights and red flags

Green lights: strangers describe the problem without you prompting. They already pay for a workaround, time, tools, people. They ask when they can start, not whether you will build it. They reply to follow-ups. They refer you to a colleague with the same pain.

Red flags: you spend most conversations explaining why the idea is good. People say "interesting" and go quiet. High traffic, no clicks. Emails that ghost when you mention price. Everyone loves it but "needs approval" with no path to the approver. Competitors exist and customers seem fine with them.

None of these alone is a final verdict. Stack them. One red flag might mean bad copy. Four red flags mean move on.

My personal bar before I build

I already mentioned the bar: a handful of strangers willing to pay or deposit. Here is what passing looks like in composite form.

Two weeks in. Ten conversations completed. Six describe the pain as weekly or daily. Fake door page sent 300 targeted visitors. Twenty-eight emails, five deposits at $25. Three calls where people named existing spend on workarounds above $100 a month. I would start building the smallest version that delivers the core outcome.

Same two weeks, different outcome: ten conversations, three mild pains, rest polite. Two hundred visitors, six emails, zero deposits, one call. I would not build. I would either sharpen the problem, change the audience, or kill the idea and bank the learning.

Write your own bar before you start. Put it in a note. When you are tempted to ignore it because you really want to build, read the note.

When to kill an idea (and when stubbornness is justified)

Killing an idea feels like failure. It is the opposite. It is a successful experiment that returned a result: this configuration of problem, audience, and offer is not a business yet.

Kill when you cannot reach the ICP cheaply after honest tries. Kill when pain exists but frequency is too low for subscription pricing. Kill when everyone has a workaround they tolerate. Kill when you keep changing the ICP to rescue the idea. Kill when the only people who love it are builders, not buyers.

Stubbornness is justified when signals are mixed but fixable. Low conversion with a vague headline is fixable. Test a new headline. Low deposits with a high price might mean test a lower anchor, not abandon ship. Conversations that disagree on features but agree on pain mean narrow the scope, not quit.

The difference is whether the evidence points to "wrong offer" or "wrong problem." Wrong offer gets a iteration. Wrong problem gets a grave.

I killed a project last year after validation, and it stung for a day. I had a name and a domain I liked. I had told people I was working on it. The fake door got traffic but almost no emails from the right people. Calls revealed the pain was real but monthly software was the wrong shape; people wanted a one-time service. That is useful. I did not build the SaaS. I would have hated supporting it.

A two-week micro-SaaS validation sprint

If you want a schedule, here is how I would spend fourteen days validating a SaaS idea before building, assuming evenings and a normal day job, not a full-time sprint.

Days 1-2: pick the niche you understand or can access. Write the ICP sketch and problem statement in one paragraph. List ten places those people gather. Lurk and collect complaints. No building.

Days 3-6: reach out for conversations. Goal five to ten calls. Use DMs, community posts, your network only if it matches ICP. Take notes in one doc. Look for repeated pain, costs, workarounds.

Days 7-8: write fake door copy from what you heard. Build one page. Add price and email capture. Add optional deposit link if you are ready to test money.

Days 9-11: drive targeted traffic. Forums, communities, small ad test, personal outreach to people who complained publicly. Aim for a few hundred relevant visitors, not tens of thousands of random ones.

Days 12-13: follow up every email and deposit personally. Ask what they need most. Offer three more calls if you are thin on conversation data. This is where many validations die quietly. Founders treat the landing page as set-and-forget, send one batch of traffic, count emails, and never talk to the humans behind them. The follow-up is not optional. It is where you learn whether the emails meant anything.

On day 12, email every signup individually. Not a Mailchimp blast. A short personal note with one question: "What would you need this to do on day one for it to be worth paying for?" Replies separate real pain from polite curiosity. For deposit payers, ask if they would hop on a 15-minute call. You owe them that anyway.

Day 14: decide against the bar you wrote on day 1. Build, iterate the offer, or kill. Write down what you learned even if you kill it. Future you will validate the next idea faster. I keep a simple doc called "dead ideas" with one paragraph each: what I tested, what signal I got, what I would do differently. It sounds depressing. It is actually one of the most valuable files I own, because patterns repeat. Same weak traffic source, same vague ICP, same vanity metric I tried to negotiate with. The doc stops me from making the same mistake with a new domain name attached.

Notice what is missing from those fourteen days. Almost no code. Maybe a landing page builder. No auth, no database, no AI-generated scaffold you will throw away when the idea dies. The ratio is deliberate. Validation should feel a little lopsided toward talking and measuring, because building will get all the attention soon enough once you have earned it.

If you pass and start building, Part 2 of the series picks up where this leaves off. Validation earns the right to open the editor. It does not replace the work of shipping something people can actually use.

Common questions about validating a SaaS idea

How do you validate a micro-SaaS idea before building?

Start narrow: define who has the problem and where they gather. Run five to ten customer interviews without pitching. Put up a fake door landing page with a visible price and drive targeted traffic. Ask for a deposit or pre-sale before you write product code. If strangers will not pay or commit to pay, the idea is not validated yet.

What is a fake door test for SaaS validation?

A fake door is a landing page for a product that does not exist yet. You describe the problem, the outcome, and a price, then measure how many targeted visitors click through and leave an email or pay a deposit. It tests demand before you spend weeks building. Ugly and clear beats polished and vague.

How long should micro-SaaS validation take?

Two weeks of focused work is enough for a first pass if you already have a niche in mind. Week one is conversations and research. Week two is a fake-door page and a pre-sale attempt. If you cannot get a single money signal in two weeks of honest effort, the idea probably needs to change, not more time.

How many customer interviews do I need?

Five honest conversations with strangers who have the problem is a solid minimum. Ten is better if you are entering a niche you do not know well. What matters is not the count but whether you hear the same pain unprompted, with real workarounds and real costs attached.

What conversion rate on a fake door landing page is good enough?

There is no universal number because traffic quality matters more than volume. As a rough guide, if ten percent or more of targeted visitors hand over an email on a page for a product that does not exist yet, that is encouraging. Below two percent from a relevant audience is usually a no, unless your offer or headline is clearly wrong and you have a specific fix to test.

Should I validate with a free tier or charge from day one?

Validate willingness to pay, not willingness to sign up. A free waitlist tells you almost nothing about revenue. Put a price on the page, offer early-bird pricing, or ask for a small deposit. Free users are research subjects who cost you support time. Paying customers, or people who commit to pay, are validation.

When is it okay to skip validation and just build?

When the build is tiny and disposable, and you are building for yourself as customer number one with a problem you feel weekly. Even then, talk to a few people before you spend a month on it. The only case where I skip formal validation is a weekend experiment I am willing to throw away entirely. Anything bigger earns a week of demand work first.

What if people say they love the idea but nobody pays?

That is the most common outcome, and it means the idea is not validated yet. Politeness is free. Payment is not. Go back to your ICP, rewrite the offer, raise the urgency in your headline, or pick a sharper problem. Love without money is a hobby, not a business signal.

Before you open your editor

Validation is not the fun part. Nobody posts a screenshot of a spreadsheet where they decided not to build something. There is no badge for killing an idea in week two.

Do it anyway.

The builders I watch succeed are not the ones with the cleverest ideas or the fastest prompts. They are the ones who refuse to treat code as progress until strangers prove they will pay. In 2026 you can build in a weekend. You can also waste a year on a weekend's worth of enthusiasm if nobody wanted it.

My friend with the nine-day SaaS took the lesson. He spent the next month talking to people, ran a fake door, got a handful of deposits, and built something smaller and less impressive that customers pay for every month. Boring. Profitable. Which was the whole point.

So pick a problem narrow enough to test. Write down who has it and where they gather. Build the fake door. Have the calls. Ask for money before the product exists. Set a bar and hold yourself to it.

If the signals say no, you did not fail. You bought back months of your life.

If the signals say yes, then open Cursor and build the boring thing people already told you they would pay for. That is when AI becomes an unfair advantage instead of a faster way to fail. You validated a micro-SaaS idea before building. Now the build is the easy part, and you have already done the hard one.