The First 100 Customers Course #29: How Browserless Turned GitHub Help Into Its First 10 Customers

TL;DR

Browserless founder Joel Griffith says his first ten customers did not come from a launch, an ad budget, or a cold-email list. They came from developers already describing a painful production problem in GitHub issues, Stack Overflow, and Reddit. He answered the technical question first, then offered Browserless only as the managed alternative for people who did not want to operate Chrome themselves.

The first customer reportedly chose the highest plan at $200 per month while the service cost roughly $50 in infrastructure. But the fast first margin did not create fast growth. Griffith estimates Browserless was around $1,000 MRR or less after year one. The repeatable system was slower: useful answer → paid user → support question → durable documentation → more discoverable proof. The first-ten attribution and economics are founder-reported, with no public conversion or retention data.

What you will build

You will build a permission-aware help queue for a technical SaaS: one narrow problem map, one community listening routine, one answer template, one disclosed product bridge, one support-to- content rule, and one measurement sheet. The output is not a scraping bot or a comment campaign. It is a small operating system for being useful where qualified buyers already ask for help.

This fits a developer tool or technical workflow product when the founder can genuinely solve the underlying problem without the product. It does not fit when the community bans commercial participation, when the founder has no domain expertise, or when the product requires interrupting people who have not asked for help.

Case snapshot

Stage	What the sources support	Evidence limit
Problem discovery	Repeated crashes, memory issues, Docker setup, missing packages, and browser upkeep	Founder account and current repository documentation
Market choice	Five or six consumer ideas failed before Griffith chose a problem he knew as an engineer	Approximate founder count
First channel	GitHub issues, Stack Overflow, and an active subreddit	No platform split or reply count
Manual work	Teach the direct fix first, then mention Browserless as the optional managed path	Founder says he sometimes crossed rules and got in trouble
First milestone	Ten paying customers; first plan reportedly $200 per month	No customer list, dates, or independently verified invoice
Early economics	About $50 infrastructure against the first $200 plan	Excludes labor and other operating costs
First year	Roughly $1,000 MRR or less	Founder uses “maybe” and approximate language
Compounding layer	Support became documentation; content later brought larger customers and most inbound	No audited attribution or cohort data

The model: solve the public problem before selling the shortcut

The causal loop is live technical pain → useful public answer → optional managed alternative → paid customer → support insight → durable documentation → more discoverable pain. The first answer proves competence. The product bridge lets the buyer trade money for avoided operations. Support creates the next answer. Each turn leaves an asset behind.

The order matters. A product mention without a complete answer is promotion. A useful answer with no relevant bridge is community work but not a distribution system. Browserless connected the two because the free answer and the paid product solved different layers: “here is how to run it” and “we will run it for you.”

Step 1: choose a pain you can diagnose without your product

Browserless grew from Griffith's own repeated problems with headless browsers. A wishlist side project exposed fragile browser automation, but he could also recognize the same failure pattern from PDF generation, testing, scraping, Docker, and production infrastructure. That was stronger evidence than a broad interest in developer tools.

Build a problem map with four columns: observable failure, expensive workaround, person feeling it, and the smallest useful answer you can give without your product. Keep only problems you have solved at least twice. A good wedge is narrow enough that the buyer can search for the error, yet costly enough that reliable operations are worth paying for.

Pass condition: you can explain and repair one recurring failure from first principles. Stop condition: your only answer is “book a demo” or “try my tool.”

Step 2: find live demand, not a list of job titles

Griffith sorted Puppeteer's issues by most commented. He was not looking for people who matched a persona label. He was looking for repeated failures with visible urgency: Chrome in Linux, Docker dependencies, memory pressure, zombie processes, and unreliable production behavior.

Create a daily 20-minute listening block. Review official issue trackers, technical forums, public community searches, and the questions arriving in your own support. Score each thread on recency, pain, fit, permission to answer, and whether the problem is already resolved. Do not harvest private identity data or move a discussion off-platform without invitation.

Pass condition: five current questions match the same narrow failure and community rules permit a useful response. Stop condition: the signal is merely a job title, keyword mention, or old thread revived for promotion.

