Launch and learn

How to Launch an MVP and Get First Users

An MVP launch isn’t a big announcement. It is getting the product into the hands of a small group of the right customers, watching them use it, and learning fast enough to improve it every week.

ShoutEx Team · Data checked October 3, 2026
Launch small, learn fast.MVP Development for founders · Data checked October 3, 2026
5 to 20
Design partners or beta customers to start with, as a rule of thumb
2013
Year Paul Graham’s essay ‘Do Things that Don’t Scale’ was published
12
Testers new personal Google Play accounts need for a closed test

How do you launch an MVP?

Launch an MVP to a small group first: five to twenty design partners or beta customers who have the problem and agreed to give feedback. Onboard each one personally, watch how they use the core flow, fix what blocks them, and widen access only when the first group is getting the result without your help.

How do you find the first users?

Find first users through people who already have the problem: prospects from your discovery interviews, your network, communities where your customers gather, and warm introductions. Paul Graham’s advice is that founders must go out and recruit users rather than wait for them (Do Things that Don’t Scale).

  • People you interviewed during discovery.
  • Warm introductions from advisors and investors.
  • Communities and groups where your customers gather.
  • Prospects who joined a waitlist or paid a deposit.
  • Former colleagues in your target role.

How should a private beta run?

Run a private beta with clear expectations on both sides: what the product does now, what you need from them, and how long the beta lasts. The structure below keeps it focused on learning rather than support.

WeekFocusWhat you do
1OnboardingSet up each user personally; watch the first use
2 to 3Core flowFix blockers; short check-in calls
4 to 6HabitTrack whether users come back without reminders
6 to 8DecisionAsk about paying; decide what to build next

What about launching mobile apps?

Mobile launches have extra steps. New personal Google Play developer accounts must run a closed test with at least 12 testers for 14 consecutive days before going to production (Google’s testing requirements). Apple reviews apps before release. Use the store testing programs to run your beta, and plan these steps into the MVP timeline.

Founder rule

Onboard the first users by hand.

Personal onboarding feels slow, but it is how you see what the product really needs.

How do you collect useful feedback?

Collect feedback by watching behaviour first and asking second. Track whether users complete the core flow and come back, then ask about specific moments: where they got stuck, what they did instead, what they would pay. Prepare this during the build, and use it to decide your next step in after the MVP. For getting from beta users to paying customers, see how to get your first 10 customers.

Frequently asked questions

How do I launch an MVP?

Release it to a small group of design partners or beta customers, onboard them personally, fix blockers, and widen access gradually.

How many users should an MVP start with?

As a rule of thumb, five to twenty design partners or beta customers who have the problem and will give feedback.

Where do I find my first users?

Discovery interviews, warm introductions, communities where your customers gather, waitlists and former colleagues.

What is a design partner?

An early customer who uses the product, gives regular feedback and helps shape it, often in exchange for early access or a discount.

Should I charge beta users?

Asking for payment, even a small amount, is the clearest test of value. Discuss it before the beta ends.

How do I launch a mobile MVP?

Use the store testing programs for the beta. New personal Google Play accounts need 12 testers for 14 days before production.

Should I do a public launch?

Only once the core flow works for your first group without your help. Before that, keep it private.

Sources & further reading

Figures and rules change. These sources let you verify the current information directly. Hours, rates and timelines on this page are planning assumptions, not quotes.