The Demand Research Sprint: Validate a SaaS Idea in 7 Days

Most founders don't validate too little — they validate wrong. They talk to three friends, skim a subreddit for an afternoon, and decide they have a market. Or they do the opposite and never decide at all, reading demand research forever because no step ever tells them "this is enough to start."

The fix is a bounded sprint. Give yourself exactly seven days, run the same sequence every time, and force a verdict on day seven. Not "maybe," not "it depends" — a written yes/no with the evidence sitting next to it. Here's the day-by-day framework.

Day 1 — Write down the assumption

Start by writing the single riskiest assumption in one sentence, the way you'd pitch it to a stranger:

"People who [do X] are wasting [time or money] on [current solution] and would switch to a tool that [does Y]."

This is your demand hypothesis. Every day of the sprint is testing that sentence. The rest of the plan is built from it, so get it sharp before you look at anything. If you can't write that sentence, you're not ready to research — you're still brainstorming, and that's a different (shorter) day.

Day 2 — Gather raw signals, don't judge yet

Now you go where the people who would buy this talk. Don't build anything and don't evaluate — collect.

For each of the main platforms your audience lives on, pull every post that touches the problem: the complaint, the workaround, the "is there a tool for this?", the feature request, the "I gave up and built it myself." Record the platform, the post, and roughly how recent and how specific it is.

This is exactly the raw material DemandOrca pulls and clusters from public Bluesky posts automatically, but you can do the first pass by hand. The point of day two is volume and scope, not filtering. You want to feel the shape of the problem before you start triaging it. If you only find a handful of posts, that's data — note it, don't force it.

Day 3 — Classify what you found

Now you switch from collector to analyst. Group every signal into a bucket:

• Buying intent — someone ready to pay or switch, describing cost. "I'd happily pay for X if it did Y."
• Pain — a real, current problem with cost attached. "I lost two hours yesterday on this."
• Workaround — they're solving it suboptimally today. "I keep a spreadsheet for this."
• Nice-to-have — mild interest, no cost. "That'd be neat."

The pain-points vs nice-to-haves line is the one that matters most: a nice-to-have is not demand no matter how many people mention it. Only the first three buckets count toward your hypothesis. And when you're tagging, filter hard for the false demand signals that trick you — the people who'd only switch if it were free, the friends answering politely, the one loud voice that isn't a market.

Day 4 — Find the pattern behind the signals

This is the insight day. Take your real signals (buying + pain + workaround) and ask: who is behind them? Not what tool they mention — what kind of person. Cluster by the speaker, not the surface topic.

You're looking for the people who have the buying intent, the current pain, and the workaround — all three. That intersection is your customer. If the signals cluster into a coherent, numerous persona and the pain is current and costly, your five demand signals that predict a SaaS will succeed are present. If the signals point in five different directions with no recurring person, you have noise, not a market.

Day 6 — Talk to ten of those people

Social signals tell you demand exists. They don't tell you whether you can serve it. The only way to learn that is to talk to the people you identified. Send ten personalized messages to the ones with real buying intent — not templates, real messages referencing what they said. Use an interview script to make each conversation count.

You're not selling. You're confirming the pain is real, current, and costly, and — critically — what they'd already pay to remove it. If they name a price they'd hand over today, you have a budget. If they say "it's a minor annoyance," that's a nice-to-have, whatever the pile of posts said.

Day 7 — Decide

This is the only day with a binary output. Lay out what you collected and answer the two questions:

1. Is the demand real and recurring? A dozen people with current, costly, specific pain across a week beats a hundred generic mentions.
2. Can you serve it better than the workaround? Your workaround test — if people are solving this with spreadsheets and email today, your bar for "better" is low and that's exactly where you win.

If both answers are yes, the sprint's verdict is a product spec — and your next step is a waitlist of real buyers who've already told you they'd pay. If either is no, the verdict is a note on what the data said, not a failure — you spent seven days instead of six months.

The whole framework, in one line: collect without judgment, classify by cost, cluster by person, talk to ten, and force a verdict on day seven. Do that and you're not guessing whether your idea has demand — you're running the cheapest experiment that can tell you.

And if you want the collecting and clustering days to take minutes instead of days, that's what DemandOrca does. It watches public Bluesky posts, classifies the demand signals, and groups them into opportunities you can build against — so your sprint starts on the conversation, not the crawl. See what people are asking for right now.