The First 100 Customers Course #34: How TabaPay Turned 10 Warm Relationships Into Partner-Led Inbound

TL;DR

TabaPay's first 10 customers came from people the founders already knew. They were not giant banks. Co-founder Rodney Robinson says they were small fintech companies with the exact problem TabaPay was built to solve: moving money out and collecting it back through one instant, cost-conscious system.

The reusable mechanism was narrow pain → warm first 10 → vendor-backed delivery → reliability proof → trusted partner referrals → qualified inbound. Warm access opened the first doors. It did not remove the need to survive a critical workflow. The evidence does not show that this sequence produced exactly 100 customers, and no public partner-attribution funnel exists.

What you will build

You will build a six-gate trust ladder for a B2B product whose failure can damage the customer's operations. The outputs are a one-degree wedge, a 20-account relationship map, a delivery-risk budget, a first-ten offer, a customer proof packet, and one partner-referral experiment.

This is for infrastructure, security, data, compliance, workflow, or vertical SaaS products that need trust before scale. It is not for a broad self-serve app that a buyer can test alone in five minutes. TabaPay also had unusual advantages: decades of payments experience, existing industry relationships, an investor who had backed a previous company, and founders willing to accept personal and regulatory risk. Copy the sequence, not the risk appetite.

Case snapshot

Stage	What the evidence supports	Evidence limit
Wedge	Instant push and pull money movement for regulated fintech companies	Founder and company accounts; not a claim of inventing every underlying rail
First system	Roughly one year assembling software, vendors, and sponsor-bank access	No dated build log; first-revenue timing conflicts inside the interview
First 10	Small fintech founders already known to the team	Names, prices, contracts, order, and conversion denominator are private
Manual work	Founder calls, vendor coordination, bank sponsorship, and a personal guarantee	The guarantee is founder-reported and not a recommended default
Later inbound	Banks and payment networks referred companies with the relevant problem	No customer count or channel percentage is public
Failed channels	A large outbound team and a part-time Mexico experiment did not work	Spend, duration, activity, and conversion are undisclosed
Later scale	Founder reports $100 million in revenue; company reports $100B annualized volume	Separate metrics, neither proves the early acquisition funnel

The model: borrow trust, then become referrable

The original observation came before the product. Robinson had worked on instant payouts that became part of Mastercard Send. Customers also needed the reverse flow: lenders and other regulated businesses had to collect money without destroying their economics. Mastercard did not want to compete with the processors handling that side. TabaPay formed around the gap. The company's own founding history corroborates the push-pull thesis.

The team did not spend years owning every layer before speaking to a customer. It assembled the first system with vendors, accepted higher costs, and charged what the market would bear. That bought learning speed. It also imported every vendor's availability into TabaPay's own service. The first 10 accounts therefore did two jobs: they paid and they exposed the reliability work required before a trusted institution could refer another customer.

This is more precise than “use your network.” A relationship can transfer enough trust for a first test. It cannot make a fragile product reliable. TabaPay had to convert borrowed founder trust into operational proof, then package that proof so banks and networks could safely point their own clients toward it.

Step 1: write a one-degree wedge

Define one painful job, one buyer, and one incumbent constraint. TabaPay did not begin as a universal money platform. Its early buyer was a regulated fintech that needed both directions of instant movement at a cost its business model could absorb.

We help [narrow buyer] complete [critical job] when [incumbent constraint] makes the usual option too expensive, slow, risky, or incomplete.

Interview five operators without showing them this sentence first. Record the workflow, current workaround, cost of failure, switching risk, decision owner, and trigger date. Pass: five buyers independently describe the same blocked job. Stop: every interview asks for a different product or the problem is irritating but not operationally important.

Step 2: map 20 relationships, not 2,000 leads

Build a worksheet with account, person, problem evidence, relationship owner, source of trust, current workaround, switching risk, buying authority, and next conversation. Ask who owns the exact problem, not who likes the founders. TabaPay pursued small fintechs rather than the largest financial institutions it could name.

