The First 100 Customers Course #30: How OnRamp Turned a Bubble MVP Into Its First 15 Paying Customers

TL;DR

OnRamp did not use no-code to avoid engineering forever. Co-founder Paul Holder says he and Ross Lerner used Bubble to answer one expensive question before hiring an engineer: would a customer-success leader pay for a simple portal and trust it in front of their own customers? The answer became roughly 15 paying companies.

That count is founder-reported and approximate. There is no public customer list, invoice set, signup denominator, retention cohort, or acquisition-cost data. The transferable lesson is the evidence ladder: operator expertise → buyer interviews → one narrow customer-facing prototype → paid production use → engineering gate. The prototype was temporary. The proof it collected was durable.

What you will build

You will build a paid-proof ladder for one risky B2B workflow. It contains a narrow buyer and problem statement, a 15-interview discovery sprint, one customer-facing prototype, a paid pilot with a real usage test, and a written decision gate for custom engineering. The output is not a prettier MVP. It is a sequence that tells you what evidence must exist before the next investment.

This fits a workflow product when a simple prototype can deliver one useful outcome safely. It does not fit security-critical, regulated, high-volume, or technically irreversible work that the chosen substrate cannot handle responsibly. Do not use “OnRamp did it” as permission to put a fragile prototype into a workflow where failure can harm a customer.

Case snapshot

Stage	What the sources support	Evidence limit
Problem origin	Holder and Lerner had worked on customer onboarding at VTS	Founder account; later profiles confirm roles and company continuity
Discovery	About 3-4 months interviewing customer-success leaders	No public interview count or response rate
Prototype	A simple customer-facing step-by-step portal built in Bubble	No archived build or code is public
Paid proof	Roughly 15 paying customers on the Bubble version	Approximate founder memory; no independent audit
Early price	Holder remembers around $100 per month	He explicitly says he no longer remembers precisely
Engineering transition	Pre-seed funding supported the first engineer and a custom codebase	Chronology is supported; customer count was not the only cause
Early channel	Startup lookalikes, founder networks, advice calls, and introductions	No account-level attribution or conversion data
Failed motion	Google Ads drew services demand; cold email did not work for OnRamp	Company-specific account, not a universal channel verdict

The model: prototype the trust decision, not the whole product

Most MVP advice asks how little software you can build. OnRamp's stronger question was what behavior would prove trust. Its buyer was not testing a private utility. A customer-success leader had to pay and put the portal in front of their own customers. That crossed a reputation boundary. It was stronger evidence than a signup, waitlist, compliment, or polite demo request.

The model has five stages: learn the workflow from operators; isolate the most visible painful step; build only enough to deliver that step; charge for live use; rebuild only when paid demand exceeds the substrate. Bubble was useful because it made the fourth stage possible before a technical hire. It was not the strategy by itself.

Fill this worksheet before opening a builder: buyer, existing process, risky action, smallest proof, payment, and engineering trigger. If you cannot name the risky action, you are probably prototyping screens rather than demand.

Step 1: interview around one workflow you already understand

Holder and Lerner had experienced complex onboarding at VTS. According to the SaaS Club interview, they spent about three or four months checking whether that pain existed beyond one employer. Their advantage was not insider access to a giant market. It was enough operational context to ask about real handoffs, delays, and workarounds.

Run 15 conversations with people who own the same workflow. Ask about the last actual case: what happened after signature, where the customer waited, which handoff failed, what the team rebuilt manually, what the customer could see, and which mistake delayed revenue or adoption. Do not ask whether they like your idea until the event map is complete.

Output: a ledger of repeated events, actors, workarounds, and consequences. Pass condition: at least five buyers independently describe the same costly step. Stop condition: interest appears only after you explain your solution.

Step 2: choose one customer-facing wedge

