A web app only tells you whether your business idea works if you build it so it can tell you. Five functions make the difference: measuring what users do, a pay button before everything is finished, feedback inside the app, a waitlist with invitations in small groups, and an admin view with the right numbers. Together they add little build time, but without them you launch a product and, three months later, still don't know whether to carry on. This article explains each function, what it tells you and how to keep it simple.

The short version

  • Build measurement in from day one. Adding it later costs more, and you miss exactly the first, most instructive users.
  • Behaviour beats opinions. What people do and what they're willing to pay for counts for more than what they say.
  • Admit people in small groups, so after every change you can see whether it works better.
  • Decide up front when you'll stop, adjust or keep building. Otherwise you keep hoping for next month.

Haven't tested your idea with conversations or a waitlist yet? Start with How to launch a SaaS MVP as a non-technical founder. This article is about the step after that: building the first version so it gives you answers.

1. Measuring what users do

The key question in the first weeks isn't how many people sign up, but how many go on to actually use the core feature. For that you need a funnel: sign up, first login, first use of the core feature, coming back. At each step you see how many people drop off.

  • Track a handful of moments, not every click. Five to ten events are enough to see the funnel.
  • Choose a privacy-friendly analytics tool, ideally with storage in the EU, and don't track personal data you don't need.
  • Look at the biggest drop in the funnel. If half of your users leave before the core feature, the problem is in the onboarding, not in your idea.

Without these measurements, low usage leaves you guessing: do people not want your product, or do they simply not get through it? Those are two very different problems.

2. A pay button before everything is finished

People are quick to say they'd "definitely use" something. Whether they'll pay for it, you only find out once there's a pay button. You don't have to wait until the whole product is finished to test that.

  • Pre-sales or early access. Let users pay for access now, perhaps with a discount for the first group.
  • A button for a feature that doesn't exist yet. Unsure whether an extension is worth building? Add a button for it in the app and measure how often it's clicked. This is also called a "fake door".
  • Be honest. Anyone who clicks such a button immediately sees a clear message, such as "This feature is coming soon. Want early access?" That way you test demand without misleading anyone, and you collect interested users at the same time.

A click on a pay button is a stronger signal than ten enthusiastic replies. An actual payment is stronger still.

3. Feedback inside the app

A survey emailed a month after signup gets few responses, mostly from people who already like the product. Feedback works better when you ask one question at the moment that matters.

  • Right after the core feature: "Did this help you?" with yes or no and an optional text field.
  • When people drop out: anyone who cancels a subscription or abandons a process halfway gets one short question about why.
  • Always within reach: a permanent "Give feedback" button or a direct contact address, so users can raise things themselves.

Read every response yourself in the first weeks. The pattern in ten short answers often tells you more than a chart.

4. A waitlist and invitations in groups

It's tempting to let everyone in at once. But once you change the app afterwards, you no longer know which users experienced what. Inviting people in groups (cohorts) keeps that overview.

  • Admit one group per week, for example twenty or fifty people from your waitlist.
  • Change one thing between groups, such as the onboarding or the price, and compare the next group with the previous one.
  • Stay in personal contact with the first groups. A short call with a few early users gives you insights the numbers won't.

A side benefit: if something goes wrong, it affects a small group that knows it's getting in early, not all your users at once.

5. An admin view with the right numbers

All this measuring is of little use if you have to look things up in three different tools. A simple overview in your own admin panel makes sure you look at it every week. Three numbers are enough:

  1. Activation: the share of new users who use the core feature at least once.
  2. Retention: the share still active a week or a month later, per group from step 4.
  3. Conversion: the share who pay, or click the pay button from step 2.

Add a list of the latest feedback from step 3, and you have everything for your weekly decision on one screen.

Tip: discuss these five functions with your development partner during the intake. Built into the first version they add little work; added later, you miss exactly the data from your first users.

What are good signals, and when do you stop?

There's no single number that applies to every product, but there are clear patterns.

  • A good sign: users come back without being reminded, they ask when a feature is coming, or they pay without much haggling.
  • Adjust: people sign up but never reach the core feature, or they use it once and don't return. Fix the onboarding or the promise first, before building new features.
  • Stop or pivot: after a few groups and changes, activation and retention stay low and nobody clicks the pay button. Then the problem probably isn't big enough, or you're solving it for the wrong audience.

Product-market fit, explained simply

Product-market fit means your product solves a problem that a clear group of people finds important enough to keep using it and pay for it. You often notice it before you can measure it: demand pulls without you having to push hard.

A widely used way to test it is to ask your active users one question: "How disappointed would you be if you could no longer use this product?" The answers are very disappointed, somewhat disappointed or not disappointed. A well-known rule of thumb from growth marketer Sean Ellis is that you're on the right track when around 40 percent answer "very disappointed". Treat that as a guideline, not a hard line: the trend across several groups says more than a single measurement.

Agree with yourself up front what you expect to see, and after how many weeks or groups you'll take stock. Then you decide based on numbers, not on hope.

How we build it

We build web applications and SaaS MVPs in 4 to 8 weeks, with a fixed scope, price and deadline and a working version every week. An MVP starts at €3,000 to €5,000. Which of these functions belong in your first version is something we discuss in the intake, so from launch you can see whether your idea works. Also read What is an MVP? or see how our process works.