How to find your first ten users with no marketing budget

Start with one group you can reach personally and one real task you can help them complete this week. Recruit in small batches, observe the first use, and ask to check back when the task happens again. Ten accounts are easy to count. Ten people who have a reason to use the product give you something to build on.

This approach costs your time even when the advertising budget is zero. Paul Graham's early-stage advice includes recruiting users individually and helping them get started. The procedure below is an original worked example of applying that idea to a small SaaS. Its numbers are illustrative, not conversion benchmarks. Do Things that Don't Scale

Pick a group you can actually reach

Suppose you built a tool that collects client feedback on design proofs. Choose freelance packaging designers who currently consolidate comments from email and have another proof due within two weeks. That gives you a specific task, an existing workaround and an upcoming opportunity to try the product.

Write down where you have a legitimate way to speak with that group. Possibilities include introductions from designers you already know, a professional group that permits research requests, or people who have publicly asked for help with this exact workflow. Read community rules and ask a moderator when needed. A directory of strangers is not the same as an invitation to message them.

Choose the route where you can explain why this particular person might benefit. If you cannot identify anyone with an upcoming proof, investigate the audience before spending the week polishing a launch announcement.

Offer one specific next step

Here is a sample invitation for someone who has agreed to hear about relevant tools. Replace the details with facts you can support.

I'm building a tool for collecting comments on design proofs. You mentioned combining feedback from email. Would you be open to showing me how you handled your most recent proof? If it fits, I can help you try one upcoming round in the tool. The pilot is free, and I'd like your candid feedback afterward.

State any price and time commitment honestly. Keep the initial conversation short and let people decline. An unanswered message is no reason to keep chasing someone.

Before demonstrating, have the designer walk through a recent job, the workaround they used and the point where it became frustrating. Eric Migicovsky's user-interview guidance emphasizes concrete past experiences and attempted solutions. That helps you learn whether your proposed workflow fits. YC's interview questions and transcript

If the actual problem is getting clients to agree on a brief, a proof-comment tool may arrive too late. Record that mismatch. If the problem fits, ask permission to help with the next proof, using material the designer is allowed to share.

If the invitation still feels broad, narrow the pilot with Jay Raavi’s AI mentor ↗. Bring the reachable group, its next task and the time you can spend helping.

Define a user by the work completed

For this pilot, count a successful first use when a designer collects feedback on a real proof and produces an actionable revision list. Record whether you helped. A sample-file demo does not meet that definition. A second use requires a new proof on a later occasion.

For an API product, trace the first real result through a second job. That example makes the difference between a working demo and repeat use explicit; the proof-feedback pilot needs its own outcome events. If a first use requires two people, measure whether a request finds a willing partner in time. Ten signups in different places or time slots may never get a chance to help each other.

Keep a small log with a participant ID, recruitment route, upcoming task date, first result, assistance required, next task date and follow-up permission. You do not need to copy private client designs or comments into the log. Ask the designer to confirm an outcome you cannot observe directly.

Here is one hypothetical batch after all eight agreed pilots have had time for two proof rounds.

There are six successful first users here and four repeat users. Six of eight agreed pilots completed the task, or 75%. That is a description of eight people, not evidence of a dependable acquisition rate. Read the two incomplete cases before expanding recruitment.

Budget the founder work too. Thirty invitations at four minutes each, twelve conversations at twenty minutes and eight setup slots at fifteen minutes total 480 minutes, or eight hours. That excludes finding participants, fixes and follow-ups. If you have four hours available, shrink the batch or spread it across two weeks.

Choose the next batch from what you learned

If conversations reveal a different recurring problem, revise the audience or the product promise. If suitable designers agree but fail during setup, fix that step and revisit willing participants. When people complete a proof but decline the next one, ask what they used instead and why.

If the four repeat users get useful revision lists with manageable help, recruit a few more people with the same workflow. Ask satisfied participants whether they know one colleague who would welcome an introduction. Keep recording assistance so a founder-operated service does not get mistaken for independent product use.

Ten is a convenient first milestone. It does not establish willingness to pay or a repeatable growth channel. After a free pilot delivers value, test a bounded paid promise and record the delivery and support burden. Actual purchases, usable results and founder-assisted rescues answer different questions. For now, the next action is concrete. Find one reachable person with the task coming up, learn how they do it today, and agree on what a useful trial would accomplish.