Step 3: answer in two layers

Browserless's answer pattern was practical. Griffith described the package a developer needed, warned about the next dependencies, and called out operational traps. Only then did he add the alternative: use Browserless if you prefer not to manage that layer.

Use a two-layer answer template. Layer one contains diagnosis, direct fix, caveats, and a way to verify the result. Layer two contains one sentence disclosing your affiliation and the paid shortcut. A reader who never clicks should still leave with the solution. Follow current rules; some communities require explicit disclosure and others prohibit product mentions entirely.

Pass condition: a moderator could remove the product sentence and the answer would remain the best response in the thread. Stop condition: the answer hides affiliation, withholds the fix, or repeats across unrelated threads.

Step 4: price the avoided operation

The first Browserless customer reportedly paid $200 per month, its highest plan at the time. The founder estimated about $50 in infrastructure, so the account covered direct hosting. That does not prove full profitability, but it does show the buyer valued removed operational pain more than a token entry price.

Price against the avoided burden: engineering time, failures, security maintenance, capacity, and incident risk. Write down direct cost, support minutes, expected concurrency, and a failure reserve. Do not copy $200. The useful rule is that one qualified customer should validate both willingness to pay and a plausible contribution margin.

Pass condition: the first plan covers direct delivery and the buyer can name the work it replaces. Stop condition: free usage is the only evidence, or support turns the plan negative before founder labor is counted.

Step 5: convert every support answer into one durable asset

While running Browserless beside a full-time job, Griffith used one rule: each stream of work needed two or three outcomes. A support fix should solve the customer's issue and create documentation so the same question does not demand the same work again. Later, long-form content brought the first multi-thousand-MRR accounts.

Add an asset decision to support closure. If a question is repeated twice, high-risk, or blocks setup, turn the answer into a documentation page, runnable example, or troubleshooting note. Link it from the product and from future permitted answers. Record the originating question, the verified fix, and the date it was retested.

Pass condition: the next user can solve the issue without founder intervention. Stop condition: content is written for a broad keyword while real support questions remain undocumented.

Step 6: measure trust separately from traffic

Griffith says Hacker News front pages, GitHub trending, and mentions from major developer advocates created visible spikes but did not translate directly into an MRR windfall. The slow work of showing up around the problem produced the paid relationships. Users later carried Browserless from one employer to another.

Track four stages: qualified questions answered, repeat visitors to the technical asset, product starts attributed to that asset, and paid conversions. Add a qualitative field for “brought to a new company” because practitioner mobility can be a real developer-tool expansion path. Do not optimize raw views before you know which questions create product evaluation.

Pass condition: at least one answer-to-evaluation path can be reconstructed with consent. Stop condition: a traffic spike is reported as distribution success without product or revenue evidence.

What failed and what stayed slow

• Broad consumer ideas failed: Griffith estimates five or six B2C attempts before choosing a problem grounded in his engineering experience.
• Community promotion crossed lines: he says he got in trouble and that rules are tighter now. The modern playbook must lead with complete help, disclosure, and permission.
• Early profitability did not mean fast scale: Browserless was only around $1,000 MRR or less after the first year by the founder's estimate.
• Virality was not the revenue engine: large attention spikes built awareness but did not directly produce the recurring-revenue jump.
• The founder remained the bottleneck: support, engineering, content, and sales stayed concentrated until operating complexity justified outside help.

Your seven-day implementation plan

1. Day 1: list ten failures you have personally repaired and choose one repeated pain.
2. Day 2: map five permitted communities and write down their promotion rules.
3. Day 3: collect ten current questions; score them for urgency, fit, and answerability.
4. Day 4: publish three complete answers with affiliation disclosed where relevant.
5. Day 5: turn the strongest repeated answer into one tested documentation asset.
6. Day 6: instrument question, asset, product-start, and paid-conversion attribution.
7. Day 7: review replies and support; keep the pain only if two qualified people progressed.

The week's output is three useful interventions, one durable asset, and one evidence sheet. It is not ten promotional comments. If the work creates no qualified conversation, change the problem or community before increasing volume.

