How to Get Your First 10 Customers: A Founder-Led Plan

The first ten customers are a learning project before they are a growth channel. You need people with a real problem, enough authority to try a solution, and patience for a product that is still becoming itself. YC’s advice is blunt: do work that does not scale and talk directly to customers before trying to automate acquisition. That does not mean one channel always wins. The SBA also lists networks, referrals, communities, events, partnerships, online presence, and targeted prospect lists as possible sources.

TL;DR

• First 10 Customers is a founder-led growth and customer conversations guide: use it to make one decision, not to collect generic advice.
• Start with the smallest useful version: a signal, a specific next action, and a respectful exit; add complexity only when the evidence requires it.
• Treat every claim as either an observation, an estimate, or a hypothesis; do not present a signal as proof.
• Before you publish or act, check the buyer's words, a dated owner, and evidence that can be checked.
• The practical outcome is a dated next step, a clear owner, and a reason to stop or revisit the decision.

A 90-day operating plan

Do not treat “ten conversations a week” or “customer three brings customer ten” as benchmarks. They are possible operating choices, not evidence-backed rules. Choose a weekly conversation target your calendar can sustain and report what happened.

Find the first conversations

Start with former colleagues, communities, relevant events, partners, customer interviews, and carefully researched companies that visibly encounter the problem. Write a list with name, role, why_now, source, and permission_or_relationship. Ask for a conversation before pitching:

I am researching how [role] handles [specific workflow]. I noticed [evidence]
and want to understand the last time this caused trouble. Could I ask three
questions? This is research, not a sales pitch.

During the conversation, ask about the last incident, current workaround, cost or risk, previous attempts, and what would make a fix worth paying for. Someone who has never tried to solve the problem may be curious but is not yet a qualified early customer.

Qualification and tracking template

prospect:
source:
buyer_and_role:
problem_in_their_words:
last_incident_and_date:
current_workaround:
impact_and_source:             # buyer estimate, report, or observation
urgency:
decision_maker:
budget_status:
pilot_success_metric:
next_step_owner_and_date:
pilot_status:                  # not offered, proposed, paid, active, complete
payment_status:
referral_potential_and_consent:

Advance a prospect when the problem is evidenced, the person can influence a decision, and there is a dated next step. Mark nurture when urgency is unclear; mark disqualified when the problem is absent or the buyer is outside your scope. This prevents polite conversations from becoming imaginary pipeline.

Make the pilot small and paid

A useful pilot has one team, one workflow, one outcome, a start and end date, and a written decision point. Price depends on the buyer and the value of the work; do not copy a universal dollar range from another startup. A modest payment can test willingness to allocate money, but it must still cover your delivery burden.

PILOT BRIEF
Scope: [one workflow for one team]
Duration: [dates]
Customer effort: [hours, access, owner]
Success metric: [baseline -> target, measurement method]
Price: [amount and payment terms]
Readout: [date and attendees]
If it misses: [what both sides learn and what happens next]

Illustrative example, not a benchmark: A workflow product might test 30 researched accounts, hold 10 conversations, offer 3 pilots, and convert 1-2. The numbers are planning assumptions. If the first pilot cannot provide access to the required data, stop and redesign the pilot instead of calling the customer a failure.

Deliver like the product is already mature

Founder-led onboarding is not a permanent advantage; it is a fast way to learn. Set expectations in writing, send a midpoint update, record decisions, and show the result in the customer’s own terms. Document what was manual, what broke, and what the buyer would not pay for. A case study is only useful if the customer consents to the quote, logo, and numbers.

From one customer to ten

After a successful readout, ask for a specific introduction, not “anyone you know.” Give the customer a forwardable note and make clear that sharing is optional. Ask about a referral at a value moment, not during an outage, dispute, or unresolved support issue. The customer referrals guide includes the consent and tracking details.

Lookalikes are hypotheses. If the first customer is a 50-person SaaS company with a support team, find other companies with the same problem evidence, not merely the same logo category. Keep the source and proof attached to each new account.

Decide whether a prospect is ready

Early enthusiasm is not the same as buying intent. Use a simple readiness test before offering a pilot:

Ask the prospect to describe the last occurrence, not their ideal future. If they cannot remember an incident, have not tried a workaround, and would not allocate time or money to a pilot, do not pressure them into becoming a design partner. Their lack of urgency is evidence about the segment.

What a failed pilot should change

Illustrative scenario, not a benchmark: A founder offers a two-week pilot to three operations teams. One team cannot provide the data needed to measure the outcome. One completes the setup but says the workflow is too infrequent to justify a purchase. One reaches the agreed result but needs an integration the product does not support. None of these is simply “the customer failed.” The first reveals an access requirement, the second challenges the problem frequency, and the third defines a product boundary. The founder should narrow the next pilot brief and say what changed.

Do not publish a success story that hides a failed implementation, manual work, or a customer limitation. Ask whether the customer approves the wording, numbers, name, logo, and use of their quote separately. If approval is not given, use an anonymized internal note rather than a public case study.

Moving from pilot to repeatable sale

After each pilot, record five things: the trigger that started the conversation, the buyer who paid or sponsored it, the work you performed manually, the evidence the customer accepted, and the objection that remained. Compare customers by problem shape, not only industry. Two companies may share a vertical but have different urgency, ownership, or compliance constraints.

Create a one-page customer proof file with:

