How I Designed a Freemium API Plan Developers Actually Want to Pay For

The Painful Origin Story

Two years ago, I launched a BIN lookup API with pricing that looked good on a spreadsheet and failed everywhere else.

The model was simple: free tier with 100 requests per month, Pro tier at $29/month with 10,000 requests, and Enterprise at custom pricing. I assumed the progression made sense. Users would try the free tier, hit the limit quickly, and upgrade.

What actually happened: the free tier was so constrained that serious developers never bothered onboarding. The jump to $29/month felt arbitrary to the 20-person startups using my API in non-critical flows. And the Enterprise tier collected inquiries from big companies who then negotiated us down by 40% and asked for custom integrations.

After 6 months: 40 signups, 3 paying customers, 1 angry customer who felt overcharged.

I was pricing for growth that did not exist because I had never talked to the people I was trying to sell to.

TL;DR: What I Learned (and Changed)

If you are pricing a developer API, these four lessons will save you the same six months I wasted:

1. Free tier is your onboarding tool, not your product. Make it viable for real prototyping, not a tease that only lets developers test with five requests. The free tier should answer the question: "Does this API solve my problem?" It should not answer: "Can I build my whole company on this free tier?"

2. Pricing boundaries should match real developer workflows, not arbitrary request counts. A startup that runs 10,000 lookups per month is not the same as one running 100,000 per month. The actual pain point surfaces at different scales, and your tier breakpoints should acknowledge that.

3. Transparent per-minute rate limits matter more than monthly quotas. Developers care about burst capacity. Can they run a batch job without getting rate-limited to death? Can their application handle a traffic spike? These questions drive upgrades, not hitting a monthly wall three weeks into the month.

4. Talk to users before you finalize anything. I made pricing decisions in isolation. Every conversation I had with an actual developer after launch revealed something I had missed. Start there, not with spreadsheet assumptions.

Where Most API Pricing Goes Wrong

I see the same mistakes repeatedly in other API products, and I made most of them.

Mistake 1: Assuming free users will convert to paid.

The conversion funnel is not linear. A developer using 50 free API requests per month will never become a $50/month customer because they do not need it. They will either leave or stay on free forever. The free tier should be designed for developers who will eventually need 5,000+ monthly requests, not everyone.

This means asking: what is the smallest viable dataset or transaction volume where a serious developer says, "I need more than free"? For a BIN lookup API, that threshold is somewhere around 1,000 lookups per month. That is enough for a developer to validate that the API works, integrate it into a prototype, and realize they need it in production. It is not enough to run a production system for even a small company.

Mistake 2: Setting rate limits that punish normal usage patterns.

If your Pro plan offers 100,000 requests per month but limits users to 10 requests per minute, you have created a perverse situation. A developer with a legitimate batch job fails immediately, then cancels because they think your API is broken. They were not hitting the monthly limit; they were hitting a per-minute wall that made no sense.

Developers think in terms of per-second and per-minute throughput first, then monthly volume second. A rate limit of 200 requests per minute sounds boring on a pricing page, but it is the difference between "I can batch-process 1000 records in my evening job" and "my batch jobs time out constantly."

Mistake 3: Making Enterprise a mystery box.

When potential customers see "Enterprise: custom pricing," they assume three things: your product is expensive, negotiation is required, and you are hiding something. Even if your actual Enterprise terms are fair, the perception of opacity suppresses inquiries from large companies that would otherwise upgrade.

I now list baseline Enterprise numbers upfront (unlimited requests, custom rate limits, SLA guarantees, API keys). This signals that Enterprise is not a black box. Customers can decide if it is a conversation worth having.

How I Restructured the Tiers (and Why)

Here is the actual pricing model I moved to, and the reasoning behind each decision.

Free: 1,000 requests per month, 10 per minute

This is the new floor. 1,000 lookups is enough for:

