463 lines
14 KiB
Markdown
463 lines
14 KiB
Markdown
---
|
|
name: free-tier-strategy
|
|
description: "Design free tiers that convert to paid without creating resentment or abuse. Trigger phrases: free tier design, freemium model, free trial strategy, free tier limits, developer free plan, open source commercial, feature gating, upgrade triggers, free tier conversion"
|
|
risk: unknown
|
|
source: https://github.com/jonathimer/devmarketing-skills/tree/main/skills/free-tier-strategy
|
|
source_repo: jonathimer/devmarketing-skills
|
|
source_type: community
|
|
date_added: 2026-07-01
|
|
license: MIT
|
|
license_source: https://github.com/jonathimer/devmarketing-skills/blob/main/LICENSE
|
|
---
|
|
|
|
# Free Tier Strategy
|
|
## When to Use
|
|
|
|
Use this skill when you need design free tiers that convert to paid without creating resentment or abuse. Trigger phrases: free tier design, freemium model, free trial strategy, free tier limits, developer free plan, open source commercial, feature gating, upgrade triggers, free tier conversion.
|
|
|
|
|
|
Design free tiers that let developers build real things, demonstrate value, and convert naturally—without feeling like a trap or creating resentment.
|
|
|
|
## Overview
|
|
|
|
Developer tools need free tiers. Developers expect to try before they buy, and they expect the trial to be meaningful—not a 14-day timer or a feature-locked demo. But free tiers also need to sustain your business. Get this wrong in either direction: too restrictive kills adoption, too generous kills revenue.
|
|
|
|
The best free tiers feel generous to individual developers while naturally scaling into paid tiers as projects grow.
|
|
|
|
## Before You Start
|
|
|
|
Review the `/devmarketing-skills/skills/developer-audience-context` skill. Free tier design varies significantly based on whether you're targeting hobbyists, startups, or enterprises. Also understand your unit economics—what does each free user actually cost you?
|
|
|
|
## Free Tier vs Free Trial vs Freemium
|
|
|
|
### Definitions
|
|
|
|
**Free trial:** Time-limited full access (14 or 30 days)
|
|
- Best for: High-touch enterprise sales
|
|
- Worst for: Developer tools with self-serve motion
|
|
|
|
**Free tier:** Permanently free with usage/feature limits
|
|
- Best for: Developer tools with self-serve adoption
|
|
- Requires: Careful limit design
|
|
|
|
**Freemium:** Free tier plus premium features for payment
|
|
- Best for: Tools with clear hobby/pro distinction
|
|
- Requires: Obvious value in premium features
|
|
|
|
**Open core:** Free open source with commercial additions
|
|
- Best for: Infrastructure and platforms
|
|
- Requires: Active open source community
|
|
|
|
### Choosing Your Model
|
|
|
|
| Factor | Free Trial | Free Tier | Freemium | Open Core |
|
|
|--------|-----------|-----------|----------|-----------|
|
|
| Sales motion | High-touch | Self-serve | Self-serve | Mixed |
|
|
| Time to evaluate | Weeks | Months | Months | Unlimited |
|
|
| Conversion pressure | High | Low | Medium | None |
|
|
| Community building | Low | Medium | Medium | High |
|
|
| Support costs | High | Low | Medium | Variable |
|
|
|
|
**Developer tools almost always need a permanent free tier, not a free trial.** Developers build side projects, evaluate tools for future use, and recommend tools to others—all of which require long-term free access.
|
|
|
|
## Usage Limits That Make Sense
|
|
|
|
### Good Limit Dimensions
|
|
|
|
**API calls/requests**
|
|
- Developers understand and can track
|
|
- Scales naturally with application growth
|
|
- Example: 10,000 requests/month
|
|
|
|
**Compute resources**
|
|
- Clear relationship to cost
|
|
- Predictable for developers
|
|
- Example: 500 build minutes/month
|
|
|
|
**Storage**
|
|
- Easy to understand
|
|
- Natural upgrade trigger as data grows
|
|
- Example: 1GB storage
|
|
|
|
**Seats/users**
|
|
- Makes sense for collaboration tools
|
|
- Natural upgrade for team growth
|
|
- Example: Up to 3 team members
|
|
|
|
### Bad Limit Dimensions
|
|
|
|
**Time-based trials disguised as free tiers**
|
|
- "Free tier expires after 90 days of inactivity"
|
|
- Creates anxiety and resentment
|
|
|
|
**Arbitrary feature combinations**
|
|
- "Free: 3 projects with 2 environments each, max 5 databases per environment, 100MB per database"
|
|
- Too complex to evaluate
|
|
|
|
**Limits that punish success**
|
|
- "Free up to 100 monthly active users"
|
|
- Your most successful free users hit limits fastest
|
|
|
|
### The Goldilocks Zone
|
|
|
|
Free tier limits should:
|
|
1. **Allow meaningful usage** - Build and run a real side project
|
|
2. **Cover hobbyist use cases** - Personal projects should never require payment
|
|
3. **Trigger on growth, not time** - Upgrades happen because projects succeed
|
|
4. **Be easy to predict** - Developers should know when they'll hit limits
|
|
|
|
### Example: Good Limit Structure
|
|
|
|
**Vercel:**
|
|
- Unlimited personal projects
|
|
- 100GB bandwidth/month
|
|
- Serverless function limits
|
|
- Hobby use stays free forever
|
|
|
|
**Supabase:**
|
|
- 500MB database storage
|
|
- 2GB bandwidth
|
|
- 50,000 monthly active users
|
|
- Social auth unlimited
|
|
|
|
**PlanetScale:**
|
|
- 1 database
|
|
- 1 billion row reads/month
|
|
- 10 million row writes/month
|
|
- 5GB storage
|
|
|
|
## Feature Gating Strategies
|
|
|
|
### The Free Features Principle
|
|
|
|
Free tiers should include everything needed to:
|
|
1. Evaluate the product thoroughly
|
|
2. Build and ship a real project
|
|
3. Operate in production at small scale
|
|
|
|
### Features to Keep Free
|
|
|
|
- Core functionality
|
|
- All integrations and SDKs
|
|
- Standard authentication
|
|
- Basic monitoring and logs
|
|
- Documentation and community support
|
|
- Development and testing environments
|
|
|
|
### Features to Gate Behind Paid Tiers
|
|
|
|
**Collaboration features:**
|
|
- Team members beyond the solo developer
|
|
- Access controls and permissions
|
|
- Audit logs
|
|
|
|
**Scale and performance:**
|
|
- Higher rate limits
|
|
- More compute/storage
|
|
- Premium infrastructure (dedicated instances)
|
|
|
|
**Enterprise requirements:**
|
|
- SSO/SAML
|
|
- SLAs and uptime guarantees
|
|
- Priority support
|
|
- Compliance certifications
|
|
- Custom contracts
|
|
|
|
### Feature Gating Anti-Patterns
|
|
|
|
**Gating basic developer needs:**
|
|
```
|
|
Bad: Custom domains require paid plan
|
|
(Custom domains are table stakes)
|
|
|
|
Bad: CI/CD integration requires paid plan
|
|
(This is how developers deploy)
|
|
|
|
Bad: Environment variables limited on free
|
|
(This is basic functionality)
|
|
```
|
|
|
|
**Gating that breaks evaluation:**
|
|
```
|
|
Bad: "Advanced features" available for 7 days then locked
|
|
(Developers can't properly evaluate)
|
|
|
|
Bad: Production deploys require credit card
|
|
(Can't demonstrate to stakeholders)
|
|
```
|
|
|
|
## Avoiding "Free Tier Tax" Resentment
|
|
|
|
### What Creates Resentment
|
|
|
|
1. **Hidden degradation** - Free tier is slower, less reliable
|
|
2. **Feature removal** - Features moved from free to paid
|
|
3. **Surprise limits** - Hitting limits without warning
|
|
4. **Contemptuous messaging** - "Upgrade to unlock BASIC features"
|
|
5. **Support discrimination** - Free users treated as second-class
|
|
|
|
### Creating Positive Free Tier Experience
|
|
|
|
**Clear expectations:**
|
|
```
|
|
Free tier includes:
|
|
- Everything you need to build and launch
|
|
- No credit card required
|
|
- No time limits
|
|
|
|
Upgrade when you need:
|
|
- Team collaboration
|
|
- Higher usage limits
|
|
- Priority support
|
|
```
|
|
|
|
**Graceful limit handling:**
|
|
```
|
|
You've used 8,000 of 10,000 free API calls this month.
|
|
|
|
Options:
|
|
- Wait for reset on March 1st
|
|
- Upgrade to Pro ($29/mo) for 100,000 calls
|
|
- Request temporary limit increase (for launches)
|
|
```
|
|
|
|
**Honest feature comparisons:**
|
|
Don't artificially cripple free tier to make paid look better.
|
|
|
|
### The GitHub Model
|
|
|
|
GitHub's free tier evolution shows how to do this well:
|
|
1. Free private repos (previously paid)
|
|
2. Free CI/CD minutes for public repos
|
|
3. Free Copilot for open source maintainers
|
|
4. Generous free tier for organizations
|
|
|
|
Result: Developers love GitHub, happily pay when they need more.
|
|
|
|
## Upgrade Triggers and Timing
|
|
|
|
### Natural Upgrade Triggers
|
|
|
|
**Growth triggers:**
|
|
- Hit usage limits (bandwidth, storage, API calls)
|
|
- Add team members
|
|
- Create more projects/environments
|
|
- Need more history/retention
|
|
|
|
**Maturity triggers:**
|
|
- Move to production
|
|
- Need uptime SLA
|
|
- Require compliance
|
|
- Want premium support
|
|
|
|
### Trigger Communication
|
|
|
|
**Bad: Nagging**
|
|
```
|
|
[Popup every login]
|
|
Upgrade to Pro! 50% off this week only!
|
|
[Dismiss] [Upgrade]
|
|
```
|
|
|
|
**Good: Contextual**
|
|
```
|
|
[When approaching limits]
|
|
You're at 85% of your free tier API calls.
|
|
Your current usage suggests you'll hit the limit in 3 days.
|
|
|
|
[View usage] [Explore plans]
|
|
```
|
|
|
|
**Better: Helpful**
|
|
```
|
|
[When adding 4th team member]
|
|
Free tier includes 3 team members.
|
|
|
|
To add more collaborators, upgrade to Team ($25/user/mo).
|
|
This includes: [benefits relevant to teams]
|
|
|
|
[Not now - stay with 3] [Upgrade to Team]
|
|
```
|
|
|
|
### Timing Principles
|
|
|
|
1. **Never interrupt workflow** - Don't block actions with upgrade prompts
|
|
2. **Warn before limits** - 70%, 85%, 95% notifications
|
|
3. **Explain the trigger** - "You're seeing this because..."
|
|
4. **Offer alternatives** - Not just "upgrade or suffer"
|
|
5. **Remember choices** - Don't repeat dismissed prompts daily
|
|
|
|
## Open Source + Commercial Models
|
|
|
|
### The Open Core Model
|
|
|
|
```
|
|
Open Source (MIT/Apache) Commercial
|
|
─────────────────────────────────────────────────
|
|
Self-hosted core Cloud hosting
|
|
Community support Priority support
|
|
Standard features Enterprise features (SSO, audit)
|
|
Compliance and SLAs
|
|
```
|
|
|
|
### Making Open Core Work
|
|
|
|
**Clear boundary:**
|
|
Developers should know exactly what's open source and what's commercial.
|
|
|
|
**Good example (GitLab):**
|
|
- Community Edition: Complete Git platform
|
|
- Enterprise Edition: Advanced security, compliance
|
|
- SaaS: Managed hosting with CE or EE features
|
|
|
|
**Open source must be useful:**
|
|
The open source version should be genuinely useful, not crippled. Developers will notice and resent "open-source-washing."
|
|
|
|
### Commercialization Strategies
|
|
|
|
**Cloud vs self-hosted:**
|
|
- Open source: Self-host for free
|
|
- Commercial: Managed cloud hosting
|
|
- Example: Plausible, Metabase, Supabase
|
|
|
|
**Enterprise features:**
|
|
- Open source: Complete for individual/small team
|
|
- Commercial: SSO, audit logs, compliance
|
|
- Example: GitLab, Sourcegraph
|
|
|
|
**Support and SLA:**
|
|
- Open source: Community support
|
|
- Commercial: Priority support, uptime SLA
|
|
- Example: Most open source databases
|
|
|
|
### Community Relationship
|
|
|
|
**Do:**
|
|
- Contribute genuinely to open source
|
|
- Accept community contributions
|
|
- Maintain transparency about commercial decisions
|
|
- Offer free commercial tier for open source projects
|
|
|
|
**Don't:**
|
|
- Relicense or change terms suddenly (see HashiCorp, Redis, Elastic)
|
|
- Compete with community-built features by commercializing them
|
|
- Use open source primarily as marketing
|
|
- Ignore community feedback on commercial boundaries
|
|
|
|
## Pricing Page Communication
|
|
|
|
### Show Limits Clearly
|
|
|
|
```
|
|
Free Pro ($29/mo) Enterprise
|
|
─────────────────────────────────────────────────────────
|
|
10,000 API calls 100,000 API calls Unlimited
|
|
1GB storage 50GB storage Unlimited
|
|
3 team members 25 team members Unlimited
|
|
Community support Email support Priority + SLA
|
|
```
|
|
|
|
### FAQ Free Tier Questions
|
|
|
|
Every pricing page needs:
|
|
- "Is the free tier actually free forever?"
|
|
- "What happens when I hit limits?"
|
|
- "Can I use free tier for commercial projects?"
|
|
- "Do I need a credit card for free tier?"
|
|
|
|
### Pricing Page Examples
|
|
|
|
**Excellent: Vercel**
|
|
- Clear free tier description
|
|
- Per-feature limit comparison
|
|
- Usage calculator
|
|
- "Hobby" framing (not "limited")
|
|
|
|
**Excellent: Supabase**
|
|
- Generous free tier prominent
|
|
- Clear limit numbers
|
|
- Feature comparison table
|
|
- Open source status visible
|
|
|
|
## Examples: Free Tiers That Work
|
|
|
|
### Stripe
|
|
|
|
- No monthly fee for free tier
|
|
- Pay only on transactions (2.9% + 30¢)
|
|
- Test mode unlimited and forever
|
|
- Full feature access
|
|
- Why it works: Aligns cost with revenue
|
|
|
|
### Cloudflare
|
|
|
|
- Generous free tier (unlimited bandwidth)
|
|
- Premium features clearly differentiated
|
|
- Free tier is genuinely useful for most sites
|
|
- Why it works: Free users become advocates
|
|
|
|
### MongoDB Atlas
|
|
|
|
- 512MB storage free forever
|
|
- Shared cluster (good enough for learning)
|
|
- All features available to test
|
|
- Why it works: Devs learn on free, companies pay
|
|
|
|
### Algolia
|
|
|
|
- 10,000 records free
|
|
- 10,000 search requests/month
|
|
- Full API access
|
|
- Why it works: Scales with application success
|
|
|
|
## Examples: Free Tier Problems
|
|
|
|
### Anti-Pattern: The Hidden Trial
|
|
|
|
"Free tier" that expires after 90 days of inactivity, or reduces limits after initial period.
|
|
|
|
### Anti-Pattern: The Feature Prison
|
|
|
|
Core features locked behind payment, making free tier useless for evaluation.
|
|
|
|
### Anti-Pattern: The Support Desert
|
|
|
|
Free users get AI chatbot only, can't access any human help even for bugs.
|
|
|
|
### Anti-Pattern: The Sudden Rug Pull
|
|
|
|
Previously free features moved behind paywall without grandfathering.
|
|
|
|
## Tools
|
|
|
|
### Usage Tracking and Limits
|
|
|
|
- **Lago** - Open source usage-based billing
|
|
- **Metronome** - Usage metering and billing
|
|
- **Orb** - Usage-based billing platform
|
|
- **Stripe Billing** - Metered billing support
|
|
|
|
### Feature Flags for Gating
|
|
|
|
- **LaunchDarkly** - Feature flag management
|
|
- **Flagsmith** - Open source alternative
|
|
- **PostHog** - Feature flags with analytics
|
|
|
|
### Analytics for Conversion
|
|
|
|
- **Amplitude** - Track free-to-paid conversion
|
|
- **Mixpanel** - Funnel analysis
|
|
- **ProfitWell** - SaaS metrics and pricing
|
|
|
|
## Related Skills
|
|
|
|
- `/devmarketing-skills/skills/usage-based-pricing` - Pricing models for developer tools
|
|
- `/devmarketing-skills/skills/developer-signup-flow` - Getting developers to free tier
|
|
- `/devmarketing-skills/skills/developer-onboarding` - Activating free tier users
|
|
|
|
## Limitations
|
|
|
|
- Use this skill only when the task clearly matches its upstream source and local project context.
|
|
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
|
|
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
|