The First 100 Customers Course #20: How Stable Turned Google Drive Into 100 Paying Customers

TL;DR

Stable's founders say they served roughly 100 paying businesses with Google Drive, email, live onboarding and hosted Stripe Checkout before they wrote a custom customer application. The useful lesson is not “never code.” It is to sell a complete, narrow outcome first, record every manual exception, and automate only after paid repetition shows where software will create leverage.

What you will build

By the end of this course, you will have a seven-stage first-customer system: a repeated painful workflow, a capacity-safe beachhead, a paid promise, a manually deliverable outcome, a live activation ritual, an exception ledger and an automation queue. You can run the system in seven days without pretending that a waitlist is revenue or that a collection of tools is already a product.

This is for a founder who can reach a small group of buyers and can personally deliver the first result. It is not for regulated work you cannot legally perform, a service whose variable cost you cannot finance, or a product whose value requires scale before any individual customer benefits. Manual does not remove safety, compliance or unit economics. It makes those constraints visible earlier.

The case in one page

Sarah Ahmad and Collin Pham had already built Mistro, a workplace directory product from Y Combinator's Winter 2020 batch. Mistro had pilots and paying customers, but demand collapsed during COVID. Ahmad says the team eventually struggled to attract users even when the product was free. Instead of defending the original idea, the founders returned to discovery.

Across hundreds of conversations with operations managers and founders, one unglamorous complaint kept returning: a company still needed a real business address and a way to handle physical mail. Remote teams were closing offices. Existing providers were designed for individuals or felt old and difficult. The founders narrowed the first offer to companies that needed a California address and received very little mail, a segment they could serve manually without drowning in volume.

They published a landing page inside YC's private Bookface community. According to the founders, dozens of people replied with immediate need. The team then called reputable San Francisco commercial mail-receiving agencies found through Yelp and signed a Market Street partner. A customer paid through hosted Stripe Checkout, joined a live onboarding call, completed the required forms and received a shared Google Drive folder. A Google Doc showed the new address; subfolders held images or PDFs of incoming mail; the founders sent notifications manually.

That workflow remained the customer-facing product for about 100 paying businesses. Ahmad says the team then wrote software piece by piece, with roughly another 100 customers passing through before customers could take meaningful actions in a dashboard. Stable later grew far beyond this cohort, but those later results do not prove that every early tactic will transfer. The founder account is a case study, not an audited funnel.

The operating model: sell the outcome before the interface

A landing page alone is not validation. Stable combined five things: a specific buyer, an urgent trigger, a paid promise, delivery capacity and accountable onboarding. Remove any one and the test gets weaker. A visitor can praise an idea without paying. A customer can pay for a promise that the team cannot fulfill. A manually fulfilled service can look busy while never producing the intended result.

Use this chain as your working model:

Repeated painful workflow → narrow urgent cohort → paid promise → partner-delivered outcome → live activation → exception ledger → piecewise software.

The boundary that matters is not code versus no code. It is evidence versus assumption. Stable used third-party software and a physical operating partner from day one. What it postponed was the custom application whose correct shape was still unknown.

Step 1: find a repeated operational sentence

Do not begin by asking people whether they like your feature. Ask them to reconstruct the last time the workflow happened. Who noticed the problem? What triggered action? What workaround did they use? What did delay or failure cost? Who owns the result? A useful signal is not one enthusiastic quote. It is the same sequence appearing across independent conversations.

Stable's signal was concrete: distributed companies still needed a credible address, mail arrived there, and somebody had to convert that physical event into a digital workflow. The complaint was not “we need a better dashboard.” It existed before any interface. That made it possible to deliver the outcome with temporary tools.

Write one evidence card for every interview:

• Buyer: the person accountable for the result.
• Trigger: the event that makes the problem urgent now.
• Current workaround: the full sequence, including people and spreadsheets.
• Consequence: lost time, risk, delayed revenue or direct cost.
• Access: the community, partner or relationship through which you can return.

Pass this step when the same buyer, trigger and workaround recur. Stop when the language remains generic, every prospect describes a different job, or the pain disappears when you ask for a recent example.

Step 2: choose a beachhead your manual operation can survive

