Start With Small Customers or Big Ones? Paystack's First 300 Conversations
Short answer: Start with smaller customers when they feel the problem urgently, can decide within days and let you observe the complete workflow. Move towards larger customers only after the product works reliably and three early cohorts expand without founder rescue. Start big instead when integration or compliance costs make small accounts uneconomic and one committed buyer can fund the learning.
Large customers offer bigger contracts, but they can hide whether the product works. A founder may spend six months satisfying one procurement process and learn little about repeatable demand.
Small customers accelerate feedback, but hundreds of low-value accounts can overwhelm support. The best starting segment maximises useful learning per pound and founder hour.
What Paystack's early merchants reveal
At Paystack's late-2015 Y Combinator interview, co-founder Shola Akinlade said the company had processed about US$200 that month. Paystack's 2016 review records its first stable customers in February and later milestones of 1,661 customers and NGN 162,872,534 in transaction volume.
Akinlade later said he spoke directly with roughly the first 300 customers or peers. A Y Combinator founder interview describes the company learning with merchants before moving deeper into the market. Paystack also reported that its first-quarter 2016 cohort was processing at least 30 times its original volume by the fourth quarter of 2017.
The public record does not settle active versus registered merchants, the period covered by the 2016 transaction figure, take rate, fraud loss or founder support time. Transaction volume is not revenue.
My view is that founders overvalue contract size and undervalue iteration speed. Your first customer should make the truth visible quickly. Unless small accounts have structurally negative economics, begin where decisions and usage happen fast, then earn the right to move upmarket.
Use the Small-Customer Learning Ladder
The Small-Customer Learning Ladder has four rungs. Climb only when the previous rung produces measurable evidence.
| Rung | Customer purpose | Evidence required | |---|---|---| | 1. Access | Observe the real workflow | Ten completed customer conversations | | 2. Reliability | Find failure points under live use | Five customers completing the core job twice | | 3. Economics | Prove service can contribute | Positive contribution after support and loss | | 4. Expansion | Show customers grow or refer | Three accounts increase usage or introduce peers |
The numbers are working guides for a low-cost B2B product. A complex enterprise system may need fewer, deeper pilots. Define your ladder before selling so one prestigious logo does not change the rules.
Compare learning velocity, not company size
For each candidate segment, estimate days from first contact to live use, founder hours to onboard, number of workflow repetitions in 30 days and contribution after direct service cost.
An owner-operated merchant who integrates this week may reveal more than a large company with a nine-month procurement cycle. Conversely, if every small merchant needs six hours of technical help and produces £8 contribution, their fast decisions create expensive learning.
The guide on [identifying your first profitable customer segment](/market-research/first-profitable-customer-segment/) shows how to combine need, reachability and economics rather than choosing on market size alone.
Turn conversations into a reliability backlog
Founder conversations should investigate real attempts. Ask what the customer tried to do, which step failed, the commercial consequence and what they did next. Tag every issue by frequency, severity and whether it blocks the core outcome.
Do not promise every requested feature. Fix repeated failure points that prevent payment, delivery or trust. Publish no invented reliability percentage. Calculate success from your own event and transaction records using a documented denominator.
For payments and other financial workflows, track attempted, successful, failed, reversed and disputed transactions separately. Volume without success and loss data can flatter the product.
Price support and risk by segment
Customer contribution is revenue less variable infrastructure, payment costs, support, onboarding, refunds, fraud losses and any transaction-linked partner fees. Founder time needs a replacement cost.
Larger customers may contribute more but demand account management, bespoke integration, security review and longer payment terms. Small customers may be self-serve but create fragmented support. Compare a cohort of each over the same period.
Payments, safeguarding, anti-money-laundering, data, tax and consumer rules vary by country and business model. You may need authorisation or regulated partners, and liability cannot be guessed from another founder's story. Obtain qualified local legal, compliance and tax advice before live activity.
Worked example: RiverPay
RiverPay is choosing between micro-retailers and national chains. These figures are illustrative.
Twenty micro-retailers each process £2,500 monthly. RiverPay earns 0.7% net revenue after payment-network fees, giving 20 x £2,500 x 0.7% = £350. Onboarding and support average two hours per merchant at £24, or £960 in the first month. Infrastructure and loss cost another £120, so the cohort loses £350 - £960 - £120 = £730 initially.
In month two, volume reaches £3,000 per merchant, revenue is £420, support costs £240 and infrastructure plus loss remains £120, leaving £60. By month three, support falls to 20 minutes per account and volume rises 40% from the starting point. Monthly revenue becomes 20 x £3,500 x 0.7% = £490. Support costs 6.67 hours x £24 = £160, and infrastructure plus loss is £120. Contribution is £210. First-quarter contribution is therefore -£730 + £60 + £210 = -£460.
A chain offers 60 sites processing £900,000 monthly, worth £900,000 x 0.45% = £4,050 net revenue. It requires £18,000 of integration, security and procurement work before launch.
| Segment | Time to live | First-quarter contribution | Workflow repetitions | |---|---:|---:|---:| | 20 micro-retailers | 10 days | negative £460 | 20 independent settings | | One chain | 150 days | negative £18,000 before use | One central integration |
RiverPay starts with small merchants, not because they are more lucrative immediately, but because they create 20 reliability observations within ten days. It sets a move-upmarket gate: 98.5% internally measured transaction success for eight weeks, support below 25 minutes per active merchant monthly, and three merchants doubling volume.
When those conditions hold, the chain integration becomes less speculative. The £460 cohort loss has bought bounded operating evidence, not necessarily funded the whole company.
Recognise the move-upmarket signal
Move when the core workflow is stable, support per account is falling, early customers are expanding and larger prospects request a consistent set of controls. Do not move because a large logo asks for a roadmap unrelated to the core.
Ask large prospects to pay for discovery or a pilot when substantial custom work is required. Their commitment distinguishes an actual buying process from innovation theatre.
Run the ladder for eight weeks
In week one, compare two segments on decision time, onboarding, repetition and expected contribution. Interview ten people in the faster-learning segment by week two. Put five into live, paid use by week four where lawful and safe.
For the remaining month, log failures, support, usage and contribution. On day 56, choose whether to repeat the cohort, repair a structural cost or test one larger account. Preserve the same reliability definitions as you move, so higher volume cannot hide worse outcomes.
Related guides
Frequently asked questions
Are small customers always easier to sell to?
No. They often have shorter approval chains, but they may be time-poor, price-sensitive and difficult to reach efficiently. A large organisation can have a defined budget and urgent mandate even when procurement is slow. Measure actual days and founder hours from qualified contact to live use for each segment. Do not infer ease from headcount. The best first segment combines urgency, access and repeated use. If small prospects require individual education about the problem, a concentrated larger segment may generate learning more efficiently.
When do small customers become a distraction?
They become a distraction when support and acquisition consume more contribution than their usage, while their feedback no longer improves the product for the intended market. Calculate contribution by cohort and tag feature requests by target segment. A small account can still be valuable if it grows, refers peers or exposes a core reliability issue. Set a service boundary and a review date. If accounts remain loss-making after onboarding should have stabilised, raise the price, reduce service, improve self-service or stop targeting that segment.
Should I charge early small customers the final price?
Charge a real price, but it need not be final. A paid pilot can reflect limited capability and additional access to the founders. State its duration, scope and later pricing route clearly. Free use can attract people with weak urgency and make support demand difficult to interpret. If you discount, record the undiscounted price and ask for a defined commitment such as live data, weekly use or feedback sessions. Pricing, renewal and consumer rules vary by jurisdiction, so check local requirements and obtain qualified advice.
How should I use the first 300 conversations?
Do not treat 300 as a target. Use every conversation to update a structured record: trigger, current method, failure, cost, buyer, integration, outcome and next action. Stop asking a question once behaviour has become predictable, then investigate the next uncertainty. A smaller number of observed live workflows can be worth more than hundreds of general interviews. The conversation programme should shrink as instrumentation and support records improve. Its purpose is to make decisions, not to create a founder mythology around personal customer contact.
What proves that I am ready for larger customers?
Require stable core outcomes, falling support per account, documented security and operations, and a repeated need from larger prospects. At least three early accounts should expand usage, retain or refer without unusual founder effort. Build the controls that multiple larger buyers require, not a bespoke list from one. Also model longer payment terms and account-management cost. Readiness is not just product maturity; it includes contracting, incident response and cash. Enterprise obligations vary, so have qualified advisers review material commitments before signing.
Can a big first customer damage the product?
Yes. A large buyer can fund development but pull the roadmap towards one organisation's process, create revenue concentration and delay learning from the wider market. Protect the business with a paid, time-limited scope, change control and a clear statement of what remains standard. Track the proportion of revenue and engineering capacity tied to the account. The customer can be an excellent first partner when its problem represents the intended segment and it accepts shared product boundaries. Size itself is neither validation nor danger.
Comments (0)