• The original problem in the customer’s words.
• The baseline and measurement method.
• What the product did and what the founder did manually.
• The limitation or unresolved risk.
• Permission status for quote, logo, numbers, and named reference.
• The closest next customer profile.

This file makes referrals and lookalike research more honest. It also tells a future salesperson what not to promise.

Founder-led acquisition checklist

1. Choose one buyer and one painful workflow.
2. Build a list from relationships, communities, referrals, and researched public signals.
3. Ask for a research conversation before presenting the product.
4. Record the last incident, workaround, urgency, authority, and budget path.
5. Offer one small paid pilot with written success criteria.
6. Confirm access, owner, dates, price, and decision point before starting.
7. Send progress updates and record manual work.
8. Run a readout against the agreed metric, including what missed.
9. Ask for a specific optional introduction only after value is clear.
10. Update the ICP before expanding the list.

Customer consent applies to outreach as well as proof. A customer may introduce a peer without authorizing you to mention the customer’s name or results. Keep those permissions separate.

Pricing and scope decisions

Early customers often ask for custom work because the product is still forming. Decide which requests teach you about the core problem and which requests create a one-off service obligation. Put the boundary in the pilot brief. If the customer needs an integration, data export, or security review, say whether it is included, separately priced, or outside the pilot.

Do not promise roadmap items as though they are shipped. State what the product does now, what the founder will do manually, and what is only being considered. A first customer who buys an honest scope is more useful than a customer who agrees to an attractive but impossible promise.

A simple customer learning review

At the end of each week, review the conversations and pilots together. Look for repeated words, not just repeated feature requests. Ask whether the same buyer owns the problem, whether the trigger is similar, whether the workaround is costly enough, and whether the customer accepted the same proof. If not, narrow the segment before adding more prospects.

Keep a “do not claim” list. It might include an unverified time saving, a result from one unusual customer, a feature still in testing, or a logo that has not been approved. The list protects future outreach and prevents a founder’s memory from turning a pilot detail into a public promise.

Customer-one-to-ten checklist

1. Select a problem with a recent, observable incident.
2. Confirm the buyer, user, approver, and data owner.
3. Ask for a paid pilot with a written outcome.
4. Set access, customer effort, dates, price, and decision point.
5. Report progress and surface limitations early.
6. Run a readout against the agreed measurement method.
7. Request permission for each quote, metric, logo, and referral.
8. Turn successful work into a proof file, not an inflated case study.
9. Search for lookalikes by problem evidence and trigger.
10. Stop, narrow, or change the offer when pilots repeatedly fail for the same reason.

The first 10 customers operating standard

This guide is written for a reader who needs to use first 10 customers in a real workflow, not merely understand the definition. The dependable version starts with the decision that must be made, names the evidence available today, and keeps the next step small enough to complete. That is the editorial standard used throughout this guide and across the Parlel library: practical guidance should help a founder, operator, candidate, or freelancer act without hiding uncertainty behind confident language.

Decide what success means before you start

Write the result in one sentence: “After this exercise, I will know whether , and the next action will be .” For first 10 customers, that sentence prevents the most common failure mode — doing more research after the useful question has already been answered. If the work concerns a person, company, role, client, or vendor, record the source and date as you go. If it concerns a template or message, define the recipient, context, and desired response before polishing the wording.

Use a small fixture rather than an abstract example. Pick three to five real records, situations, or drafts and run the method end to end. Keep one case that should succeed, one ambiguous case, and one case that should be rejected. That mix exposes whether the process can distinguish a useful signal from a convenient story. It also gives you material for a later review without pretending that a tiny sample is a benchmark.

Make the work explainable to another person

A high-quality result should survive a handoff. Another person should be able to see what was known at the time, which assumptions were made, what action was taken, and what would change the decision. For this topic, preserve the original input alongside the conclusion. Keep a short “why now” note, the owner, the due date, and the stop condition. This makes first 10 customers useful in an agency-style operating system: the work is repeatable without becoming mechanical, and a reviewer can improve it without rewriting the whole process.

Quality-control pass before you ship

1. Intent: Does the page answer the query implied by its title in the first screen?
2. Evidence: Are current facts linked to a source, date, or clearly labeled assumption?
3. Specificity: Could a reader use the checklist, script, table, or example immediately?
4. Boundaries: Does the guide say when the method is a poor fit or should stop?
5. Next action: Is there one useful action rather than a pile of competing calls to action?

Those checks matter more than adding another paragraph of general advice. They also protect search quality: the page earns attention by resolving the reader's problem, not by repeating first 10 customers unnaturally. If the evidence is thin, say so and explain how to improve it. If the answer changes by country, role, plan, or company size, make that branch visible instead of burying it in a footnote.

Run it on Parlel

Use Parlel to refill a reviewed target list and keep the customer record honest.

FIRST-10 DIGEST (weekly)
- new_matches: { company, source_url, fit, signal_date, confidence }
- stakeholder_moves: { person, old_company, new_company, consent_context }
- customer_proof: { metric, source, approved_for_sharing: true|false }
- next_action: { conversation|pilot|readout|referral|nurture }

Verify signals in the company directory and people in the people directory. The digest proposes research; the founder decides whom to contact and what to claim.

Keep reading

Continue the workflow with three closely related guides: - sales prospecting - how to ask customers for referrals - how to get a job at a startup

Sources and further reading

• YC: essential startup advice
• SBA: ways to find first customers
• Unitelvoice: first customer conversations
• Stripe Atlas