The first ICP is not merely the group most likely to say yes. It must also fit your temporary delivery capacity. Stable qualified early buyers by address need and low mail volume. That excluded companies whose mail volume or geography would break the immature operation.

Define your beachhead with a positive rule and a disqualifier. For example: “B2B SaaS companies that hired their first sales representative in the last 60 days and need weekly pipeline review; exclude teams with more than two sales regions.” The positive rule concentrates urgency. The disqualifier protects delivery quality while you are still learning.

Estimate capacity before outreach. List every manual step, its minutes, its external cost and the person responsible. Then choose a maximum pilot cohort. If ten customers would consume the entire week, do not invite 100. Scarcity is honest when it reflects operating capacity.

Step 3: test a paid promise inside a trusted room

Stable launched into YC's founder community, not into an anonymous internet audience. Bookface concentrated the right buyers and lent the founders trust. That advantage is material. Copying only the landing page removes half the mechanism.

Your equivalent might be an industry Slack group, an accelerator cohort, a customer community, a professional association or 30 warm introductions. Earn permission, describe the narrow outcome and state the manual nature of the pilot. Ask for payment before building the application. Payment does not prove retention, but it is stronger evidence than an email address.

A useful pilot page answers six questions:

1. Who is this specifically for?
2. What completed outcome will they receive?
3. What must they provide or change?
4. How quickly will the first result happen?
5. What is manual, and what data or compliance limits apply?
6. What will they pay now?

Track conversations, qualified buyers, payments and completed outcomes separately. Do not turn “dozens emailed us” into a conversion rate when the visitor count is unknown. Stable's public sources do not disclose early price, CAC or landing-page conversion.

Step 4: assemble the smallest complete delivery system

The MVP must produce the promised result end to end. Stable needed more than a folder. It needed a physical address, a mail partner, authorization paperwork, receipt and scanning, secure delivery, notifications, payment and human support. Google Drive was only the visible layer of a larger operating system.

Design your manual product as five linked records:

• Promise: the outcome and service boundary the customer bought.
• Input: the information, access or paperwork needed to start.
• Work queue: every unit of work, owner, due time and state.
• Evidence: the artifact proving the result was delivered.
• Exception: every case that required judgment, rework or escalation.

If a partner performs a critical step, treat partner capacity as product capacity. Define handoffs, service levels, failure recovery and customer communication before selling. Stable's mail partner was part of the product, not a later distribution partnership.

Step 5: make onboarding the activation engine

The founders onboarded early customers live and handled support themselves. This was not merely white-glove hospitality. It let them observe every missing instruction, compliance question and moment of confusion while helping the customer reach value.

Define activation as the first completed outcome. For Stable, a sensible operational checkpoint is the address change completed and the first piece of mail digitized and delivered. A paid account with unfinished paperwork is not activated. A login is not value.

During each call, record the customer's trigger, promised outcome, missing inputs, time to first value, objections, exceptions and next commitment. End with one explicit success condition. If a buyer repeatedly postpones the required change, that is evidence about urgency or implementation cost, not just a reminder problem.

Step 6: turn exceptions into an automation queue

Do not automate the most annoying task merely because you dislike it. Automate the stable, repeated bottleneck whose inputs and acceptable outputs you now understand. Keep judgment-heavy, rare or high-risk cases with a human.

Score each candidate workflow from one to five on four dimensions:

• frequency across paying customers;
• minutes or cost consumed per occurrence;
• consistency of inputs and outputs;
• cost of an incorrect automated decision.

Build first where frequency, cost and consistency are high and error risk is low. Stable began writing software after about 100 customers and continued replacing the manual workflow piece by piece. The case does not establish 100 as a universal threshold. Your gate is enough paid repetition to define the workflow and enough pressure to justify engineering time.

What failed, and what not to copy

Mistro is the most important part of the story. The team had built software and had paying pilots, yet the market shift destroyed urgency. More product work could not manufacture demand. Returning to conversations exposed a different problem with immediate operational consequences.

Later, Stable tested paid acquisition with only a few hundred dollars per week. Ahmad describes the test as too small to generate confidence and says attribution across early channels was fuzzy. The lesson is not that paid ads never work. It is that an underpowered test should remain “inconclusive,” not become a permanent channel verdict.