The first Bubble build did not reproduce the eventual OnRamp platform. It focused on the idea buyers found compelling: a step-by-step portal they could put in front of customers. That choice made the willingness-to-pay test concrete. The buyer had to decide whether the portal was useful and credible enough for a real onboarding.

Choose the smallest part that can cross your trust boundary. For a data product, it might be one verified report delivered on schedule. For a sales product, one reviewed account list with evidence. For an onboarding product, one shared plan that both sides can complete. Do not add an admin suite, analytics, automation, and a marketplace to make the prototype feel complete.

Decision rule: if a feature does not help the buyer complete the risky action, defer it. The purpose of this version is to test behavior, not to demonstrate the founder's full product imagination.

Step 3: charge for real use, not access

Holder remembers early pricing at around $100 per month, but he says he no longer remembers the exact figure. Do not copy the price. Copy the evidence standard: customers paid and used the portal in the workflow that carried their own reputation.

Define a pilot with one workflow, one owner, one success event, and one review date. Track time to activation, completion, manual interventions, failures, support time, and whether the buyer wants to continue. A founder can manually support the outcome, but must record the labor. Hidden service work is acceptable during validation only when it is visible in the economics and does not mislead the customer.

Pass condition: the customer trusts the prototype with live work and completes the success event. Stop condition: the customer pays but never exposes the product to the actual job. Revenue without activation can validate sales skill while leaving product risk untouched.

Step 4: use introductions as an evidence network

OnRamp initially sold to startups that resembled the founders' previous environment. Holder describes advice calls that became problem conversations. When the person was not a buyer, they often knew someone who owned the same pain. He says this network motion carried the company from roughly its first ten customers to its first fifty.

That channel had a limit, and Holder states it clearly: networks run out. It worked because later five-figure contracts meant a small number of trusted introductions could support meaningful revenue. Treat the network as a learning system, not an infinite acquisition engine.

After each useful conversation, ask one narrow referral question tied to the observed workflow. Keep referred leads separate from cold research. Measure introduction source, meeting, qualified problem, pilot, paid continuation, and time to the next introduction. The useful metric is not “warm leads.” It is how much verified learning and paid use each trust path creates.

Step 5: write the engineering gate before the prototype breaks

At roughly 15 customers, OnRamp had both proof and technical strain. Holder says the Bubble version had not reached six figures and could not support the next stage. After the pre-seed round, the company hired its first engineer and moved the validated workflow onto a custom codebase while continuing to sell.

Write the gate before growth makes the decision emotional. Rebuild when paid usage exceeds the prototype's reliable capacity, a buyer requires security or control the stack cannot support, manual operations erase the unit economics, repeated demand needs a missing workflow, or the substrate blocks activation or retention. “We raised money” is not the gate. “The validated job now exceeds the substrate” is.

What failed, and how to diagnose it

The prototype was viable but not truly minimal. Holder says OnRamp tried to cover task management, workflow orchestration, and a customer portal at the same time. The breadth helped later, but he believes going deep on the highest-pain wedge could have moved faster.

Google Ads produced leads, but many wanted services to design their onboarding rather than software to scale an existing program. Cold email was tried repeatedly and had not worked for OnRamp. The correct conclusion is not that paid search or cold email can never work. It is that wrong intent requires a different channel, and a new category often needs recognition before an ask. OnRamp later combined LinkedIn content, ads, connections, and calls into a warmer motion.

• Wrong search intent: change the channel or narrow the query.
• No category recognition: teach the problem before asking for a meeting.
• Three products in one MVP: choose the deepest painful step.
• Mixed segments: pick the buyer whose economics support the product.

Your 7-day implementation plan

1. Day 1: name one buyer, one workflow, and one risky action.
2. Day 2: recruit 15 interviews from your operating network and second-degree introductions.
3. Day 3: conduct five interviews and log observed events, not feature requests.
4. Day 4: conduct five more and rank repeated pain by cost and frequency.
5. Day 5: finish the interviews and define one customer-facing proof.
6. Day 6: storyboard the prototype, pilot terms, success event, and safety limits.
7. Day 7: ask three qualified buyers to pay. Build only after one accepts the live usage test.