Score pain, authority, timing, tolerance for an early vendor, and learning value from zero to two. Require at least seven of ten. A friendly contact without the problem is excluded. A cold account with the problem can wait until the first proof exists. Pass: ten qualified conversations produce three concrete next steps. Stop: introductions are warm but the operational problem is missing.

Step 3: buy speed with a delivery-risk budget

List every layer you could build, buy, or handle manually. For each one, record time saved, margin cost, availability dependency, compliance exposure, fallback, owner, and the date when you will reconsider ownership. A vendor is not just a line item. It is imported behavior.

Robinson explains the compounding risk plainly in the September 2026 founder interview: if several dependencies each fail, their downtime becomes part of your promise. TabaPay later replaced processing vendors and moved toward direct control. It did not pretend those vendors were invisible.

Pass: the buyer receives the critical outcome and every dependency has a monitored owner and tested fallback. Stop: you cannot explain who responds, who pays, or how the customer continues when the borrowed layer fails.

Step 4: turn the first 10 into a proof packet

For each early account, capture the original pain, integration path, manual work, first successful job, incident history, recovery time, value delivered, and permission for a reference call. Separate observed evidence from the founder's interpretation. A signup is not proof for a critical workflow.

The packet should answer four partner questions: Who is this for? Which job is solved? What can break? What evidence shows the operator responds well? Include one architecture explanation, one incident-and-recovery note, one customer outcome, and one exclusion rule. Pass: two customers describe a recurring outcome and one accepts a reference call. Stop: the packet contains only logos, praise, or vanity volume.

Step 5: earn one trusted referral channel

List the institutions the buyer already asks for advice: banks, platforms, consultants, agencies, communities, or integration partners. Choose one whose economics improve when your customer succeeds. TabaPay says an early sponsor bank was itself entering fintech, while payment networks benefited from net-new transaction activity. Referral value and partner incentive pointed in the same direction.

Send a proof packet, not a generic partnership deck. Ask for one introduction to one matched account. Track referrals, accepted calls, qualified problems, technical evaluations, pilots, and wins as separate events. Pass: the partner sends two qualified introductions without repeated chasing. Stop: the partner likes the idea but cannot name a customer, a trigger, or a reason to refer now.

Step 6: build selective inbound, not passive waiting

Robinson describes inbound as targeted message plus trusted distribution, not publishing random content and waiting. TabaPay made its market and problem legible, then equipped banks and networks to route matching demand. Salespeople still needed enough domain knowledge to diagnose inbound calls.

Write one problem page and one partner briefing. Both must state the buyer, trigger, job, evidence, failure boundaries, and disqualifiers. Review inbound quality monthly. Pass: at least half of referred calls match the wedge and arrive with a named problem. Stop: volume grows while fit falls, or sales depends on reteaching the partner every week.

What failed, and what not to generalise

TabaPay tried a large outbound sales force. Robinson says it did not work. The company also treated Mexico as a side experiment rather than funding a complete local channel. That failed too. His conclusion is that outbound is obsolete in B2B. Treat that as a strong operator opinion grounded in a trust-heavy payments context, not as a universal law.

A lower-risk SaaS with a visible pain may still make narrow outbound work. The transferable decision is to match the channel to the trust burden. When a buyer risks money movement, compliance, or uptime, a referral from an accountable institution can remove more friction than another cold email. When the product is easy to test and reverse, direct outreach may remain the fastest learning loop.

Do not copy the personal guarantee as founder theatre. Robinson says he pledged his house to secure bank support. The public evidence does not provide the terms, and a regulated payments business is not a template for ordinary SaaS financing. The reusable lesson is to identify the trust instrument the partner requires and decide explicitly whether the downside is acceptable.

Your seven-day implementation plan

1. Day 1: write the wedge and five exclusion rules.
2. Day 2: build the 20-account warm relationship map.
3. Day 3: interview five accounts about the critical job and switching risk.
4. Day 4: complete the build-buy-manual delivery-risk budget.
5. Day 5: write the first-ten offer, checkpoint, and stop condition.
6. Day 6: create the proof-packet template before proof exists.
7. Day 7: choose one partner type and test its referral incentive.

