How to validate a SaaS idea before you write any code

In 2026 you can build a SaaS in a weekend. AI writes the boring parts. Tereza Tizkova wrote that you can vibecode your own tool instead of paying someone $50 a month for theirs. So people skip the hard part. They open a repo, ship a clean product, and stare at zero customers.

Pieter Levels said it in June 2026: everyone can build apps with AI. Almost nobody has an audience, money for ads, or a free way to get attention. Building got cheap. Proof that someone will pay did not. Validation is how you get that proof before the code exists.

Indiecity is for one person or a team under twenty. You do not need a research team. You need people who already have the pain, words they use when it hurts, and a price they will accept. Talk first. Build second.

What validation is (and is not)

Validation is evidence that a specific person will pay for a specific outcome. It is not a friend saying the idea is cool. It is not a Product Hunt upvote. It is not a waitlist of emails with no price on the page.

Real signals look like this:

• Someone describes the problem in their own words without you pitching
• They already spend time or money on a bad workaround
• They ask the price, or they book a call after they see it
• They pay, or they commit to a paid pilot with a date

If the only proof you have is “people said it was interesting,” you have compliments. Compliments do not count. Payment does. Ship first and you will learn this the expensive way.

The 2026 trap: ship first, learn nothing

In July 2026, Jack Builds wrote on Indie Hackers after four months of solo building. He coded the features. He polished the landing page. He set up onboarding. Launch day: zero paying customers, not one signup. He had never talked to a potential customer before he shipped.

That is not a launch problem you fix later. Four months with zero customer conversations is skipped validation. Empty analytics are what you get when you skip that work. Code feels like progress. Conversations feel risky. So people build in a vacuum, then call the silence bad luck. It is work they skipped.

The fix starts before the editor. Talk about their life, not your idea.

Pass the Mom Test before you open the editor

Rob Fitzpatrick’s Mom Test is still the clean rule: talk about their life, not your idea. Ask what they did last time the problem hit. Ask what they already tried. Ask what it cost them in time or money. Do not pitch. Do not ask if they would use your product. People lie to be nice, especially people who like you. For the full call method, use customer interviews when you have zero users.

Bad questions invite empty praise. “Would you use an app that does X?” will get a yes that means nothing. Good questions sound ordinary:

• Walk me through the last time this broke. What did you do?
• What do you use now? What do you hate about it?
• Who else is in that workflow? Who signs off on tools?
• What have you already paid (tools, freelancers, overtime) to deal with this?
• If this disappeared tomorrow, what would you do instead?

Write down their words. Those words become the page. Not your clever category name. You will find the same words in public if you look where people already complain.

Find the pain already written down

You do not invent demand in a blank document. Search for “anyone know a tool that does X.” Read one-star reviews. Show up the same day someone vents. That person already named the pain. You did not invent it.

Do not confuse founder rooms with customer rooms. If your buyer is not a founder, Indie Hackers and launch feeds are still the wrong place. Sit in the Slack, Discord, forum, or trade group where the work already happens. Copy the sentences they use when they are angry. Note the workaround that already eats their week.

Build a short list before you write code:

1. One buyer you can name by job title (not “anyone with a laptop”).
2. One problem they hit on a schedule (weekly, monthly, every launch).
3. One current fix they already pay for or suffer through.
4. Thirty names or rooms where those people already talk.

Talk before you build

Send notes that ask for their story, not a demo of a product that does not exist yet. Keep learning calls and sales calls apart. On a learning call you do not pitch. You listen. You ask what they did last time. You shut up when they talk.

Hey [name]. I saw you mention [the messy thing in their words]. I am not selling anything yet. I am trying to understand how people like you handle it today. Could I get 15 minutes this week? I will only ask about what you already do.

Thanks for walking me through that. Just so I am clear: last time it cost you [time / money / risk], and you fixed it with [workaround]. If someone took that off your plate for [price], would that be worth a short pilot, or is this not painful enough to pay for?

You are listening for the same story three times from people who can pay. When the pain is real, they talk in details. When it is polite interest, they stay vague and change the subject. After you hear the story, put a price where they can see it.

Put a price on a page

A page without a price is a brochure. Put the offer in plain words: who it is for, what outcome you remove, what it costs, what happens next. One page is enough. No blog, no feature grid, no fake testimonials. Test the idea with a landing page and a price once you can name the buyer.

Charge a number you can say without wincing. If you hide the price, people treat the work as free research. If they flinch at the number, you learn something. If they never see a number, you learn nothing.

What the page must do:

• Name the buyer and the pain in their words
• Show one outcome, not a feature list
• Show a price (or a clear range for a pilot)
• Offer one action: pay, book a call, or start a dated pilot

Send that page only after you understand the problem. Use it to ask for money or a calendar hold, not to collect vague interest. When someone pays, or books after seeing the price, you have a signal strong enough to open the editor.

A two-week validation plan (no code)

1. Day 1. Write the buyer, the problem, and a price on one page. List 30 names or rooms.
2. Days 2 to 6. Book five to ten learning calls. Mom Test only. No pitch. Capture exact phrases.
3. Day 7. Rewrite the page with their words. Keep the price. Cut anything they did not mention.
4. Days 8 to 12. Send the page. Ask for a paid pilot, a deposit, or a call that ends with a yes or a no.
5. Day 14. Count real commitments. If you have none after honest conversations, change the offer or the buyer. Do not start a repo to feel better.

Keep four columns: talked, same pain, saw price, committed. Add a fifth for the exact phrase they used. That phrase is your headline.

How you know it is real

People take the call. They describe a workaround you did not invent. They wince at a cost they already pay. Someone asks the price before you do. Someone pays, or sets a pilot date in writing. Those are the signals. “Keep me posted” is not one of them.

If twenty people who should care will not give you fifteen minutes, the problem is weak or you are talking to the wrong person. That is useful. It is cheaper than four months of code nobody ordered.

What to stop doing

• Opening a repo before you have talked to buyers.
• Asking “Would you use this?” and treating the answer as data.
• Building a free waitlist with no price.
• Polishing a landing page for people you have never met.
• Confusing founder applause with customer demand.
• Adding features to avoid sending the next message.

When you can write code

Write code when someone has paid, or when a paid pilot has a date, a scope, and a person who owns the problem. Until then, the product is the conversation and the page. After you have proof, ship the smallest thing that delivers the outcome they already agreed to buy.

Getting people to pay is the next job. How to get your first 10 paying customers without ads is the field guide for that week: a price, a named list, and a message that asks for the money.

Then you have a story

Validation is a short chain of real conversations, a priced page, and at least one commitment that costs the buyer something. Skip it and you will ship into silence. Run it and you know whether to build. If you validated the hard way and you will put your name on it, send us the story.

Until then, close the editor. Open the calendar. Ask about their life, not your idea.