When Do Demand Signals Mean It's Time to Start Building?

Every guide on demand validation tells you to "find signals before you build." Fair enough. But none of them tell you when to stop looking and start building.

That gap kills founders in two ways. Some build too early — they see three complaints on Bluesky and spend three months on a product nobody wants. Others build too late — they keep collecting signals, waiting for certainty, and someone else ships the same idea first.

The truth is that demand signals don't arrive with a permission slip. You have to decide when the evidence is strong enough to act. Here's a framework for making that call without guessing.

The three thresholds: volume, consistency, and specificity

Before you write a line of code, you want to see all three of these in your signal data.

1. Volume — how many independent signals?

One complaint is an anecdote. Ten complaints from ten different people is a pattern. The question isn't "is there demand?" but "is there enough demand to sustain a business?"

A practical floor: at least 20–30 independent signals from separate people before you treat a problem as a real market. Not 30 mentions from the same thread — 30 distinct posts, comments, or conversations from people who don't know each other.

If you're scoring and ranking product ideas by demand, this is your first filter. Sort out the noise. Count the unique humans.

2. Consistency — is the signal stable over time?

A burst of complaints over one weekend is a reaction. The same complaint appearing steadily over weeks, across different conversations and contexts, is a structural problem.

This is why timing matters. If you only look at signals for a day or two, you can't tell the difference between a fad and a permanent pain. Watch the signal for at least 3–4 weeks before you trust the pattern. If the complaints are still coming after a month, the problem isn't going away on its own.

The workaround test is especially useful here. Workarounds — the spreadsheets, the manual processes, the duct-taped tool stacks — are structural by definition. Nobody builds a workaround for a problem they'll forget about next week.

3. Specificity — are they describing the solution or just venting?

"I hate managing my inventory" is a complaint. "I track everything in three Google Sheets and it takes me four hours every Monday" is a demand signal with a product spec attached.

Specificity is the difference between a problem people will pay to solve and one they'll just complain about. The more concrete the description — naming tools, naming time costs, naming money costs — the closer someone is to being ready to buy.

This is the same filter you use to separate pain points from nice-to-haves. Vague frustration is free. A detailed description of a broken process is a buying signal.

The two-week rule

Once you have all three thresholds — volume (20+ unique signals), consistency (stable over 3–4 weeks), and specificity (people describing concrete costs) — give yourself two more weeks.

In those two weeks, do three things:

Talk to five of the people who posted the signals. DM them. Ask what they're doing today, what they've tried, what they'd pay for. If you can't get five conversations from 30 signals, your audience isn't reachable — which is its own problem.
Check if anyone is already paying for a workaround. If people are spending money — even badly, even on a spreadsheet plugin or a VA — the demand is real. Pricing from demand signals starts here: the money already being spent is your proof and your pricing floor.
Write a one-page description of the product and share it with the people you talked to. Not a landing page. A plain text description: "Here's what I'm thinking of building. Would this solve your problem? What's missing?" If the response is "yes, when can I get it?" — build. If the response is "maybe" or silence — keep watching.

What "build" actually means

When the evidence is strong enough, "start building" doesn't mean "start coding." It means:

Build a waitlist first. Turn the demand signals into a waitlist before you build the product. If the signals are real, people will join. If they won't join a free waitlist, they won't pay for a product.
Build the smallest possible version. Not the full vision — the one thing that solves the core pain. If the signals say "I spend four hours every Monday on inventory," build the thing that makes it take 30 minutes. Nothing else.
Charge from day one. Free users tell you nothing about demand. The first version should have a price on it. If the demand signals were real, the people who complained will pay. If they don't pay, the signals were noise — and you found out in two weeks instead of six months.

The opposite mistake: waiting too long

Some founders read this and think "okay, I'll watch for a month, talk to five people, build a waitlist, and then I'll be ready." They never start. The signals keep coming, the spreadsheet keeps growing, and the certainty never arrives — because certainty doesn't exist.

Demand signals reduce risk. They don't eliminate it. At some point you have to find your first customers before building and accept that the evidence is good enough, even if it's not perfect.

The founders who win aren't the ones with the most data. They're the ones who know when the data is sufficient — and who act on it.

A simple checklist

Before you start building, you should be able to answer yes to every question:

[ ] At least 20 independent demand signals from separate people
[ ] Signals have been consistent for 3–4 weeks (not a one-time burst)
[ ] Signals are specific — people describe concrete costs (time, money, tools)
[ ] You've talked to at least 5 of them and they confirmed the problem
[ ] At least one person is already paying for a workaround
[ ] You shared a one-page product description and got positive responses
[ ] You have a waitlist with real signups (not just friends and family)

If you can't check all seven, keep watching. If you can — stop watching and start building.

The demand is there. The question is whether you're going to read about it or act on it.