First-customer operating loop

Get the first 10 SaaS customers by narrowing the learning loop.

Do not begin with every channel. Define one qualified customer, find a small group with the problem now, make one useful offer, and let replies, use, return, and payment decide the next move.

Start with a project See the workflow

Qualification boundary

Define who counts before counting to ten.

A first customer is not any person willing to sign up. Use one qualification rule so ten customers produce comparable evidence.

Use this workflow when

The person experiences the target problem now and can describe the current workaround.
They can access the workflow, data, or authority required to try the product.
The use case matches the product decision you need to make next.
You can observe first value, follow up, and learn whether they return.

Do not count this as proof

A broad waitlist member who joined for curiosity but cannot use the core workflow.
A friendly supporter whose praise is not tied to a current problem.
A user from a different segment whose requests would pull the product away from the hypothesis.
A contact reached through a channel you cannot honestly or safely operate today.

Smallest complete workflow

Run one 30 → 10 → 3 customer cycle.

The numbers are a planning constraint, not a guaranteed funnel. Their purpose is to keep the batch small enough to learn from every response.

01
Write the customer and trigger
Name the role, situation, urgent event, current workaround, and observable cost. Two researchers should be able to find similar people from the definition.
02
Build a list of 30 qualified people
Use approved research to find people with visible evidence of the problem. Record why each person fits; do not treat an unfiltered contact list as an ICP.
03
Prepare ten individual conversations
Lead with specific context and a useful question. Explain what exists, what is rough, and why this person may be relevant. Make declining easy.
04
Approve the exact outreach
Review the recipient, copy, channel, account, batch size, and stop condition. A plan is not permission to publish or send an unknown payload later.
05
Deliver one narrow result
Help qualified respondents complete the product's core job. Manual assistance is acceptable when it teaches you what the repeatable product must do.
06
Make a three-way decision
Continue when qualified people reach value and return; revise when interest exists but the workflow fails; stop or change segment when the problem or urgency is absent.

Inspectable control

Example approval card — first conversation batch

This is an illustrative task card, not a claimed customer result or completed experiment.

Objective: Test whether founder-led SaaS teams with a live beta need a repeatable way to recruit and learn from qualified early users.
Action: Prepare five individual X/Twitter replies or direct conversation openings for review; publish only the items separately approved.
Target: Five founders with a live product and a recent public statement about difficulty finding early users.
Acceptance: Every draft references observable context, asks one useful question, and makes no claim of guaranteed customers or automated Reddit/email execution.
Stop condition: Stop after five reviewed drafts, any account/auth mismatch, or evidence that the target does not fit the ICP.

ReviseRejectApprove exact scope

Reusable worksheet

Copy the 30 → 10 → 3 customer worksheet.

Use one row per prospect and keep qualification, outreach, product use, return, and payment separate. A spreadsheet or plain document is enough.

ICP and trigger: Role, situation, urgent event, current workaround, and observable cost.
Starting artifact: The URL, demo, repo, landing page, or workflow the person can inspect or try.
30-person qualification: Name, public source, evidence of fit, disqualifier checked, and why the problem appears current.
10-conversation batch: Exact context, opening question, channel, account, batch number, and approved final copy.
Approval boundary: Recipient, payload, cost, quantity, owner, success check, and stop condition.
First value: The narrow job attempted, assistance provided, completion evidence, and failure point.
Signal ledger: Relevant reply, qualified conversation, first value, return, payment, clear no, and the evidence URL or note.
Decision: Continue, revise, or stop; record what changes in the audience, promise, product, or next batch.

Decision scorecard

Score the signals that change a company decision.

Do not collapse attention, qualification, product use, and revenue into one conversion number.

Relevant reply

Confirms the problem, timing, or current workaround.

Qualified conversation

The person fits the ICP and can try the target workflow.

First value

They complete the narrow job the product promises.

Return

They come back or repeat the workflow without persuasion.

Payment

They exchange money for continued value.

Clear no

A specific objection helps change the audience, promise, or product.

Current product boundary

Plan with what actually runs today.

This workflow does not promise ten customers from 30 prospects. The batch sizes create a bounded learning cycle. Results depend on the problem, qualification, offer, trust, product, and founder follow-through.

Research

Live

Soloop can run approved market, competitor, and prospect research and return evidence to the project.

X / Twitter

Live with OAuth

Approved drafts, publishing, and reply collection can run through the connected account.

Cold email

Beta · Gmail required

Email work requires a connected Gmail account and the approval path shown on the task.

Manual publication

Soloop can prepare reviewable copy, but the founder keeps the public posting step.

Plan-only

Soloop can discuss and plan the channel; it does not buy or manage ads today.

Coding

Live after approval

Sandboxed coding can change and test the product within the approved task scope.

Continue the loop

Find design partnersQualify a recurring learning relationship before asking for a purchase.Choose a provisional ICPCompare segments and exclusions before finding people.How to find beta usersUse the qualification screen and 20-conversation recruiting sprint.Validate a SaaS ideaChoose the riskiest assumption before increasing outreach volume.Current Soloop capabilitiesReview the exact approval and channel boundaries.

FAQ

Questions before the next move.

Should the first 10 SaaS customers come from one niche?

Usually, yes. A narrow initial segment makes responses comparable and helps you identify whether the same problem, trigger, and value event repeat. Expand after the pattern is clear.

Do free beta users count as customers?

Track them as qualified users until money moves. Their use and return behavior are valuable evidence, but keeping payment separate prevents a large free cohort from being mistaken for a working business model.

Which acquisition channel should I start with?

Start where qualified people already reveal the problem and where you can operate honestly. Soloop currently supports approved research and live X/Twitter; cold email is beta with Gmail, Reddit publication is manual, and ads are plan-only.

Bring the product you already have

Choose one move. Review it. Learn from the result.

Start with a URL, repo, landing page, demo, deck, file, or rough product.

Start with a project