--- title: "Pre-Launch Demand Evidence" date: "2026-07-19" canonical: "https://raytally.com/en/ideas/2026-07-19-if-you-build-it-they-will-come/" generator: "RayTally · dev-prompt-v4" signal: query: "If You Build It, They Will Come" observed_at: "2026-07-19T01:33:02.331Z" sources: - url: "https://news.ycombinator.com/item?id=48959090" boundary: "Published at 2026-07-18T00:00:00.000Z. Observed at 2026-07-19T01:33:02.331Z." - url: "https://tally.so/help/file-uploads" boundary: "No publication timestamp is present in the source record." - url: "https://help.maze.co/articles/4777475916-maze-quick-start" boundary: "No publication timestamp is present in the source record." - url: "https://dovetail.com/solutions/research-repository/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-19-if-you-build-it-they-will-come/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Pre-Launch Demand Evidence Before launch, turn an idea into scenario-based questions and collect the real materials users rely on to see who would genuinely switch to a new product. ## Product concept Before launching, an independent developer rewrites an idea as a small set of questions about real situations and invites prospective users to submit the spreadsheets, screenshots, or manual workflows they use today. Instead of treating a stated willingness to use the product as validation, it records who will share real material and who will keep testing, then groups that evidence into a scenario-based demand wall. Within a week, the developer can see which problems already have users they can serve, rather than relying on an interest curve alone. ## Why now (backed by facts) At the July 19 observation, "If You Build It, They Will Come" ranked fifth on Hacker News with 265 points and 97 comments, concentrating discussion in that window around whether personal organizing and investment lead to participation. For independent developers preparing to launch, this shifts the question from "Will anyone come if I build it?" to a more testable moment: whether prospective users will first share the real materials they are using now. ## Direction (model inference, not independently verified) Target user: Independent developers planning to spend one week to one month building, but who currently have only likes, a waitlist, or scattered interviews. They use it before choosing a scenario, cutting features, or deciding whether to keep investing. Minimal entry point: Start with a shareable scenario questionnaire. Each question accepts a screenshot, file, or link to an existing tool; respondents explain the specific task the material represents and separately confirm whether they will join the next testing round. The backend only needs to group submissions by scenario, mark follow-up willingness, and generate an anonymized, shareable evidence wall. The strongest case against: Users may decline to upload material because of privacy, confidentiality obligations, or lack of trust in the organizer, not because the problem does not exist. Conversely, friends and core community members may be willing to help without intending to switch or pay. Unless the product can distinguish trust barriers and polite assistance from genuine replacement intent, the evidence wall merely presents selection bias more neatly. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Run a public "show how you do this today" call around one vertical scenario, turn representative anonymized submissions into evidence-wall updates, then return to the original community to invite similar users to contribute. Each call brings in participants while creating real, shareable content. ## Competitors & gaps (model inference) - Tally: Tally already collects images, documents, and other files through forms, but it is built for general information gathering. The opening here is a workflow that organizes material type, the scenario it represents, willingness to join follow-up testing, and the strength of the evidence for demand decisions. - Maze: Maze covers moderated and unmoderated research, participant recruitment, reporting, and sharing. The narrower entry point is validation before a prototype exists, using users' current work materials and their commitment to continue testing as signals. - Dovetail: Dovetail provides a research repository that keeps interviews, tests, and feedback traceable to source material. The opportunity is to serve independent developers without a formal research process, starting with a public call for the first submission rather than organizing research that has already been completed. ## How it makes money (model inference) Project-based subscription: the free plan includes one validation project and a limited number of submissions; paid plans add more active projects, private evidence walls, collaborators, and data export. ## Source context Theme: "If You Build It, They Will Come" discussion Trigger Hacker News post (original English): If You Build It, They Will Come Heat at capture: ~265 points, 97 comments (point-in-time values) Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers. ## Sources - If You Build It, They Will Come | Hacker News (https://news.ycombinator.com/item?id=48959090) - File upload forms (https://tally.so/help/file-uploads) - Maze quick start (https://help.maze.co/articles/4777475916-maze-quick-start) - Research Repository (https://dovetail.com/solutions/research-repository/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.