# How to collect feedback before you launch > Before launch, collect feedback with a hosted feedback page that you share with invited testers, and add the widget to your landing page once it is on a live domain. Ask testers specific questions about what they tried, and keep the early items tidy with statuses and notes. Source: https://escutaproduto.com/resources/collect-feedback-before-launch Last updated: 2026-10-09 ## Start before there is a product to install into Most teams wait until the product is ready before they ask anyone for feedback. That is the wrong order. The earliest opinions are the cheapest to act on, because the product is still flexible and people are willing to say what confuses them. A landing page, a prototype link or a small group of invited testers gives you that signal long before you install a script in an app. Escuta Produto works at this stage in two ways. The [hosted feedback page](/docs/hosted-page) needs no code and no app, so you can share it right away. The widget can sit on a landing page once that page lives on a domain you control. Both send the same kind of structured item, with the page URL and browser saved automatically. ## Use the hosted page for testers you invite The hosted page lives at `https://escutaproduto.com/f/your-product-slug`. Share it with each tester in the message that invites them. Add `?lang=pt` or `?lang=en` to match the language of the invitation, and add `?email=` with their address to prefill the form. The prefilled email saves them a step, and it tells you who is writing without asking twice. Prefilling the email is personal data, so only add it for testers who agreed to take part in the test. Escuta Produto does not send emails, so the invitation and any follow-up come from your own mailbox. Keep the sender name and reply address consistent so testers know who will read their message. The hosted page is not indexed by search engines, which suits an invitation link. Anyone who has the link can still submit, so do not treat it as private. Share it only with the group you want to hear from. ## Put the widget on the landing page A landing page is public, so the widget belongs there once the domain is live. Add the script to the page template and set the allowed origins to the landing domain and any staging domain you use. The widget will not submit from a site that is not on the list, so check this before you rely on it. ```html ``` Use the `data-trigger` option to hide the floating button if the landing page already has a clear call to action. An explicit button with a preselected type works well for a waitlist page: ```html ``` Visitors who are not yet testers can still tell you what would make the product useful to them. Those messages show you the words people use, which helps with the page copy and the feature list. ## Ask testers for specific feedback Early feedback is only useful when it is specific. A tester who writes "it's nice" has given you a feeling, not a finding. Ask questions that make people describe what they did: - What were you trying to do when you opened the product? - Which step took longest, or made you stop? - What did you expect to happen, and what happened instead? - Which part would you miss if it disappeared tomorrow? Yes or no questions tell you what people think of an idea. Open questions tell you what they do. Put the questions in your invitation email and at the top of the hosted page, so testers see them before they type. Use the four types to sort what comes back. A bug is something that broke. An idea is a request. Praise tells you what to protect when you build the next version. Use other for anything else, such as a question about pricing or access. ## Use prototypes and staging links carefully A prototype link is a good way to hear about the design before the code is done. Add the staging domain to the allowed origins, so the widget works there, and share the prototype with a small group. Tell testers which version they are looking at, because a message about an early build is only useful if you know the build. Remember that a staging environment is often reachable by anyone who finds the link. Keep the widget off pages that show private data, and do not let a test environment hold anything you would not want a stranger to read. ## Keep early feedback tidy Early feedback piles up quickly, and it is easy to lose the thread when twenty people write in the same week. Use the five statuses to show what happened to each item: new while you read it, planned when you decide to act, in progress while someone works on it, done when it ships and closed when you decide not to act. Use the private internal notes for context you will need later. A note such as "beta group 1, works on a phone" or "duplicate of the onboarding request" saves time when you read the item again. Escuta Produto has no tags, so use the notes for grouping, and use the text search to find related messages. Close the loop with the testers who took the time to write. A short reply from your own email, saying what changed because of their message, is the best thank you you can send. The [article on thanking customers for feedback](/resources/thank-customers-for-feedback) covers that message in more detail. ## Move to the in-app widget at launch When the product is live, keep the hosted page for invitations and help links, and add the widget inside the app for ongoing feedback. Add the production domains to the allowed origins, and check that the page URL on each item points to the right place. Keep the pre-launch items in the same inbox. You can read the early messages next to the launch messages, which shows you whether the problems that testers described are still present once real customers arrive. ## Set up Escuta Produto before launch Create a product for the launch, copy its public key and add the landing domain and staging domain to the allowed origins. Share the hosted page with your first testers and send one test item from each route, then check that the page URL, the browser and any prefilled email appear on the item. Connect a Slack or Discord webhook so new messages reach the founder or the team that reads them. The [notifications guide](/docs/notifications) covers the setup, and the [widget reference](/docs/widget) lists the placement options. For the testing stage itself, [collecting feedback in a beta program](/resources/beta-program-feedback) covers the weekly rhythm, and [collecting feedback in a SaaS product](/resources/collect-feedback-saas) explains how to identify logged-in users once the app is live. ## Frequently asked questions ### Can I collect feedback before the product exists? Yes. The hosted feedback page works with no app and no code, so you can share it with testers, in a prototype or on a landing page. Create the product first, then send the link. ### How do I add the widget to a landing page before launch? Add the script to the landing page on a domain you control, and put that domain in the allowed origins. The widget submits only from sites on that list, so add the staging and production domains before you test. ### What should I ask early testers? Ask what they tried to do, what got in their way and what they expected to happen. Specific questions produce useful answers, while yes or no questions only tell you what people think of the idea.