The output is not a promise of 100 customers. It is a defensible route to the first few accounts and a measurable test of whether their proof can travel through one trusted intermediary.

Lead Scorer implementation: preserve the trust ladder

Lead Scorer can organise the research, qualification, contact discovery, and reviewed drafts. It cannot create a real relationship, verify an undisclosed first-ten ledger, guarantee partner referrals, or activate a campaign without approval. Use it to keep this motion narrow.

Phase 1: store the wedge and split the lists

Run icp-offer-context with the critical job, exclusions, allowed proof, and forbidden claims. Create two separate lists: Warm first-ten accounts and Potential trust partners. Use search_companies only to complete named-account facts, then create_list and add_companies_to_list. Never mix partner records into the buyer sequence.

Define the ICP for [wedge]. Exclude accounts without [critical job], buying authority, or a near-term trigger. Create a separate partner profile for institutions this ICP already trusts. Do not infer a relationship or claim proof we do not have.

Pass: every record belongs to exactly one stage and has dated problem evidence. Stop: list membership depends on company size or job title alone.

Phase 2: score before enrichment

Give buyer fit 40 points, problem evidence 25, authority 15, trigger timing 10, and early-vendor tolerance 10. Require 75 before contact discovery. For partners, score buyer trust, incentive alignment, access to the ICP, and willingness to make a named introduction. Run signal-research-dossier for dated evidence. Use contact-discovery or find_lead_contact_info only on keepers and only after reviewing the credit estimate.

Pass: a reviewer can explain the score from sources. Stop: the model fills evidence gaps with plausible industry assumptions or spends enrichment credits on a broad list.

Phase 3: draft two different conversations

Create a draft campaign for warm accounts and a separate draft for partners. The warm note should identify the real relationship and ask for a problem interview, not pretend a case study exists. The partner note should carry the proof packet and ask for one matched introduction. Use generate_campaign_drafts, then run outreach-qa-audit. Review every message. Do not activate or send without explicit human approval.

Draft one interview ask for each qualified warm account and one proof-packet introduction ask for each qualified partner. Use only verified relationship and problem signals. One ask per message. Leave the campaigns in draft and stop when evidence is missing.

Phase 4: turn replies into channel evidence

Tag objections as switching risk, reliability, compliance, integration, authority, or timing. Move repeated objections into Content Studio as source material for technical proof. Record every referral as referred, accepted, qualified, evaluated, piloted, won, or rejected. A warm reply is not a customer, and a partner introduction is not a qualified opportunity until the problem is confirmed.

Pass: two accounts complete the critical job and one partner sends two qualified introductions. Stop: the team optimises replies while delivery proof remains weak.

Saveable checklist

• One narrow buyer, critical job, and incumbent constraint
• Twenty relationships scored for fit rather than friendliness
• A build-buy-manual budget with imported failure modes
• First-ten success and stop conditions
• Proof beyond signups, logos, and praise
• One partner with a visible incentive to refer
• Separate buyer and partner lists
• Human review before enrichment spend and every send
• No claim that partner inbound caused later scale without attribution data

Sources and limits

The first-ten account, vendor tradeoffs, personal guarantee, failed channels, and later partner inbound come from the selected SaaS Club interview with Rodney Robinson. The claims are founder-reported. No public source supplies the customer ledger, contract values, conversion denominator, CAC, gross margin, churn, or partner-attributed account count.

TabaPay's 2026 company account reports a $100 billion annualised payment-volume run rate and more than 670 million 2025 transactions. Those are company-reported current metrics, not proof of the first-ten funnel. An Inc. profile corroborates the 2017 founding year, and Nilson Report issue 1260 contains the independent 2023 US merchant-acquirer ranking. Neither source verifies early acquisition attribution.

The interview conflicts on time to first revenue and alternates between $100 million in revenue and ARR language. This course does not use a precise first-revenue timeline or audited ARR claim. It also keeps the first 10 warm accounts, later partner referrals, and current scale as separate stages rather than presenting them as one measured funnel.