• A developer to run integration tests against real data (not mocks)
• A small app to do a few lookups per day for a week
• A prototype to determine if the API solves the problem

The per-minute limit is high enough that normal API usage never hits it. A developer calling the API once per second for 10 seconds does not fail. But a developer trying to batch-process 10,000 records hits a wall and knows they need to upgrade.

Why this works: it is not a tease. It is a real sandbox. And it is generous enough that the question "Should I even evaluate this product?" gets answered with "yes, definitely."

Conversion rate after moving to 1,000/month free tier: 8%.

Starter: 10,000 requests per month, 50 per minute, 3 API keys

This tier is for developers who have moved from prototype to MVP. They are building something real but it is not mission-critical yet.

10,000 requests per month is roughly:

• 300 lookups per day
• 10 lookups per hour during business hours
• Enough for a small fintech or fraud team running a few hundred transactions daily

The per-minute limit of 50 is high enough that batch processing within the month is never throttled. The 3 API keys let a developer keep their test environment separate from production without hitting key limits.

The price: $25/month. This is not $29/month; it is not $19/month. It is $25/month, which is memorable and sits at the psychological boundary where a small team says "yes, that is worth it."

Conversion rate after adding this tier: 14%.

Pro: 100,000 requests per month, 200 per minute, 15 API keys

This is where it gets interesting. Pro is for teams that are treating your API as part of their infrastructure.

100,000 requests per month is:

• 3,300 lookups per day
• Enough for a fraud team running thousands of transactions daily
• Enough for a payment processor doing lookups for their entire merchant base

The per-minute limit of 200 lets a developer run batch jobs that process 12,000 records per hour without throttling. That is a serious operational capability. The 15 API keys let them organize by team, environment, and use case without burning key limits.

The price: $99/month. This price point exists for a specific reason. It is below $100, which makes it a different budget category for most small companies. It is 4x the Starter price, which is roughly the request ratio. This pricing was not arbitrary; it came from conversations with 15 developers who said, "I would pay $99 to not think about API keys and rate limits."

Conversion rate after launching Pro: 22%.

Enterprise: Unlimited requests, custom rate limits, 190 API keys, SLA

Enterprise is transparent. No custom pricing, no mystery. If you need more than 100,000 requests per month, you contact sales and get a quote. The baseline is unlimited requests, fully customizable rate limits, an SLA, and priority support.

I do not advertise the Enterprise price publicly because it depends on volume and contract terms. But I do publish that Enterprise exists and what it includes. This removes the mystery.

Conversion rate for Enterprise inquiries: 65%.

The Shifts That Actually Moved the Needle

Looking back, three changes mattered far more than pricing tweaks.

Change 1: I Made the Free Tier Actually Usable

The original 100 request free tier was a non-starter. After moving to 1,000, onboarding increased 5x immediately. Developers stopped bouncing off the free tier within a day.

The reason is simple: 1,000 requests is enough to have a real conversation with the API. You run test calls, validate the response shape, check that the data is actually useful. 100 requests is enough to read the docs, run one test, and leave.

This change cost nothing to implement. It just required removing the assumption that "free users are not real customers" and asking instead, "What do free users need to even evaluate this product?"

Change 2: I Published Per-Minute Rate Limits Prominently

The original pricing page buried rate limits in a footnote. I moved them to the main tier comparison table.

The result: developers could immediately see if a tier met their needs. Instead of buying Pro and then complaining about rate limiting, they could make an informed decision. Some developers who thought they needed Enterprise realized Starter was enough. Others realized they needed Pro from the start.

Publishing rate limits also signaled that I understood how developers actually use APIs. It built credibility.

Change 3: I Talked to Users Before Launching Changes

Before restructuring tiers, I ran 20 conversations with developers and payment companies using the API. I asked:

• At what volume does free become insufficient?
• Do rate limits or monthly quotas matter more?
• What does the jump from free to paid look like at your company?

