The First 100 Customers Course #3: How Seekster Won Its First 10 Customers Before It Had a Product
A step-by-step course for finding explicit demand, fulfilling the first jobs manually, building the supply side, and testing retention before automating a marketplace.
TL;DR
Seekster's first ten customers did not come from a launch, a waiting list, or paid acquisition. Founder Sahib Anandsongvit watched Facebook groups for people already asking for help, promised a concrete result, and fulfilled each request manually.
For the first job, a woman needed a makeup artist for Halloween. He promised a call within an hour, then searched his future wife's contacts for five providers. For the second, he promised a housekeeper within two hours, drove his own housekeeper to the buyer, and waited outside while the job was completed. There was no finished product and no logo.
The repeatable mechanism was visible request → manual promise → provider match → observed fulfilment → supply ledger → automation. It reached a real first-ten milestone. It did not solve the entire marketplace. Seekster later fought off-platform leakage, moved toward B2B, and permanently stopped operating in March 2026. Copy the validation loop, not a heroic ending.
What you will build
This course gives you a seven-day first-customer sprint. You will define one request-shaped job, work one concentrated demand source, write a bounded manual promise, operate the delivery yourself, score every dependency, and make a continue-or-stop decision from payment, repeat use, founder time, and failure evidence.
The output is not an app. It is a verified chain of behavior: a buyer asked for the job, accepted the promise, supplied the required input, received the result, paid or made an equivalent commitment, and wanted the workflow again. Software comes after the chain repeats.
Who this is for
Use the method when a buyer's need is visible and a safe human fallback can produce the result. It fits workflow SaaS, operational marketplaces, data services, AI agents, and technical products whose first version can be delivered through a controlled service.
Do not use it when manual failure creates safety, legal, financial, medical, or irreversible risk. Do not pretend a capability exists. Manual first means the promised result is real while the internal process is unscalable. It does not mean selling vaporware.
Case snapshot
| Stage | What happened | Evidence |
|---|---|---|
| 2015 | Seekster launched in Thailand | Founder interview and independent profiles |
| First customer | Halloween makeup request found in a Facebook group | Founder-reported |
| Second customer | Housekeeper delivered within two hours | Founder-reported |
| First 5–10 | Requests matched manually before product or logo | Founder-reported |
| Six months | Supply operations became the central product constraint | Founder-reported |
| 2017 | 5,000–6,000 monthly jobs and 1,800 providers | Nation Thailand |
| Later | B2B became the larger market; company reported break-even | Founder and company-reported |
| March 2026 | Platform permanently stopped taking orders | Company announcement reported independently |
The model: sell the completed job before the software
Early buyers do not reward architecture. They reward a completed job. Seekster's manual work tested four assumptions in sequence: a buyer expresses the problem where the founder can see it; the buyer accepts a specific promise; a provider can be found and coordinated; and the completed job is valuable enough to pay for.
Each successful job also produces product evidence. What did the customer say? Which details did the provider need? Which reminder prevented failure? Where did trust break? Which exception required founder judgement? When these actions repeat, they become the product specification. When every delivery is different, you have discovered a service rather than a repeatable product.
Step 1: choose one request-shaped problem
“Home services” is not a first wedge. “Find a makeup artist for an event tonight” is. A useful problem is already written by the buyer as a request, carries a deadline, and ends in a result both sides can recognize.
- Buyer: the person accountable for the result.
- Trigger: the event that makes the request active now.
- Outcome: the completed job, not your feature.
- Deadline: when value disappears or risk increases.
- Inputs: what the buyer and provider must supply.
- Exclusions: unsafe, impossible, or economically invalid cases.
Pass condition: find ten recent requests with the same buyer, outcome, and urgency. Stop condition: the requests share a keyword but require unrelated delivery systems.
Step 2: work one concentrated demand source
Seekster used Facebook groups because buyers were already asking for providers there. The channel was not “social media.” It was an active request stream. The modern equivalent might be a niche community, a marketplace board, a LinkedIn conversation, GitHub issues, a migration forum, or a role-change feed with a specific operational consequence.
Review 50 conversations in one source. Record the exact request, timestamp, buyer evidence, urgency, current workaround, and safe manual result. Keep only explicit jobs. A title, like, or generic topic is not intent.
Metric: qualified requests per 50 reviewed conversations. Pass: at least five carry a real trigger and deadline. Stop: the source produces attention but no request you can deliver.
Step 3: make a bounded promise
Seekster's first promise was operational: a call within an hour. The second was a housekeeper within two hours. Neither claimed a platform existed. Your promise needs one outcome, a time boundary, required inputs, and a safe fallback.
You are looking for [outcome] by [deadline]. I can manually deliver [bounded result] using [inputs]. You will receive [artifact or completed job] by [time]. If I cannot meet that condition, I will stop before [risk point] and tell you.
Charge when payment itself is a material assumption. If the work must be free for the first trial, set a decision date and collect a real commitment: access to production inputs, a named user, observed sessions, or a written continue-or-stop review.
Step 4: operate the workflow yourself
Create one row for every delivery. Record the request, acceptance, provider or data source, manual actions in order, elapsed time, failure and recovery, payment, repeat request, and the action that should become product. Observe the handoffs yourself. Delegating too early removes the evidence you need.
Review the ledger after jobs one, three, five, and ten. Highlight repeated work in one color, unique exceptions in another, and unsafe work in a third. Productize repeated safe work. Price unique valuable work as service or exclude it. Never automate an unsafe action merely because it is frequent.
Pass: delivery three requires less coordination than delivery one. Stop: every buyer creates a new workflow and a new category of risk.
Step 5: build the supply side before the interface
Seekster initially focused on customer experience. Around six months later, the team understood that providers needed reminders, customer details, routing, and operational support. A polished demand interface could not compensate for unreliable fulfilment.
Score each provider or dependency on availability, response time, quality, communication, repeatability, recovery, and bypass risk. In an AI product, the “supply side” may be data access, model reliability, approvals, integrations, or a human reviewer. Build the system that makes the promised result dependable.
Step 6: design against leakage and false retention
Seekster later reached substantial volume, but customers and providers could exchange direct contact information and bypass the platform. This is not only a marketplace problem. A workflow SaaS can be bypassed when users export the result and return to email, spreadsheets, an agency, or a direct vendor relationship.
Ask after each job whether the buyer would request the result again, whether they would use the same workflow, and whether contribution remains positive after coordination and recovery. Your product must keep earning its place between demand and fulfilment.
Scale gate: five completed jobs, three repeat requests, falling founder minutes per job, and no repeated safety failure. Stop gate: systematic bypass, uncontrolled quality, or acquisition required before retention exists.
Step 7: choose the next market from operating evidence
Seekster says B2B became the larger market and led to profitability. An independent 2017 report described a partnership with property developer Ananda, 5,000–6,000 monthly jobs, and more than 1,800 providers. The move changed the job from one-off household matching toward repeat property operations with a contractual buyer.
Do not pivot because enterprise contracts sound impressive. Compare repeat frequency, buyer concentration, support load, gross contribution, bypass risk, and sales cycle. Choose the market where the same operating system becomes more repeatable.
The first-customer ledger to copy
Keep one ledger that joins demand, delivery, product learning, and economics. A CRM row that ends at “won” is too shallow. For each of the first ten jobs, preserve the original request, the trigger date, why the buyer trusted the promise, the provider or dependency used, every manual step, total founder minutes, elapsed delivery time, price, direct cost, recovery cost, and the next request. Add a short buyer quote only with permission.
Review the ledger in cohorts. Jobs one to three reveal whether the result can be produced at all. Jobs four to six reveal repeated coordination and the first automation candidate. Jobs seven to ten reveal whether the buyer returns, whether providers bypass the system, and whether founder effort is falling. Do not average away a failure. A safety incident, failed delivery, or repeated bypass deserves its own decision.
Use four labels for every manual action: productize when it is repeated and safe; template when judgement remains but the input and output are stable; service when buyers value unique work enough to pay for it; and exclude when the action creates risk or destroys the economics. This prevents the common mistake of turning every founder favor into a feature request.
At job ten, write a one-page investment memo to yourself. State the supported milestone, repeat rate, founder-time trend, gross contribution, dominant failure, bypass behavior, and the next narrow experiment. The decision is one of four: continue the same manual loop, automate one constraint, change the buyer or job, or stop. “Build the platform” is not a valid conclusion unless the ledger shows which repeated step the platform must remove.
Keep the raw evidence beside the summary. Save screenshots or links to the public request, the accepted promise, delivery timestamps, corrections, and the buyer's repeat decision. Mark founder-reported numbers separately from independently checked facts. This makes later product, pricing, and distribution decisions auditable and prevents a successful anecdote from replacing the less flattering cohort evidence.
The ledger is the product brief, sales record, and stop-loss mechanism for the first ten jobs.
What failed and why the ending matters
The first-ten motion proved real demand. It did not guarantee durability. Seekster described supply complexity and leakage. During COVID, the company tried several new services while protecting provider income. It reported break-even at its fifth anniversary. Then, in February 2026, it announced that it would permanently stop accepting orders from 1 March, citing economic conditions and intense competition.
That closure improves the lesson. A vivid first-customer story can be true while unit economics, retention, channel power, or market structure later break the company. The correct takeaway is not “do things that do not scale and you will win.” It is “use manual work to expose the system, then keep testing whether the system deserves to scale.”
Your seven-day implementation plan
- Day 1: select one buyer, request, deadline, output, and exclusion rule.
- Day 2: review 50 conversations in one concentrated source.
- Day 3: contact five requesters with one bounded manual promise.
- Day 4: deliver the first job beside the buyer and log every action.
- Day 5: deliver jobs two and three; build the dependency scorecard.
- Day 6: automate only the most repeated safe handoff.
- Day 7: review payment, repeat use, founder minutes, failures, and bypass risk.
Lead Scorer implementation
This lab fits when the request appears in public professional signals and can be researched
without inventing intent. Start with $icp-offer-context: define one buyer, job,
trigger, output, and disqualifier. Use $signal-audiences or create_audience_source on one relevant LinkedIn post, event, or search.
Keep three lists: request now, watch, and stop. Score problem evidence, timing, safe manual fulfilment, and repeat
potential before spending enrichment credits. Run $signal-research-dossier on
request-now leads and require two dated sources. Use $contact-discovery only after confirming
the dry-run estimate.
Draft with $cold-email-first-touch. Offer the bounded result, not a generic demo.
Run $outreach-qa-audit and leave every message for human review. Lead Scorer must not activate
or send the campaign automatically.
Find people who explicitly described [job] after [date]. Reject title-only matches. Score timing, problem evidence, safe manual fulfilment, and repeat potential. Put 8–10 in request now, 6–7 in watch, and 1–5 in stop. Do not enrich or contact anyone yet.
Upsert completed-job evidence and repeated objections into Content Studio. Publish useful proof only after review, capture people who engage, and return qualified signals to scoring. The loop becomes request → delivery → evidence → useful content → new signal.
Checklist
- One request-shaped problem and one concentrated source.
- One bounded promise with a safe fallback.
- Manual delivery observed and logged by the founder.
- Supply, data, approvals, and providers scored.
- Retention and bypass tested before acquisition scale.
- Founder minutes falling by job five.
- Failures and the 2026 closure kept in the case.
Sources and limits
- Sahib Anandsongvit on Founder Mode, 25 June 2026. Complete transcript audited from character 0 to 36,035.
- Nation Thailand on Seekster's Ananda partnership and 2017 scale.
- Seekster's five-year CEO message.
- Independent report of Seekster's March 2026 closure.
- UN ESCAP profile of Sahib and Seekster.
The first-ten sequence, 1,000 orders per day, six-month supply lesson, B2B profitability, provider count during COVID, funding total, and exit narrative are founder-reported. The shutdown is independently reported. This course teaches the first-ten mechanism, not a claim that it guaranteed a durable marketplace.
Frequently asked questions
Did Seekster get exactly 100 customers with this method?
No. The founder explicitly describes the first five to ten customers. This course teaches that supported milestone without turning it into a claim about the first hundred.
What was Seekster's first-customer channel?
Requests already posted inside Facebook groups. The founder replied to explicit demand and manually found and coordinated the provider before a product or logo existed.
What should a SaaS founder copy?
Copy the sequence: observe an explicit request, make a bounded promise, deliver the result manually, log every handoff, automate the repeated constraint, and require retention before scaling acquisition.