Lead Scorer implementation: protect the evidence ladder

Lead Scorer can reproduce the research and drafting discipline around this motion. It cannot create founder trust, decide that a prototype is safe, or turn weak evidence into demand. Use it as the execution surface for list separation, qualification, enrichment gates, and reviewed outreach.

Phase 1: store the narrow context

Define the product and ICP before sourcing: workflow owner, company stage, onboarding complexity, existing process, disqualifiers, and the observable signal that makes the problem plausible. Invoke the ICP and offer context skill, then the scoring-rubric skill. Give workflow ownership more weight than job-title similarity. Set a hard keep threshold before enrichment.

Define an ICP for customer-success leaders at B2B companies with multi-step, high-touch onboarding. Score evidence of workflow ownership, process complexity, and active scaling pain. Disqualify PLG-only onboarding and teams still designing the basic process. Do not invent missing evidence.

Output: a reusable context record and a weighted score. Pass condition: a reviewer can explain every score from cited evidence. Stop condition: the score depends on an inferred pain that no source supports.

Phase 2: separate trust paths

Create three lists: direct operating contacts, second-degree referrals, and cold research. Do not merge them. The provenance changes the ask and the evidence. A referred contact can receive the shared context; a cold contact needs a verified reason for relevance. Score all three before spending contact-discovery credits.

Run signal research on keepers only. Require at least two dated sources when the message claims a live initiative. Contact discovery comes last, after human approval of the company, person, and reason. This preserves the platform's credit gates and prevents an agent from enriching a broad speculative list.

Phase 3: draft interviews, not pitches

Create a draft multichannel campaign with one message per lead. The first ask is a short workflow interview, not a demo. Use verified signals in the opening, name the specific workflow, and ask about the last real case. Keep every draft in review. The agent must not activate the campaign, spend beyond confirmation gates, or send messages.

Draft an interview request for each approved lead. Use only verified signals. Ask about the last real onboarding workflow and its hardest handoff. Do not claim a product result, do not offer a demo, and leave every message for human review.

Output: a reviewed interview queue linked to evidence. Pass condition: the recipient can answer without learning the product. Stop condition: the draft opens with a feature, a generic compliment, or an unsupported pain.

Phase 4: feed objections back into proof

Classify replies as interested, timing, wrong person, objection, or no. Interested replies enter the interview calendar. Wrong-person replies can produce one referral request. Objections go to Content Studio as research questions: which missing proof, safety concern, or workflow detail blocked trust? Useful answers can later become evidence-rich content and new signal audiences. They must not become automatic rebuttals.

The approval loop is the point: context approval, list approval, enrichment approval, draft approval, and send approval. Lead Scorer turns a manual research loop into an agent-driven one; the founder still owns truth, safety, and the decision to build.

Checklist

• One operator-owned workflow, not a broad persona
• Fifteen event-based interviews
• One customer-facing proof
• A paid pilot with one success event
• Introductions tracked separately from cold research
• Manual work, support, and failures logged
• An engineering gate written before the rebuild
• Human approval before enrichment, drafting, and sending

Sources and limits

The early sequence comes from Paul Holder's SaaS Club interview. The founders' origin note, a 2024 funding release, and an independent 2026 founder profile confirm the company, founders, product, and later continuity. A 2025 company announcement and independent funding report document a later $15 million raise and are not evidence for the early acquisition mechanism.

The roughly 15 customers, approximate $100 early price, founder-network attribution, and early chronology are founder-reported. No public source provides the first-customer list, invoices, signup denominator, conversion rate, CAC, or retention cohort. The official episode summary is derived from the same interview, not independent corroboration. This course therefore teaches the evidence sequence without presenting the milestone as audited fact.