DEV Community

Amar Kovacevic
Amar Kovacevic

Posted on • Originally published at databaselists.com

We Killed ZoomInfo-Style Pricing and Built Pay-Per-Search Business Data Instead. Here Is the Math

The standard B2B SaaS playbook says: charge a monthly subscription, lock in LTV, optimize for retention. ZoomInfo did this and became a $14B company. Apollo, Lusha, Cognism all followed.

When we built DatabaseLists — natural-language AI search for business leads — we tried the same playbook. $99/mo, $299/mo, $999/mo. It bombed. Conversion was 0.4%. We almost shut it down.

Then we tried something the playbook says not to do: kill subscriptions entirely, charge per search. Conversion went to 7.8%. LTV dropped, but volume went up so much that revenue tripled in three months.

Here is the math, the counter-intuitive lesson, and why this only works in specific markets.

The frequency problem

The fundamental issue with subscription pricing for lead-gen tools is frequency mismatch.

A salesperson at a tech company might pull lead lists daily — fine, $99/mo is cheap.

But the actual SMB market — the consultant, the agency, the local SaaS, the marketing freelancer — they need leads in bursts. Three days a month, maybe. Then nothing for six weeks until the next campaign.

For these users, $99/mo means they're paying $33/search for the 3 searches they actually run. Their brain does that math and unsubscribes within the first month.

We were burning cash on Stripe fees and a churn-funnel of users who never got value before they bailed.

What pay-per-search actually looks like

$0.10 per search, 10 free searches on signup
Top-up packs: $5 (50), $25 (300), $50 (700), $200 (3,500)
No subscription. Credits never expire.
Enter fullscreen mode Exit fullscreen mode

What changed in user behavior, measured over the first 90 days:

Metric Subscription model Pay-per-search
Signup → first search 38% 91%
Conversion to paid 0.4% 7.8%
Avg revenue per paying user $204 $34
Refund/chargeback rate 8.1% 0.3%
Word-of-mouth signups 4% 23%
Net revenue / month 1.0x 3.1x

The headline: ARPU dropped 6x. Total revenue tripled.

Why this is counter-intuitive

The SaaS playbook is built on LTV math: acquire customers, lock them in, milk LTV. CAC payback periods of 9–18 months are normal.

But that math assumes:

  1. The product has frequent enough use that monthly billing feels worth it
  2. Users have budget authority to commit to a recurring expense
  3. Switching costs are high enough to prevent churn

For SMB lead-gen, all three of those are false:

  1. Use is bursty, not constant
  2. The user IS the budget owner, and a $99 recurring charge is a real psychological cost
  3. Switching is trivial — they can just go to Google Maps + Hunter.io

When the playbook assumptions break, the playbook breaks. Pay-per-search restores the value-pricing alignment: you pay for what you get, when you get it.

The chargeback effect we didn't expect

The 8.1% chargeback rate on subscriptions was killing us. Most weren't fraud — they were "I forgot I subscribed and just noticed on my Amex statement six months later" disputes. Stripe sided with the customer ~70% of the time, and the chargeback fees themselves cost us $15 per dispute on top of the refund.

Pay-per-search chargebacks dropped to 0.3% because:

  • The charge is tied to an action they took today
  • The amount is small enough not to flag on bank statements
  • The credits never expire, so there's no "I'm not using it anymore" frustration

This effect alone added ~$2,800/mo in retained revenue. We didn't model it. It was a surprise.

The word-of-mouth multiplier

Pay-per-search turned out to be inherently shareable in a way subscriptions aren't.

"Hey, try this thing, you get 10 free searches" is a sentence a user will actually send to a colleague. "Hey, try this thing, you'll need to pay $99/mo" is not.

23% of new signups came from explicit referrals in the pay-per-search era, vs 4% during the subscription era. We didn't change the referral program — the product structure did the work.

When this DOESN'T work

I want to be careful here — pay-per-search worked for us because of specific market conditions. It would have been a disaster in other contexts:

Don't do pay-per-use if:

  • Your product has high daily engagement (e.g. Slack, Notion). Subscription captures more value here.
  • Your fixed costs per user are high (e.g. you provision dedicated compute). You need predictable revenue.
  • Your CAC is over $300. You need the LTV math to work.
  • Your competitors are entrenched on subscriptions and have switching costs locked in. You'll need to differentiate on something other than pricing.

Do consider pay-per-use if:

  • Use is bursty (lead gen, image generation, transcription, data pulls)
  • Your user is the budget owner (solo, SMB, freelancer)
  • The unit of value is clearly countable (1 search, 1 image, 1 minute of audio)
  • Your variable cost per call is low enough that small per-unit prices still make margin

The unexpected upside: better data

The other thing that happened — users started using us in new ways we hadn't designed for.

A real estate agent in Dubai ran 240 searches in one weekend, scoping a market entry. Under subscription pricing, he never would have signed up. Under pay-per-search, he spent $24 and gave us a feature request list that led to our entire UAE expansion.

When pricing aligns with usage moments, you learn what users actually want to do — not what they're rationing themselves to within a monthly cap.

The Stripe implementation

Practical note for builders: pay-per-use is harder to implement than subscriptions. You need:

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  payment_method_types: ['card'],
  line_items: [{ price: 'price_credit_pack_300', quantity: 1 }],
  metadata: { user_id: userId, credits: '300' },
});
Enter fullscreen mode Exit fullscreen mode

Two gotchas:

  1. Webhooks must be idempotent. Stripe retries on 5xx. Use the event ID as a uniqueness key on credit increments.
  2. Credit balance must be transactional. Use a row lock on the user when decrementing, or you'll oversell credits to concurrent searches.

TL;DR

Subscriptions are the default SaaS pricing model because they work for ~70% of products. For the other 30% — bursty-usage tools serving budget-owning SMBs — pay-per-use is structurally better. Lower ARPU, higher conversion, lower churn, higher referral rate. Run the math on your own market before defaulting to monthly.

If you want to see pay-per-search in action: 10 free searches at DatabaseLists. Type "Italian restaurants in Dubai with 4+ stars". The data is real.

Top comments (0)