Early Adopters vs Curious Visitors: How to Tell

The fastest way to find early adopters after a launch is to stop looking at who signed up and start looking at what they did next. An early adopter shows three behaviours a curious visitor almost never does: they come back on a different day without being asked, they put their own real data or work into your app instead of poking at the demo, and they complain about something specific. Score every signup on those three signals, zero or one each, and you will know by the end of one evening which five or six people deserve a personal message and which forty-odd were just passing through. Demographics, job titles and how excited someone sounded in a comment tell you far less than those three actions.

Most writing on early adopters is about finding them before you build: brainstorm segments, rank them, interview the top ones. That is useful work, but it assumes you are still at the whiteboard. If you already shipped, posted it somewhere, and now have a spreadsheet of fifty email addresses and no idea which ones matter, you need a different tool. This post is that tool.

Why does launch-day traffic mislead you?

Launch traffic is mostly curiosity, and curiosity looks exactly like interest on a dashboard. A signup from someone who clicked through from a launch board, opened two screens and left is counted the same as a signup from someone who has been fighting your exact problem for a year. Both are one row.

Three things make the first day especially noisy for an indie app:

• A lot of your visitors are other makers. Launch platforms, build-in-public threads and maker communities are full of people who browse new products the way other people browse a newsstand. They are friendly, they leave encouraging comments, and most of them do not have the problem you solved.
• Novelty inflates everything. People try new things because they are new. The same person who signs up on launch day would not have searched for your category on a normal Tuesday.
• Encouragement is cheap to give. "Love this!" costs a commenter two seconds. It is kind, and you should be grateful for it, but it is not evidence of need.

Steve Blank's description of the people worth building for is still the clearest one around. In his post on the minimum feature set and earlyvangelists, he lists the traits: they have a problem, they know they have it, they are actively looking for a fix, and the pain is bad enough that they have already cobbled together an interim solution. Notice that every one of those is about behaviour and circumstance. None of them is about age, industry or how enthusiastic they sounded. That is the lens to bring to your signup list.

What behaviour marks a real early adopter?

Here is the rubric. Open your signup list next to your app's admin view or whatever usage data you have, even if that is just "last seen" timestamps and a count of items created. Score each person on three signals.

Signal	Scores 1 when...	Scores 0 when...	Why it matters
Came back	They returned on a later day, unprompted, and did something	Everything they did happened in the first session	Returning means the app earned a place in their week, not just their curiosity
Brought their own stuff	They imported, uploaded, connected or typed in real data from their own life or work	They only touched the sample project, demo data or empty state	Real data is a cost. Nobody pays it for a tool they do not intend to use
Complained specifically	They reported a concrete friction ("the CSV import drops my date column") or described a workaround they use today	Silence, or generic feedback ("looks great", "needs dark mode")	Specific complaints come from people who tried to get a real job done and hit a wall

Add the scores up and sort the list.

Score	Who they probably are	What to do this week
3	An early adopter. Keep them close	Personal message within a day or two. Ask for a short call or a long reply. Fix their complaint first
2	A likely early adopter who hit a snag, or a real user who is quiet	One personal follow-up, focused on whichever signal is missing
1	Curious, maybe interested later	No individual outreach. They stay on your update list
0	A launch-day tourist	Thank the launch, not the person. Leave them alone

The rubric deliberately ignores how the person found you, what they said in public, and whether they seem like your "target customer". Those things are guesses. The three signals are facts you can read off your own data, and on a list of fifty you can score everyone in an evening.

A note on the "came back" signal: if your app is something people use once a month by nature (a tax helper, an invoice generator), stretch the window. The question is "did they return when the need came up again", not "did they log in daily".

Which signals are noise?

Several things feel like strong signals on launch day and are not. It helps to name them so you stop weighting them.

• Upvotes, likes and reposts. These measure how well your launch post landed, not whether anyone needs the product. Plenty of people upvote things they will never open.
• Enthusiastic comments without a question. "This is exactly what I needed!" followed by no second session is a polite visitor. Real users ask something, because they tried to do something.
• Waitlist or newsletter signups alone. An email address is a bookmark. It becomes a signal only when it is followed by use.
• Big feature requests on day one. "Can it also integrate with every CRM?" usually comes from someone imagining a product, not using yours. Compare that with "the export button is greyed out after I rename a file", which comes from someone who clicked it.
• Job title and company. A founder of an impressive company who never came back is a zero. A student who imported three hundred rows and emailed you about a bug is a three.
• Other makers praising your stack or design. Genuinely nice, and good for morale. Rarely evidence of need.

None of this means the noisy people are unimportant as humans or as future users. It means they should not drive what you build next week.

How do you contact the ones who matter?

Write to your threes and twos individually, by hand, and make the message about what they did, not about you.

A message that works has three parts: the specific thing you noticed, a direct thank you, and one small ask.

