If you want the first 100 customers for a B2B product, "get more traffic" is a poor place to start. The stronger question is what a new buyer can finish on their first visit that was painful to do yesterday. Baremetrics' early customers were SaaS operators who needed subscription numbers but were assembling them manually from Stripe data and spreadsheets. Connecting their account produced a useful dashboard immediately. Some of those customers then told other founders about it.
Josh Pigford wrote in April 2014 that Baremetrics reached its first 100 customers in roughly four months without a free plan or free trial; he put the average customer price near $70 per month. He credited Twitter for much of the discovery, but his own account makes the mechanism more precise: an urgent existing job, a very short path to the first result, and a result easy to explain to another founder. Those are founder-reported historical facts. They are a case to examine, not a present-day customer acquisition benchmark. Source: Pigford's first-100 account.
The short answer for another product is to make the first session answer a question the customer already cares about, using information they already have. Then see whether the result is valuable enough to pay for and specific enough to recommend. A polished tour, long trial, or attractive dashboard will not compensate for a weak first result.
The customer already had a job
Baremetrics did not need to persuade SaaS founders that revenue, churn, and subscriptions mattered. Its early buyers were already doing the work, often in spreadsheets or makeshift integrations. Pigford says those customers spent hours calculating figures and still lacked useful visibility into their business. The product connected to Stripe and displayed their historical data without making them wait for new events to accumulate. Source: first-100 account.
This is the distinction between an education problem and an execution problem. A founder who is unsure whether a metric matters needs explanation. A founder who already exports Stripe data every week needs that recurring task removed. The latter can judge a new tool quickly because the before-state is familiar and costly.
| Before Baremetrics, as described by Pigford | First session with Baremetrics | Why that matters |
|---|---|---|
| Export payment data and assemble calculations | Connect a Stripe account | No blank workspace to design |
| Maintain a spreadsheet or custom integration | Import historical transactions | Value appears using existing data |
| Reconcile numbers and interpret trends manually | See a populated metrics dashboard | A decision can begin immediately |
| Explain the workflow to another founder | Show the resulting dashboard | The recommendation is concrete |
I read the case as an activation design problem, not a social-media tactic. If the product had required weeks of event tracking before it showed anything, the same audience might have produced clicks and little word of mouth. If the dashboard had merely reproduced Stripe's existing interface, the first result would have been less remarkable. The value came from collapsing several unpleasant steps into a quick, comprehensible answer.
What happened in the first year
Pigford later published a timeline: idea in October 2013, initial launch in November, rebuild and relaunch in January 2014, public demo in February, first 100 customers by April, and more than $10,000 MRR by May. By September, he reported $20,000 MRR. This retrospective comes from the founder, so the dates and amounts should be read as the company's account of its own history. Source: Baremetrics' one-year timeline.
That sequence matters for two reasons. First, the first version was not the final product; Pigford says he rebuilt it soon after launch using paying-customer feedback. Second, the public demo appeared after the core connection and customer use were working. A demo can help someone imagine value, but the connected account is where the value was tested.
The 2014 post includes several contemporaneous customer comments about saving spreadsheet effort and seeing instant subscription insight. Those comments are not a representative survey. They do, however, identify the exact point customers chose to tell peers about: what appeared after connection. They are stronger evidence for a shareable first result than a founder's assertion that people liked the product. Source: first-100 account.
| Stage | Evidence available | What the next stage needed to prove |
|---|---|---|
| Manual metrics pain | Founder's own work and customer conversations | More than one founder had the same job |
| First paid use | Customers connected real accounts and paid | The result deserved continued payment |
| Unprompted recommendations | Early users described the benefit publicly | The message could travel beyond personal contacts |
| Rebuild | Feedback from paying accounts | The product could improve without losing its simple promise |
| 100 customers | Aggregate customer count | Retention and economics still needed monitoring |
One useful counter-reading is that Pigford was already visible among software founders. Distribution was not free; it was a network and a channel that reached qualified buyers. His account says Twitter was the largest source of first customers. It does not isolate the effect of product design from the effect of his network, his public writing, or the growing Stripe ecosystem. We can identify a plausible mechanism, but not calculate a causal contribution from the public record alone.
A present-day check: the core result still depends on existing data
Baremetrics' current Stripe integration documentation says it imports historical customer, subscription, and transaction data, then keeps subscription data updated. It now estimates an import commonly taking 5–15 minutes rather than the literal one-click, instant experience described in 2014. The same documentation notes that metrics may briefly show zero while calculations finish. This is a useful correction to a simplistic retelling: "instant" meant an unusually short route to a meaningful result for that job, not zero processing time under every condition. Source: current Baremetrics Stripe integration guide.
We did not create a new Baremetrics account or connect private payment data for this article. The check is of public documentation, so it establishes the documented flow, not a first-hand measurement of current onboarding. That distinction matters because onboarding changes over time while the underlying design question remains: what information can you use to show the customer a result before asking them to configure a large system?
Oddig's first-result audit
Use this audit if signups arrive but few people reach the action that makes your product useful. Begin with five recent first-time users. For each one, ask them to bring the real input they would normally use. Watch the full first session without guiding them. Record elapsed time and the point at which they can make a better decision, not merely the point at which an account has been created.
1. Name the pre-existing task
Write it as a sentence with a verb and an object: "calculate last month's expansion revenue from Stripe" or "turn a customer-call backlog into prioritized requests." Avoid feature language such as "open analytics". If a prospective user cannot describe when they last did this task, the job may be too weak or too infrequent to support your promise.
Ask for the artifact from the last occurrence: a spreadsheet, email chain, brief, support ticket, or dashboard screenshot. Note how long it took, what was uncertain, and who needed the answer. A claimed ten-hour pain that happens once a year differs from a thirty-minute pain repeated every week.
2. Map the inputs the customer already owns
Baremetrics benefited from an existing Stripe history. Another product may use a document, public URL, calendar, repository, or product image. Write down the minimum input needed to produce the first useful output and whether the user can grant access safely. Do not ask for a complete workspace setup if one object is enough.
If the task requires sensitive data, trust is part of activation. A customer may value the outcome but decline to connect a payment or health account without a clear explanation of scope, permissions, deletion, and security. Measure that refusal separately from lack of interest in the result.
3. Define the first answer, not the first screen
Choose a question the product should answer by the end of the first session. For Baremetrics it might have been, "What has happened to my recurring revenue and subscriptions?" For a small research tool it might be, "Which three customer objections recur in these calls?" The output should point to a decision or next action.
Now remove every onboarding step that does not materially improve that answer. A step may be necessary later for collaboration or configuration but unnecessary before the first result. Keep a list of deferred steps so the product can ask for them when their purpose is visible.
4. Test recommendation language
After users get a result, ask: "If a colleague had this problem, what would you tell them this tool does?" Write down their words. A strong answer names the old pain and the new result. A weak answer names a feature category or says the interface looks nice. Do not prompt users to share publicly during this test; the goal is to learn whether the outcome explains itself.
5. Ask for the next commitment
The commitment depends on the business: pay, import a second data source, invite a teammate, run another report, or keep the integration connected through the next operating cycle. Select it before testing. Five enthusiastic sessions followed by no second use are a product warning, even when time to first result is short.
A worksheet with stopping conditions
Do the arithmetic for your own product rather than copying the Baremetrics story. Use one row per user, then compare patterns across the first five.
| Field to record | Example answer | What would change the product decision? |
|---|---|---|
| Last time the job occurred | "Every Monday before the revenue meeting" | If it rarely occurs, consider one-off pricing |
| Current workaround | "Export Stripe CSV, update spreadsheet" | If no workaround exists, test whether the job is important |
| Time to first useful answer | "Eight minutes after connecting" | If setup dominates, reduce required inputs |
| First answer used | "We found a churn spike in one plan" | If nobody acts on it, clarify the output |
| Unprompted explanation | "It replaces our manual MRR sheet" | If vague, improve the promise and result |
| Next commitment | "Finance manager invited" | If none, test whether value continues |
Choose thresholds suited to your customer and task before the test. For example: at least four of five can complete the real job without your help, at least three name the same benefit in their own words, and at least two take the next meaningful action. These are experiment criteria, not industry averages. If the result fails, change the input, output, or target customer and test again. Buying more traffic at that stage would increase the number of people encountering the same weak experience.
Where the Baremetrics pattern stops working
An immediate result is easiest when the customer has useful historical data in a well-structured system. A product that requires months of behavior, a team-wide rollout, or a change in legal process cannot honestly promise the same first session. It can still give a smaller first answer: an audit of existing data, a sample workflow using a safe subset, or a single task completed manually with the customer.
Likewise, recommendation is not automatic. Baremetrics served a networked niche of founders who recognized the same spreadsheet pain. A tool for a confidential internal workflow may be valuable yet rarely shared publicly. In that situation, measure retention, expansion, or referrals through private introductions instead of copying a public word-of-mouth tactic.
The case also does not prove that free plans are bad. Pigford chose not to use one in that period; that was a choice in a particular market at a particular time. The more transferable lesson is to expose the value quickly enough that a buyer can decide whether paying is reasonable. A trial may help when the job takes more time to prove. A free plan may help when the product needs collaboration or network effects. Both should be judged by the next commitment, not by sign-up volume alone.
The question to take into your next product review
Show your team the first session of five real users. At the moment each user stops, ask: "What did this person learn, save, complete, or decide that they could not do as easily before?" If the answer is only "they created an account," fix the first result. If the answer is specific but users still leave, investigate whether the result solves a recurring job, reaches the right buyer, and arrives early enough to matter.
Baremetrics' early story is memorable because the first result and the customer problem fit tightly. The acquisition channel amplified that fit. The operating task for another founder is to find their own version of the spreadsheet that a qualified customer is already tired of maintaining.
Related Oddig reading
- Test demand before building a SaaS addresses the evidence needed before the activation work starts.
- Build a growth loop after launch extends the question from first result to repeated use.
Sources and method
- Josh Pigford, "How We Got Our First 100 Customers": first-person account of acquisition, product use, pricing, and recommendations.
- Pigford's one-year timeline: dates and historical company-reported milestones.
- Baremetrics' current Stripe integration guide: documented present-day import and connection flow.
Oddig did not inspect Baremetrics' private customer data or independently attribute the first 100 customers to a single cause. The first-result audit is an editorial tool based on the case and has not been measured across an Oddig customer sample.