Finally, do not copy the milestone as mythology. The first-100 claim is founder-reported; the sources do not publish the early price, exact time to 100, retention, gross margin, CAC or full channel attribution. Current Stable features and later scale cannot be backdated to the manual cohort.

Your seven-day execution plan

1. Day 1: interview five reachable buyers about the last occurrence of one workflow.
2. Day 2: cluster repeated triggers and write one narrow ICP plus disqualifiers.
3. Day 3: map the complete manual delivery chain, partner dependencies and capacity.
4. Day 4: publish a paid pilot promise to one trusted, concentrated audience.
5. Day 5: onboard the first buyer live and deliver the first result.
6. Day 6: review every objection and exception; repair the process, not the story.
7. Day 7: decide whether to repeat, narrow, stop or automate one bottleneck.

The weekly scorecard needs only eight fields: conversations, qualified prospects, payment asks, payments, activated customers, time to first value, delivery minutes and exceptions. Add retention only when enough time has passed for the customer to repeat the behavior. Never fill an evidence gap with an optimistic zero.

Implement the workflow in Lead Scorer

Lead Scorer should hold the evidence and the approval gates; it should not hide an unproven workflow behind automation. Start with the ICP and offer context workflow. Save the buyer, trigger, exclusion rules, approved proof points and claims you must not make. This becomes the shared contract for research, scoring and copy.

Create three separate lists:

• Demand signals: people who described the problem or engaged with relevant content.
• Qualified prospects: companies that match the capacity-safe ICP.
• Pilot candidates: contacts with verified urgency and a reachable decision-maker.

Use the ICP scoring rubric before expensive enrichment. A simple first pass can weight problem fit at 35%, recent trigger at 25%, delivery fit at 20%, authority at 10% and access at 10%. Move scores of eight or more into pilot research, investigate sixes and sevens, and stop on five or below. Calibrate the rubric against people you already know; a precise score built on vague criteria is false confidence.

Next, run signal research until each pilot candidate has two dated, attributable facts. Only then use contact discovery for the people you are genuinely ready to contact. This keeps the most expensive enrichment step behind the fit gate and prevents a large database from becoming a substitute for a narrow market.

Create an AI-authored campaign or a cold-email first-touch campaign as a draft. Give each lead one message anchored to a verified trigger and one paid-pilot ask. Run the outreach QA audit before review. Keep activation manual: a human checks the evidence, approves every claim, chooses the batch and starts the campaign. Drafting is automation; permission to contact someone is still a decision.

When replies arrive, use reply triage to separate interest, timing, wrong person, objection and rejection. Route interested buyers to live onboarding. Send repeated objections back to the ICP context and Content Studio as topics for proof-rich explanations. Capture people who engage with those explanations in a signal audience, deduplicate them, then score them through the same gate. That closes the loop without treating engagement as intent.

Copy this operating prompt into your workspace:

Build a pilot list for [narrow ICP] with [recent trigger].
Disqualify [capacity or compliance limits].
Require two dated sources before contact discovery.
Score problem fit, urgency, delivery fit, authority and access.
Draft one message per accepted lead with one paid-pilot ask.
Do not send, activate or publish anything without my review.

Decision checklist

• Can you name the buyer, trigger and current workaround without feature language?
• Can the first cohort fit inside your real delivery and partner capacity?
• Will the buyer pay before custom software exists?
• Can you prove the completed outcome with an artifact or state change?
• Are you recording delivery time, objections and exceptions for every customer?
• Is the next automation chosen from repeated paid work rather than founder preference?
• Do you have a stop rule if buyers praise the idea but avoid payment or activation?

Sources and evidence limits

The core operating facts come from Sarah Ahmad's SaaS Club interview and full transcript and Collin Pham's 2021 first-100 account. The company's founders and YC batch are corroborated by Y Combinator's Stable profile. Stable's current product documentation is useful only for present-day scope; it is not evidence of what existed for the first cohort. A 2026 Authority Magazine interview repeats the later customer scale, but that figure still originates with the company.

Treat “100” as a supported founder-reported milestone, not audited precision. The sources use “about” and “first 100 or so.” They do not disclose early price, retention, gross margin, CAC, exact time to the milestone, landing-page traffic or partner economics. The course therefore teaches the observable sequence and its limits, not a fabricated conversion model.