"Hi Sam, I saw you imported your client list twice and hit the date-column bug on the second try. That one is fixed now, sorry it bit you. Would you be up for a 15-minute call this week? I want to see how you actually use it, and I will fix whatever you show me."

Some practical rules:

• Reply where they already talked to you. If someone complained in a comment thread, answer there first, then move to email or DM for the follow-up.
• Lead with the fix when there is one. Nothing tells an early adopter they chose well like seeing their complaint shipped within days.
• Offer to help them get set up. Paul Graham's essay Do Things That Don't Scale describes how the Stripe founders, instead of saying "we'll send you a link", would install the product for a willing user on the spot. For an indie app, the equivalent is offering to import their data for them or walking them through the first real task on a call.
• Keep the list small enough to know by name. If you cannot remember each person's use case without looking it up, you have too many in the "contact" bucket, or you are not writing down what they tell you.

If your list does not have any threes yet, that is information too. The approach in how to get your first 10 users for a side project is the right move then: go find ten named people who have already described your problem in public, rather than waiting for the launch crowd to sort itself out.

What should you ask them first?

Ask about what they did before your app existed and what they do now, not about what they think of it. Opinions are cheap and generous. Past behaviour is the thing you can build on.

Rob Fitzpatrick's book The Mom Test is built on exactly this idea: people will tell you your idea is good to be nice, so you ask about their life and their specific past actions instead. Applied to an early adopter call, the first questions look like this:

1. "What were you using for this before you found my app?" The answer tells you your real competitor, which is often a spreadsheet.
2. "Walk me through the last time you did this task." Watch for the workaround. The workaround is the feature.
3. "What made you come back on Thursday?" You already know they returned. Find out what triggered it, because that trigger is your retention story.
4. "What almost made you give up?" This surfaces the friction people do not bother to report.
5. "Who else do you know who does this job?" Early adopters tend to know each other. One good intro can be worth more than a second launch.

Avoid "would you pay for this?" and "would you use it if it had X?" on the first call. Hypothetical answers about the future are the least reliable data you can collect. Write down everything they say, in their words, in the same place you keep your launch notes. A launch week retro is a good home for the patterns that show up across three or four calls.

What do you do with everyone else?

The ones and zeros are not a failure. They are the normal shape of launch traffic, and a few of them will turn into real users later when their need arrives. Treat them lightly and keep the door open.

• Send one useful update, not a drip campaign. When you ship something your threes asked for, tell the whole list in two or three sentences. That update is a second chance for a tourist who now has the problem.
• Do not chase them with "we miss you" emails. They did not leave, they were never really there. Pestering them costs you goodwill for nothing.
• Watch for promotions. Re-run the rubric a week or two after launch. Someone who scored a one on day three and imported real data on day twelve just became a two, and deserves the personal message.
• Keep a public place where they can find you again. Most people rediscover a tool weeks later when a colleague mentions the problem or they search for it. A launch post sinks off the front page within a day. A listing in a showcase directory stays put, which is why it is worth having one alongside your own site.

If you want that live surface, you can submit your app to TryMy for free. Listings are human-reviewed, the app has to be free to try (free, freemium or with a free trial), and each one gets its own page in the showcase that people can browse long after your launch day has scrolled away.

FAQ

How many early adopters do you need?

Fewer than you think. For an indie app, a handful of people who score a three and stay in touch with you is enough to steer the next month of work, because each of them will give you far more detail than a hundred casual users. The goal is not a number, it is a group small enough that you know every person's use case by name and large enough that you can tell a pattern from one person's quirk. When two or three of them independently complain about the same thing, you have your next priority.

Are launch-platform signups usually early adopters?

Mostly not, and that is fine. Launch boards and maker communities send a lot of curious visitors and fellow builders, and a smaller number of people who genuinely have the problem. The platform is good at getting you in front of people, but it cannot tell you which of them matter. Run the three-signal triage on those signups the same way you would on anyone else. Our guide to getting your first 100 people to try your app covers which channels tend to send users rather than spectators.

How do you keep early adopters engaged?

Ship their fixes and tell them personally when you do. Nothing else comes close. After that: reply to them fast, give them a direct line (email or a small private chat), ask before you change something they rely on, and occasionally show them work in progress. Early adopters stay because they feel like part of the build. If you want a structured way to run a small group like this, the beta tester checklist and the guide to finding beta testers with no audience both apply here.

Should you give early adopters something for free?

Giving something is a good idea when it is a thank you, not a bribe for feedback. Extended access to a paid tier, a locked-in price, or their name in the changelog all cost you little and signal that you noticed them. Avoid paying cash or gift cards for feedback, because it attracts people who want the reward rather than the product, and that corrupts the exact signal you are trying to read. The early adopters worth keeping would have stuck around without the gift. The gift just tells them you know it.