The short answer
After your app launches, collect user feedback through a combination of in-app prompts, short email surveys, direct interviews, and passive behaviour tracking. Use in-app prompts for quick sentiment signals, interviews for depth, and analytics to see what users actually do versus what they say they do. Treat all three as a system, not a menu of options.
Getting your app live is one milestone. Knowing whether it solves a real problem for real people is another. Most founders discover, about two weeks after launch, that they have plenty of opinions in their inbox and no structured way to make sense of them.
This article covers the specific methods that work for early-stage apps, when your user base is small, your development budget is finite, and every decision about what to build next has to be grounded in something more reliable than a hunch.
For a broader picture of everything that needs to happen in the days immediately after delivery, see What to Do the Week Your App Goes Live.
Why timing matters more than the tool you choose
Feedback collected at the wrong moment is mostly noise. Ask users what they think five seconds after they sign up and they have no experience to draw on. Wait three months and you are talking to your survivors, not a representative sample.
The most useful window is somewhere between the user's second and fifth meaningful action inside the app. At that point they have formed an impression but have not yet rationalised it.
For most apps, that window opens within the first three to seven days of a new user's activity. Build your feedback triggers around that window rather than around calendar dates.
Method 1: In-app microsurveys
A microsurvey is one to three questions shown at a specific point in the user's journey. The goal is a fast, honest signal, not comprehensive data.
The most reliable single question for an early-stage product is a variation of: "How disappointed would you be if you could no longer use this app?" with three options: very disappointed, somewhat disappointed, not disappointed. This is often called the Product-Market Fit survey, and a result where more than 40 percent say "very disappointed" is a reasonable signal that you have something worth developing further.
Keep microsurveys to one question per session. Showing multiple questions kills completion rates. Use a tool like Typeform, Tally, or a native modal built by your developer. Trigger the prompt after a user completes a core action, not when they first open the app.
Method 2: Direct user interviews
No survey tells you why. Interviews do.
Aim for five to eight conversations in your first month. That number sounds small, but after five interviews you will start hearing the same themes repeated. Recruiting is simpler than founders expect: send a plain-text email to your most active users asking for 20 minutes. Offer nothing in return. Users who agree are already invested in the product and will give honest answers.
Structure each interview around three questions:
- What were you trying to do the first time you opened the app?
- Walk me through what happened.
- What would have made that easier?
Avoid asking what features users want. People are poor predictors of what they need. Instead, ask about the last time they tried to do the thing your app is supposed to do, and listen for where the friction was.
Record the call with permission. Take notes immediately afterward. Look for phrases that repeat across multiple interviews. Those phrases are your product roadmap.
Method 3: Behaviour analytics
What users say and what they do are often different things. Behaviour analytics close that gap.
At minimum, instrument your app to track:
- Which screens users visit and in what order
- Where they drop off (the last action before closing the app)
- Which features are used more than once versus tried once and abandoned
- Time between sign-up and first meaningful action
Tools like Mixpanel, PostHog, and Amplitude offer free tiers that cover most early-stage needs. Your developer can add event tracking during build or as a quick addition post-launch.
Drop-off points are the most valuable signal. If 60 percent of users never get past a particular screen, that screen has a problem. No survey will tell you that with the same clarity.
Method 4: Passive feedback channels
Some users will not respond to surveys or agree to calls but will write a message if there is somewhere obvious to send it.
Add a feedback link or button inside the app that opens a simple form or your support email. Put it somewhere visible, not buried in a settings menu. A floating button or a link in the navigation bar works well.
For apps with a small user base, a shared Slack or WhatsApp group can serve the same purpose and has the added benefit of letting users see each other's questions. This creates a lightweight community before you have the scale to build a formal one.
Monitor app store reviews if your app is listed. Respond to every review in the first three months, including negative ones. Responses show future users that the product is actively maintained and occasionally convert critics into advocates.
Comparing the four methods
| Method | Best for | Time to insight | Volume needed | Cost |
|---|---|---|---|---|
| In-app microsurveys | Sentiment signals, PMF check | 1-2 weeks | 20+ responses | Low |
| User interviews | Understanding root causes | Immediate | 5-8 sessions | Time only |
| Behaviour analytics | Identifying drop-off and usage patterns | 2-4 weeks | 50+ sessions | Low to medium |
| Passive channels | Capturing unsolicited issues | Ongoing | Any | Minimal |
Run all four simultaneously from day one rather than sequencing them. They answer different questions.
Turning feedback into decisions
Raw feedback is not a roadmap. You need a simple system for processing it.
Create a shared document (a spreadsheet is enough) with four columns: the feedback, the source, the frequency (how many users raised the same point), and a tentative priority. Update it after every interview, every week of survey responses, and every time you review analytics.
Prioritise fixes and features by the intersection of frequency and severity. A bug that blocks five percent of users from completing onboarding ranks above a nice-to-have feature request from a single power user.
Before commissioning new development based on feedback, revisit the cost structure of your engagement with your developer. If you are on a time-and-materials arrangement, scope creep can make feedback-driven iterations expensive. The article Fixed Price vs Hourly: Which Is Safer for Founders? covers how to structure that relationship before costs run ahead of you.
A note on onboarding and feedback
Feedback quality depends heavily on whether users got far enough into the product to form an opinion. If your onboarding is thin, many users will drop before they have anything useful to say.
If your survey completion rates are below 10 percent or your interview recruits are not engaging, the problem is usually onboarding rather than the feedback method. How to Onboard Your First App Users covers how to fix the path that gets users to the point where their feedback becomes meaningful.
FAQ
How many users do I need before feedback is useful?
Five to ten users is enough to start qualitative work like interviews. For survey data to show meaningful patterns, aim for at least 30 to 50 responses. Analytics require around 50 active sessions to surface reliable trends. Do not wait for large numbers before starting.
Should I offer incentives for feedback?
For interviews, no. Users who agree without incentives give more candid answers. For surveys, a small incentive (a discount, early access to a feature) can lift completion rates without meaningfully biasing responses, as long as the questions are closed-ended enough that there is no obvious "right" answer.
What do I do with contradictory feedback?
Contradictory feedback usually means you have different user segments with different needs. When two users say opposite things, look at their usage patterns. If one is a power user and the other signed up once, weight them differently. If both are active, you may have a segmentation decision to make.
How often should I run surveys after the initial launch?
Once a month for the first six months. After that, quarterly unless something significant changes (a new feature, a pricing change, a spike in churn). Constant surveys cause survey fatigue and reduce response quality over time.
What is the single most common feedback mistake founders make?
Asking leading questions. "Did you find the dashboard easy to use?" primes users to say yes. "Walk me through what you did in the dashboard" does not. Rephrase every survey question and interview prompt to remove the implied answer before you send it.