Lead Scorer implementation

Lead Scorer fits after the public help creates an identifiable, consent-respecting company signal. It should not scrape anonymous handles, post community replies, or automate self-promotion. Use the MCP from Codex or Claude for the research and follow-up layer, with the founder approving every message.

Phase 1: store the narrow buyer and exclusion rules

Use icp-offer-context to define the technical pain, product stage, team shape, infrastructure constraint, and roles that own the problem. Add explicit exclusions: students asking general questions, consultants researching for clients, anonymous accounts, competitors, and anyone whose community rules prohibit commercial follow-up.

Define an ICP for a managed developer-infrastructure product. Require evidence that the company runs the relevant workload in production and that a named technical owner is solving the operational failure now. Exclude anonymous community accounts and any signal that cannot be sourced publicly.

Pass condition: the ICP names one problem and one accountable operator. Stop condition: “developers” is the entire target market.

Phase 2: score before enrichment

Use signal-research-dossier to require two verified, dated signals per company: the public technical pain and evidence that the company operates the relevant system. Then apply icp-scoring-rubric. Weight pain recency, production stakes, technical fit, identifiable owner, and permission to contact. Require at least 8/10 before spending contact-discovery credits.

Research these companies behind verified public technical signals. Keep only those with two dated sources and a named operator responsible for the workload. Score before enrichment and skip every account where the signal depends on guessing an anonymous person's employer.

Pass condition: every enriched lead has two sources and a written reason to contact. Stop condition: the research converts community participation into surveillance.

Phase 3: draft a permission-based continuation

Use cold-email-first-touch only when a public company signal supports direct contact. Draft one message per lead, under 150 words, with one ask. Reference the useful artifact, not the founder's comment activity. Run outreach-qa-audit and leave every campaign in draft for human approval. The founder decides whether the relationship justifies outreach.

Draft a first touch that shares the tested troubleshooting asset and asks whether the same production constraint is active. Use only verified signals, make one claim, make one ask, and do not imply that a public question granted permission for a sales sequence.

Pass condition: the recipient gets immediate technical value even if they never reply. Stop condition: the message mentions monitoring their comments or starts a sequence without review.

Phase 4: close the objection-to-content loop

Classify replies with reply-triage. Send product objections, failed setups, and repeated questions back into Content Studio as candidate documentation. Capture new signal audiences only from explicit, permitted public engagement. No campaign is activated and no message is sent until the user reviews the draft and approves the action.

The result is the same structural loop Browserless used: evidence produces a useful answer; the answer produces a qualified conversation; the conversation improves the asset. Lead Scorer makes the list, scoring, evidence, and drafting repeatable. It does not replace the founder's technical help or the community's rules.

Checklist

• Choose one production problem you can solve without your product.
• Read and record the current rules of every community.
• Answer the full technical question before disclosing the optional shortcut.
• Price avoided operations, not attention or goodwill.
• Turn repeated support into tested documentation.
• Measure question-to-evaluation paths separately from traffic spikes.
• Score and enrich only when a permitted, company-level signal exists.
• Keep product follow-up in draft until a human approves it.

Sources and limits

The core evidence is The SaaS Podcast episode 473. Its complete official transcript was audited from character 0 through 51,098 in seven contiguous windows. The Browserless About page and current GitHub repository confirm the product origin, operating pain, and continuing open-source presence.

A contemporaneous 2019 Failory interview independently publishes Griffith's account that early users came from GitHub issues and Stack Overflow, when the business was around $4,000 per month. A 2021 Flagsmith interview and the founder's 2022 $1M ARR AMA support company continuity. These are independent publishers or founder-authored records, not audits of the first ten.

No source supplies the first-ten customer list, dates, platform split, reply rate, trial conversion, churn, or retention. The first customer's $200 plan, roughly $50 infrastructure cost, and early MRR remain founder-reported. The current company site says 10,000+ paying customers while the March 2026 interview estimates 3,000–4,000 paid users; definitions and dates may differ, so this course does not derive a growth rate from them.