The Pre‑Build Idea Audit: 9 Quick Signals That Tell You Don’t Build (and What to Test Instead)

Most founders confuse ‘I want to build’ with ‘people will pay for this’. The pre‑build audit reframes the question: do real customers exhibit behaviors that make building worthwhile? Pretotyping and lightweight validation methods — fake doors, concierge MVPs, landing‑page presales — are designed to answer that in days, not quarters.

The point of these experiments isn’t a polished product; it’s measurable commitment. Pretotyping pioneer Alberto Savoia popularized doing cheap, quick simulations to test demand before expensive engineering. If the audit raises red flags, run one of the suggested rapid experiments below instead of starting a full build.

Each signal below is a quick, observable indicator that your idea currently lacks the behavioral evidence to justify engineering time. If you spot one or more, don’t tweak product scope — pause and run the paired experiment.

These aren’t wishy‑wash market research items. They focus on behavior (not opinion) and on signals that reliably predict wasted engineering cycles: expressed interest that doesn’t convert, nebulous buyer identity, outsized reliance on features, negative unit economics, and so on.

Continue the checklist and pair each remaining red flag with a concrete, single best experiment you can run in days to measure real demand.

For each experiment I specify what to measure and what signal means ‘stop’ vs ‘go’.

Template A — Fake‑door (best when you need to test feature demand quickly): Build a single landing page or an in‑app CTA that promises the feature with a clear CTA: “Get early access — reserve for $X.” Route the CTA to a simple payment or ‘reserve’ form. If you can’t accept money, capture a refundable deposit or require a calendar reservation. Measure conversion rate from targeted users and follow up personally.

Template B — Concierge MVP (best for outcome‑heavy or complex workflows): Sell the outcome at real price, deliver manually for the first customers, and document time/cost to serve. Use the manual engagement to refine the onboarding questions and delivery steps. Measure repeat purchases, gross margin when manual tasks are measured, and customer willingness to keep paying once you announce automated roadmap.

Run each experiment with a clearly defined minimum‑success threshold before you start. For example: 50 paid presales from a targeted list, 3 paying concierge customers with positive ROI after manual costs, or a fake‑door 2% paid conversion from warm traffic. Predefine your stop/go thresholds and the time window (often 7–21 days).

Decision framing: “Stop” means the experiment fails to reach the pre‑set threshold; do not build. “Pivot” means you learned something specific (wrong pricing, wrong channel, different persona) and run a new, focused test. “Go” means the experiment validates the riskiest assumption (value + willingness to pay + channel) and you can responsibly allocate engineering time.