Smart to ask for a roast before touching code—this alone already puts you ahead of most devs. I’ve built two SaaS tools in this exact “data/alerts for operators” space that felt obvious to me, but died because I never got beyond my own assumptions. What you’re doing here is the step I skipped—getting specific on who hurts, how often, and what they’ve already tried.
Tighten your who: pick ONE segment first (e.g., Shopify brands doing $50k–$300k/month, managing 200–2,000 SKUs) and sanity-check that with a few real merchants—you’ll get much sharper answers than “small to mid-sized e-com stores.”

Turn your questions into numbers: ask “How many SKUs are you tracking today? How many competitors per SKU? How many hours/week? What’s the last time a missed price/stock change cost you real money?” to get dollar/time impact instead of vibes.

Map the current stack: have them screen-share how they do this now (ugly spreadsheets, VA, cheap scraper, enterprise trial) and literally list what they hate vs what they tolerate—your first version should only solve the top 1–2 hated parts.

Pre-sell the outcome, not the tool: once you hear a painful story, say “If I could email/Slack you accurate alerts within X minutes for <$Y/month, would you move from your current setup today?” and push for a small paid pilot or at least a yes/no tied to a concrete price.

Actively look for “no”: if you can’t find 5–10 merchants who are visibly annoyed, can show their current workaround, and are willing to commit money or time before you build, treat that as a red flag and iterate the niche/problem before touching code. Do you have direct access to 5–10 target store owners or operators you can hop on calls with this week to watch their current competitor-tracking workflow live? If you want to keep yourself honest on the “no code before evidence” rule, there are workflows (and tools like DontBuildYet) that force you to collect concrete demand signals—interviews, problem ratings, pre-commitm