TL;DR: Building proves you can create a solution. Finding users proves the solution matters to someone. These are separate questions, and finishing the first never answers the second.
Reading time: about 12 minutes. For developers and first-time founders.
A developer can spend six months building a product without having to convince a single stranger to care about it.
The code either works or it doesn't. A bug can be investigated. A slow query can be measured. If a feature breaks, there's usually somewhere to start looking.
Then the product is ready, the landing page is live, and the founder starts reaching out to people.
Nothing happens.
A few people visit the website. Someone says the idea sounds interesting. A friend offers encouragement. Perhaps a handful of people create accounts, but nobody returns the following week.
Suddenly, the problem that seemed straightforward during development becomes difficult to explain. The product exists. The founder believes it solves a real problem. Yet the people who supposedly need it aren't showing up.
This is where a familiar piece of startup advice enters the conversation: getting your first ten users is harder than building the product.
There is a reason the advice resonates, especially with developers who are building their first businesses. But it also leaves an important question unanswered.
The distinction matters. If you misunderstand why people aren't using your product, you can spend months trying to solve the wrong problem.
Jump to a section
1. Building gives you feedback. Selling gives you silence.
Consider what happens when a developer encounters a difficult technical problem.
The solution might take hours, days, or even weeks. But there is usually a way to investigate it. You can inspect the logs, reproduce the failure, test a different approach, and gradually narrow down the possibilities.
Progress isn't guaranteed, but the work often produces information you can use.
Customer acquisition is different.
You send twenty carefully written messages and receive two replies. You publish a detailed explanation of your product and nobody clicks through. You demonstrate a feature to someone who says they would love to use it, then never hear from them again.
You have an outcome, but you don't necessarily know what caused it.
Perhaps the people you contacted don't have the problem. Perhaps they do, but your message arrived at the wrong time. Perhaps the product is useful but switching to it would take too much effort. Perhaps they simply don't trust an unfamiliar founder with something important to their work.
Those explanations require different responses. Silence alone cannot tell you which one is correct.
This is one reason acquisition can feel more frustrating than development. With code, you can often make the next experiment more specific because you understand the system you're investigating. With customers, you are still learning how the system works.
You are learning what people care about, what they already use, what they will pay to change, and what makes them trust a product they have never tried.
And you are learning all of this while trying to persuade them to give you their time.
That is a genuinely difficult problem. But it isn't necessarily a harder problem in every measurable sense. A technically ambitious product might require years of engineering, while a simple product could find its first customers in a few days.
The more useful distinction:
| Building tests... | Finding customers tests... | |
|---|---|---|
| The question | Can you create the solution? | Does the solution matter enough that someone will act on it? |
| Feedback you get | Logs, errors, measurable results | Often silence |
| Who controls the outcome | Mostly you | Mostly other people |
Those are separate questions, and finishing the first does not answer the second.
2. Stripe's early customers didn't arrive through a signup page
In his 2013 essay Do Things That Don't Scale, Paul Graham describes how Patrick and John Collison acquired early users for Stripe.1
When somebody agreed to try the payment integration, the brothers wouldn't simply send a link and wait. They would ask to borrow the person's laptop and help install it immediately.
Y Combinator came to call this the "Collison installation."
The approach seems almost excessive now. Why should a founder personally install a product when the whole point of software is to make the experience repeatable?
Because the founders were solving a problem that a signup page couldn't solve for them.
A person who agrees to try a product has made a relatively inexpensive commitment. They can change their mind without consequence. Actually installing it requires more effort and brings the product into contact with the person's real workflow.
By helping with the installation, the founders removed friction and discovered what happened when someone tried to use Stripe for real.
Context matters. Stripe was addressing a concrete problem for developers and businesses, and its early founders had access to a network of potential customers through the startup ecosystem. Their approach does not prove that every product can acquire customers by offering personal onboarding.
It does show something more practical: sometimes the obstacle between interest and usage is not a lack of awareness. It is the work required to get started.
What that looks like in practice:
- Developer tool: help someone integrate it
- Software for accountants: import a customer's existing data
- A service: deliver the first result personally before asking for a longer commitment
These approaches do not scale indefinitely. That is precisely why they can be valuable at the beginning.
Before automating an onboarding process, a founder needs to understand where people struggle with it. Before spending heavily on marketing, they need to know what happens after somebody responds.
The first ten customers can be valuable for the revenue they bring in. They can also reveal problems that a founder working alone would never have discovered.
3. Ten signups can still mean zero real users
There is another problem with the way founders talk about their first users: the word user can describe several very different situations.
- Someone visits the landing page.
- Someone else joins the waitlist.
- A third person creates an account, opens the dashboard, and leaves.
All three might appear in a growth report. None necessarily demonstrates that the product is delivering its promised value.
This distinction is more than a matter of terminology.
In his account of Superhuman's product-market-fit process, founder Rahul Vohra described a company that had spent years building its email product but still needed a clearer way to measure whether users genuinely valued it.2
Superhuman surveyed people who had used the product at least twice in the preceding two weeks. It asked how they would feel if they could no longer use it.
Only 22% said they would be very disappointed.
That result mattered because these weren't simply people who had heard about Superhuman. They had already experienced the product. Yet most did not consider it indispensable.
The team used the survey responses to identify the people who valued the product most, understand what those people appreciated, and make improvements intended to strengthen product-market fit. Vohra subsequently reported that the score rose from 22% to 58%.
- 22% "very disappointed" (before)
+ 58% "very disappointed" (after)
There are limits to what this example establishes. The survey is a useful diagnostic, not a universal scientific test that can independently prove product-market fit. The results came from Superhuman's particular audience and product, and a high score does not guarantee a sustainable business.What this example does and doesn't establish
Still, the underlying problem is important.
Getting somebody to sign up and getting somebody to care whether your product disappears are not the same achievement.
For a founder trying to find ten users, this means the milestone needs a definition.
Ten registered accounts might be an appropriate early milestone for testing whether people will respond to an offer. Ten people who repeatedly use a core feature tell you something different. Ten paying customers tell you something different again.
None of those numbers is automatically the right target. The right target depends on what the product is supposed to accomplish.
| Product type | A meaningful signal might be |
|---|---|
| Tool used every morning | Returning frequently |
| Quarterly accounting software | Completing the quarterly task (daily usage would be a strange expectation) |
| One-time service | Successful completion and willingness to recommend the provider |
A founder should measure the behaviour that demonstrates value, rather than assume every product needs the same pattern of engagement.
Read the Superhuman product-market-fit story
4. When the advice is right, and when it isn't
The claim that customer acquisition is harder than building is most convincing when a founder has a working product but no reliable way to reach people who need it.
Imagine a developer who builds a scheduling tool for freelance designers. The technical work is manageable. The product works. But the developer has no existing audience among designers, no relationships with design agencies, and no idea where these freelancers look for tools.
The product might be finished in a month. Finding a group of people willing to try it, learning what they actually need, and discovering whether any of them will pay could take much longer.
The developer isn't necessarily struggling because the product is bad. They are trying to solve a problem for a group of people they don't yet understand well enough.
Now consider a different founder: an accountant who builds a small tool to automate a tedious task that several existing clients already complain about. The founder knows the workflow, has access to the intended users, and can test the tool with people who experience the problem every week.
The technical challenge could be the hardest part of that business. Finding the first few users might be comparatively straightforward.
| Developer building for designers | Accountant building for own clients | |
|---|---|---|
| Existing audience | No | Yes |
| Knows the workflow | No | Yes |
| Likely hardest part | Finding users | Building the tool |
Neither example is unusual enough to support a universal rule. Together, they show why the headline depends on the founder, the market, and the product.
Existing distribution changes the equation, too. Someone with an established audience, a respected reputation in a niche, or a network of potential buyers isn't starting from the same position as someone nobody knows.
That advantage is real. It doesn't mean their product is better, or that their acquisition strategy is automatically repeatable. It means some of the work required to earn attention happened before the product was launched.
The same qualification applies to technically novel products. If a founder doesn't yet know whether a proposed system can work at an acceptable cost, speed, or level of reliability, engineering experiments may need to come first. Talking to potential customers cannot resolve every question about technical feasibility.
The mistake is treating either building or customer acquisition as the correct first step for every startup.
Sometimes the founder needs to write more code. Sometimes they need to speak to potential customers before writing another line. Often, they need to do both, using what they learn from one to inform the other.
5. A quiet launch can mean four different things
Suppose you launch your product and, after several weeks, you still haven't found ten meaningful users.
The tempting response is to do more marketing. Post in more communities. Send more messages. Try another launch platform.
That might help. But first, consider where the process is breaking.
flowchart LR
A[Launch] --> B{Right people<br/>seeing it?}
B -- No --> C[1. Reach problem]
B -- Yes --> D{Taking the<br/>next step?}
D -- No --> E[2. Offer problem]
D -- Yes --> F{Reaching the<br/>main benefit?}
F -- No --> G[3. Activation problem]
F -- Yes --> H{Returning<br/>or paying?}
H -- No --> I[4. Retention problem]
H -- Yes --> J[Keep going]1. The right people aren't seeing the product
Perhaps the product solves a genuine problem, but your potential customers don't spend time on the channels you're using. Or perhaps you're targeting such a broad audience that your message never feels relevant to anyone in particular.
In this case, changing the product may accomplish very little. You need to understand where the intended customers already look for solutions and how to reach them.
2. People see the product but don't take the next step
This could mean the value proposition is unclear. It could also mean the problem isn't urgent, the price is too high, the proposed solution feels risky, or the person reading your message doesn't have the authority to make a purchase.
It is worth asking what your offer requires someone to believe before they act. An unfamiliar product asking for access to sensitive business data has a much larger trust problem than a free tool that works entirely in the browser.
3. People try the product but never reach its main benefit
Perhaps setup takes too long. Maybe the first screen asks users to configure five things before they can accomplish anything useful. The product might even work exactly as intended, but the value isn't apparent to a new user.
This is where watching someone use the product can reveal more than another round of promotional posts.
4. People get value once but don't return or pay
This is the most uncomfortable possibility because the founder has evidence that the product can work for someone, yet the behaviour isn't continuing.
The problem might be retention, pricing, a low-frequency need, or a mismatch between the person using the product and the person expected to pay. It could also mean the product is useful but not important enough to replace an existing habit.
Not a complete diagnosis. These four categories aren't exhaustive, and the boundaries between them aren't always clean. A confusing product can look like a marketing problem. A weak offer can look like a distribution problem. Low retention can reflect a product that works perfectly but solves a problem people rarely encounter.
The point is not to label every failure immediately.
It is to stop treating every failure as the same failure.
6. What should you actually do to find the first ten?
The best starting point is smaller than a launch campaign.
Choose a specific group of people who already experience the problem your product is intended to solve. Be precise enough that you can identify actual individuals, rather than an enormous category of potential customers.
Then investigate what they do today.
If you're building invoice software for freelancers, find out how those freelancers currently create invoices, follow up on unpaid bills, and keep track of their income. Ask what happens when the process goes wrong. Look for examples of real frustration, time lost, money lost, or workarounds people have already built.
Steve Blank's writing on customer development makes a useful distinction here: founders begin with hypotheses about customers and their needs, then test those hypotheses through conversations and experiments.3 The goal is to discover what is true, not simply to collect encouraging responses.
That means asking about actual behaviour is usually more informative than asking whether somebody likes your idea.
A person may tell you they would happily use an invoicing tool. That costs them nothing. Finding out what they currently use, whether they have paid for alternatives, and whether they'll try your product with a real invoice gives you stronger evidence.Example: weak evidence vs. strong evidence
Once you understand the problem, offer a small, concrete next step.
Don't necessarily ask someone to adopt your entire product. Ask whether they'll try one feature, bring one real task into it, or spend twenty minutes showing you how they currently handle the problem.
If the product is ready, help them use it. If it isn't, a prototype or a manually delivered version of the service might be enough to test the underlying assumption, provided you don't misrepresent what you've built.
Track what happens next
| Stage | What to record |
|---|---|
| Reached | Did the intended person actually see the offer? |
| Responded | Did they reply or ask a meaningful question? |
| Tried | Did they attempt the real task? |
| Activated | Did they reach the product's core value? |
| Returned | Did they use it again when the need arose? |
| Committed | Did they pay, renew, recommend it, or make another meaningful commitment? |
Not every product needs all six stages, and not every commitment looks like a payment. The table is a way to make the process observable, not a universal funnel that every business must follow.
Keep notes on why people stop, preferably in their own words. A polite refusal and a detailed objection are not equivalent. Neither is the same as someone who tries the product, gets value from it, and simply doesn't need it again until next month.
Then choose the next experiment based on what you learned:
- [ ] The wrong people are seeing the offer: change the audience or channel
- [ ] The right people understand the offer but don't care enough to try it: investigate the problem and the value proposition
- [ ] They try the product but fail to reach its main benefit: work on that experience
- [ ] They get value but don't return or pay: investigate the frequency, importance, and economics of the problem
Two weeks can be enough to uncover useful patterns when the target customers are accessible and the product delivers value quickly. It may be nowhere near enough for a business with a long sales cycle or a problem that occurs only a few times a year.
The objective isn't to promise ten users within fourteen days. It is to finish the experiment knowing more than you did when you started.
7. The first ten are not the finish line
There is a reason founders remember their first users. Each one represents a decision that happened outside the codebase: somebody noticed the product, considered it relevant, decided to try it, and perhaps found enough value to return.
But the number ten can be misleading.
| Ten users who... | ...might tell you |
|---|---|
| signed up because a friend asked | Very little about whether strangers will pay |
| independently share the same painful problem and pay to solve it | A great deal |
| never return | A product problem that another hundred signups would only make harder to ignore |
The work isn't finished when the tenth person arrives. That's often when the next question becomes possible.
- Can you find another ten people with the same problem?
- Can you reach them through a process you understand?
- Do they experience enough value to keep using the product?
- Does acquiring and serving them make economic sense?
Those questions are harder to answer than whether a product can attract ten signups, and they matter more to the future of the business.
So, is getting your first ten users harder than building the product?
Sometimes. Especially when the founder understands the technology but knows very little about the people who might buy it. But the comparison becomes less useful when it turns into a universal rule, or when it encourages founders to treat engineering and customer discovery as competing activities.
A product can be technically excellent and commercially irrelevant. It can also be commercially promising before its engineering is finished. The difficult work is finding out which situation you're in while there is still time to change direction.
That begins with a more useful question than how to get ten users.
The Startup Café — Real Startup Lessons. Beyond the Hype.
-
Paul Graham, "Do Things That Don't Scale," 2013. The essay is where the Collison installation story comes from. ↩
-
Rahul Vohra's account on the First Round Review. The 22% and 58% figures come from Superhuman's own survey of its own users, so treat them as one company's data point. ↩
-
Steve Blank's customer development writing is a collection of posts, so start with the ones on customer discovery and hypothesis testing. ↩
Top comments (1)
Our first users never came from a launch. They came from answering people's questions where they already hung out, long before we mentioned what we'd built. Building and finding users are separate skills, but talking to people early makes the second one a lot less scary.