The answers were consistent and contradicted my original assumptions. Free needed to be 10x larger. Rate limits mattered more than I thought. And pricing at $25 for Starter instead of $29 was not a cost difference; it was a perception difference.

I incorporated every answer into the restructured tiers. This is why conversion rates improved so dramatically. I was not guessing anymore.

The Real Numbers

Here are the numbers that convinced me the restructure worked.

Before (original tiers):

• Signups per month: 7
• Paying customers per month: 0.4 (sometimes a team converts, sometimes they do not)
• MRR: $100-200
• Churn: 40% per month

After (new tiers):

• Signups per month: 85
• Paying customers per month: 12
• MRR: $1,800 (Starter + Pro + Enterprise combined)
• Churn: 8% per month

This was not a magic traction inflection. But it was proof that the pricing was no longer the barrier to entry.

The mix broke down roughly as:

• Free tier: 73 of 85 signups (86%)
• Starter: 8 of 12 conversions (67% of paying)
• Pro: 3 of 12 conversions (25% of paying)
• Enterprise: 1 of 12 conversions (8% of paying)

This is important. The Starter tier, not Pro, was where most conversion happened. This contradicted my assumption that developers would skip straight to Pro. Instead, many teams started with Starter, ran into limits within 3-6 months, and upgraded. That is the healthy funnel I was trying to build.

What Developers Actually Care About (Ranked)

After this relaunch and dozens of conversations, here is what drove decisions, in order:

1. Can I try this without a credit card? Free tier with a real quota (not 50 requests) matters. Most signups come from free users who eventually convert.

2. Is the per-minute rate limit documented? Burst capacity is the question developers are asking. Monthly quotas are secondary.

3. Are the price jumps between tiers predictable? Developers do not want to be surprised. 4x the volume for 4x the price is fair. 2x the volume for 10x the price is a scam.

4. Can I have more than one API key? This signals that the product scales with the developer. A single API key for production and test is a red flag.

5. What is the minimum commitment period? Most developers want month-to-month, not annual. Annual plans were a conversation-killer.

Pricing, interestingly, was number 7 on the list. Transparency, fairness, and usability ranked higher than cost.

The Live Example

I use this exact pricing model on BinSearchLookup, which is a BIN lookup API for payment developers. The free tier (1,000/month, 10/min) brings in most signups. Starter (10,000/month, 50/min) is where conversion happens. Pro and Enterprise are healthy but smaller.

The model works because it is designed around how developers actually work, not around what a spreadsheet says is logical.

The Mistakes I Still Make

Pricing is not a set-and-forget problem. I still mess this up regularly.

Mistake I still make: Assuming a feature is worth a tier upgrade.

Last year I added batch BIN processing to Pro and expected a shift in conversions. It did not happen. Developers did not care about the feature enough to upgrade. I learned that feature additions do not drive tier upgrades; hitting quota does.

Mistake I still make: Not talking to churn customers.

When a customer downgraded from Pro to Starter, I did not reach out. In retrospect, I should have. They probably hit a workflow that broke at Starter limits, or a rate limit surprised them. I could have fixed the issue instead of losing them.

Mistake I still make: Treating Enterprise as a separate business.

I still assume Enterprise customers want "custom" everything. Many of them just want transparent terms and a handshake. A faster path to Enterprise without a 30-minute sales call would probably convert more.

Takeaways for Your API

If you are pricing a developer API, here is the short version:

1. Make free tier viable for real work, not just onboarding.
2. Publish rate limits as prominently as pricing.
3. Price tiers should reflect real usage patterns, not arbitrary request counts.
4. Ask developers what they care about instead of assuming.
5. Build the free-to-Starter funnel first. That is where most conversions happen.

The best part of this restructure was not the revenue increase. It was the shift in how developers talked about the product. Instead of "I wanted to evaluate this but the free tier was too limited," they said "I evaluated this for free, it solved my problem, and now I pay for it."

That is the only pricing metric that matters.