Cutting the free tier from 10K to 1K API calls tripled paid conversion without losing signups
A product-led growth experiment testing free tier limits on a developer API platform. Reducing the free tier from 10,000 to 1,000 monthly API calls tripled paid conversion rate from 2.8% to 8.4% while signup volume remained flat, revealing that generous free tiers were subsidizing production workloads that had no financial pressure to upgrade.
The Experiment
Upstash, a serverless data platform offering Redis and Kafka as managed services, ran a controlled pricing experiment over 90 days to test whether reducing the free tier API call limit would increase paid conversion without damaging signup volume or developer sentiment. The experiment challenged a deeply held assumption in developer tool marketing: that generous free tiers always lead to better growth outcomes.
The Original Free Tier
Before the experiment, Upstash's free tier included:
- 10,000 API calls per day (approximately 300,000 per month)
- 256 MB storage
- Single region
- Community support
- No credit card required
This was a generous free tier by industry standards. Most competitive Redis providers offered either no free tier or significantly lower limits. The generosity was intentional — the founding hypothesis was that developers would adopt Upstash for side projects, fall in love with the DX, and upgrade when they brought it to production workloads.
The Problem
After 18 months of operating with this free tier, the data told a different story. The funnel looked like this:
| Metric | Value |
|---|---|
| Monthly new signups | ~3,200 |
| Signups who make first API call within 7 days | 68% (~2,176) |
| Users still active at day 30 | 41% (~1,312) |
| Users who convert to paid within 90 days | 2.8% (~90) |
| Average free tier usage at day 30 | 2,100 daily calls |
The 2.8% paid conversion rate was the problem. The team had expected that a generous free tier would drive higher conversion through product love. Instead, the data suggested that 10,000 daily API calls was more than enough for most production workloads at the scale of Upstash's typical user. Developers were running real applications — not just side projects — entirely within the free tier because the limits were high enough to accommodate production traffic.
The Hypothesis
If we reduce the free tier API call limit from 10,000 to 1,000 daily calls, we expect:
- Paid conversion rate will increase significantly (target: 2x baseline) because production workloads currently on the free tier will hit the limit and need to upgrade
- Signup volume will remain within 10% of baseline because the free tier still exists and the lower limit is still sufficient for evaluation and side projects
- Developer sentiment will initially dip but stabilize within 30 days as the new limits become the norm
- 30-day activation rate (first API call) will be unaffected because 1,000 daily calls is more than enough for initial evaluation
The hypothesis was grounded in a specific insight from usage data analysis: 72% of free tier users never exceeded 1,000 daily API calls. The 10,000-call limit was only used by the 28% of free tier users who had crossed into production territory — exactly the users who should be on a paid plan.
The Setup
Cohort Design
The experiment used a time-based cohort design rather than a random split. New signups during the first 45 days continued to receive the 10,000-call free tier (control cohort). New signups during the second 45 days received the 1,000-call free tier (experiment cohort). Both cohorts were tracked for 90 days from their signup date.
A time-based design was chosen over a random split for two reasons: first, having two different free tier limits simultaneously would create confusion in documentation, marketing, and community discussions. Second, the pricing page could only show one set of limits at a time.
Existing free tier users were not affected — only new signups.
What Changed
| Parameter | Control (original) | Experiment (new) |
|---|---|---|
| Daily API calls | 10,000 | 1,000 |
| Storage | 256 MB | 256 MB (unchanged) |
| Regions | 1 | 1 (unchanged) |
| Credit card | Not required | Not required (unchanged) |
| Paid tier starting price | $0.20 per 100K calls | $0.20 per 100K calls (unchanged) |
Only the API call limit changed. Everything else — pricing page design, signup flow, onboarding experience, documentation — remained identical between cohorts.
Metrics Tracked
- Signup volume — Weekly new signups (primary guardrail metric)
- 7-day activation rate — Percentage of signups making first API call within 7 days
- 30-day retention — Percentage still active at day 30
- Paid conversion (90-day) — Percentage converting to paid within 90 days (primary outcome metric)
- Revenue per signup — Average revenue generated per signup within 90 days
- Community sentiment — Qualitative tracking of Twitter/X mentions, Discord feedback, and Reddit comments about the pricing change
Results
Quantitative Results
| Metric | Control (10K limit) | Experiment (1K limit) | Change |
|---|---|---|---|
| Weekly signups | 802 avg | 788 avg | -1.7% |
| 7-day activation rate | 68% | 66% | -2.9% |
| 30-day retention | 41% | 39% | -4.9% |
| 90-day paid conversion | 2.8% | 8.4% | +200% |
| Revenue per signup (90-day) | $1.12 | $4.87 | +335% |
| Monthly free tier cost to Upstash | ~$18K infrastructure | ~$3.2K infrastructure | -82% |
The results exceeded every target in the hypothesis:
Signup volume was flat (-1.7%, well within the 10% guardrail). The reduced free tier did not meaningfully deter new signups. This confirmed that developers sign up to evaluate a product — and 1,000 daily API calls is more than enough to build a proof of concept, run a tutorial, or test an integration.
Paid conversion tripled from 2.8% to 8.4%. The 1,000-call limit created a natural upgrade trigger: developers who built something worth running in production hit the limit within 2-4 weeks and faced a clear decision — pay $0.20 per 100K additional calls (a trivial cost for a production workload) or migrate to a different provider (significant effort).
Revenue per signup increased 4.3x from $1.12 to $4.87. This is the metric that matters most for PLG unit economics. Each new signup became 4.3x more valuable.
Infrastructure cost for free tier users dropped 82%. This was an unexpected but significant secondary benefit. The generous free tier had been subsidizing production workloads at meaningful infrastructure cost.
Qualitative Results: Developer Sentiment
The pricing change generated 23 public mentions across Twitter/X, Reddit, and Discord in the first two weeks.
Negative reactions (8 mentions): Developers who were running production workloads on the free tier expressed frustration. The most common complaint was "I chose Upstash because the free tier was generous enough for my use case." These were users who had adopted the product but were extracting production value without paying — exactly the segment the experiment targeted.
Neutral reactions (11 mentions): Developers who acknowledged the change without strong feelings. Several noted that 1,000 daily calls was still generous for evaluation. One r/selfhosted comment: "1K calls/day for free is still fine for testing. If you're doing more than that, you're running a real app and should probably pay."
Positive reactions (4 mentions): Surprisingly, some developers reacted positively, viewing the change as a sign of business sustainability. A Twitter/X thread from a developer with 12K followers noted: "Good. I'd rather Upstash charge for production use and stay alive than give everything away and shut down in 18 months."
The sentiment distribution — 35% negative, 48% neutral, 17% positive — stabilized within three weeks. By week four, the new limits were the accepted norm and pricing discussions disappeared from community channels.
Why 1,000 Was the Right Number
The 1,000 daily call limit was not arbitrary. It was derived from usage data analysis that identified a natural breakpoint in the user behavior distribution.
When the team plotted daily API calls per user as a histogram, two clear clusters emerged: evaluators (users making 10-500 calls per day, exploring the product or running side projects) and production users (users making 2,000-8,000 calls per day, running real applications). Very few users fell in the 500-2,000 range — it was bimodal.
Setting the limit at 1,000 captured the entire evaluation cluster within the free tier while nudging the entire production cluster toward paid. A limit of 5,000 would have left too many production users on the free tier. A limit of 500 would have caught some legitimate evaluators and potentially depressed activation rates.
What We'd Test Next
Usage-based nudges before hitting the limit
Instead of a hard cutoff at 1,000 calls, test a progressive notification system: "You've used 80% of your free tier this month. Upgrade to pay-as-you-go to avoid rate limiting." This gives developers time to anticipate the upgrade and budget for it, reducing the friction of an unexpected limit.
Annual commit discounts
For developers who convert from free to paid, test offering a 20% discount on annual commits during the first 48 hours after hitting the free tier limit. This is the moment of highest conversion intent — the developer has just confirmed that their usage exceeds the free tier and is actively making a spending decision.
Free tier with time limit instead of usage limit
An alternative model: unlimited API calls for 14 days, then paid. This removes the evaluation anxiety entirely ("can I build a meaningful proof of concept within these limits?") and replaces it with a time deadline. Some developer tools report higher activation rates with time-limited trials than usage-limited free tiers.
FAQ
Won't reducing the free tier hurt word-of-mouth growth?
Not if the free tier remains genuinely useful for evaluation. Word-of-mouth in developer tools is driven by product quality and developer experience, not by free tier generosity. Developers recommend tools because they work well, not because they're free. A developer who evaluates your product within a 1,000-call free tier and upgrades to paid is just as likely to recommend it as one who uses it for free forever — arguably more so, because paying customers are more invested.
How do you handle existing free tier users when you reduce limits?
Grandfather existing users on the old limits for a defined transition period — 90 days is standard. This gives them time to evaluate their usage and decide whether to upgrade or adjust. Forcing an immediate limit reduction on existing users generates justified backlash and can trigger churn of users who would have eventually converted to paid.
Is there a free tier limit that's too low and actually hurts signups?
Yes. If the free tier is so restricted that developers can't complete a meaningful evaluation — building a proof of concept, running a tutorial, or integrating with their stack — signups will drop because the free tier offers no value. The threshold varies by product, but the principle is consistent: the free tier must support genuine evaluation. For an API product, that means enough calls to build and test an integration. For a database, that means enough storage and connections to run a real schema.