usage-based-pricing

Files (2)

• README.md
• SKILL.md

SKILL.md (first lines)

# Usage-Based Pricing

Design pricing models that developers understand, accept, and can predict—without surprise bills or confusing metrics.

## Overview

Developers are uniquely sensitive to pricing. They'll calculate unit economics, compare alternatives, and write blog posts about surprise bills. Usage-based pricing works well for developer tools because it aligns cost with value, but it can also create anxiety about unpredictable costs.

The best developer pricing is predictable, transparent, and obviously fair. Developers should be able to estimate their bill before they commit.

## Before You Start

Review the `/devmarketing-skills/skills/free-tier-strategy` skill to understand how free tiers connect to paid pricing. Your pricing model should feel like a natural extension of the free tier, not a completely different experience.

## Usage Metrics Developers Accept

### Good Metrics: Direct Value Correlation

**API calls/requests**
- Developers understand what triggers a call
- Easy to monitor and predict
- Scales with actual usage
- Example: Stripe charges per transaction, Twilio per message

**Compute time**
- Clear relationship to server costs
- Predictable for consistent workloads
- Fair for variable workloads
- Example: AWS Lambda per GB-second, Vercel build minutes

**Storage**
- Simple to understand
- Easy to predict growth
- Clear cost driver
- Example: S3 per GB stored, databases per GB

**Bandwidth/data transfer**
- Makes sense for CDN and hosting
- Can be surprising if not monitored
- Example: Cloudflare per GB, Vercel bandwidth

**Active users (MAU)**
- Works for auth and user-facing tools
- Aligns with customer's growth
- Example: Auth0, Firebase Auth

### Problematic Metrics

**"Compute units" or proprietary measures**
```
Bad: "1 CU = 0.25 CPU seconds at 1.5GHz equivalent with 256MB memory allocation"
Developers can't estimate usage.
```

**Compound metrics**
```
Bad: "Charged per operation, where operation = read OR write OR delete,
     multiplied by document size factor"
Too complex to predict.
```

**Metrics that punish success**
```
Bad: Per-user pricing that penalizes viral growth
Developer's successful launch becomes a cost crisis.
```

**Metrics with hidden multipliers**
```
Bad: "Per request, but each retry counts, and warming requests count,
     and health checks count"
Actual usage is unpredictable.
```

### Metric Selection Framework

| Metric | When It Works | When It Fails |
|--------|---------------|---------------|
| API calls | Discrete operations | Streaming, persistent connections |
| Compute time | Variable workloads | Idle resources still cost |
| Storage | Data products | Temporary/cache data |
| Bandwidth | CDN, media | Retry-heavy protocols |
| MAU | User-facing apps | Machine-to-machine |
| Seats | Collaboration tools | Individual developers |

## Pricing Page Clarity

### Essential Pricing Page Elements

1. **Price per unit, clearly stated**
```
$0.01 per 1,000 API calls
$0.10 per GB stored
$5 per team member
```

2. **Usage calculator**
```
Estimate your monthly cost:
API calls per month: [____]
Storage (GB): [____]

Estimated cost: $XX/month
```

3. **Tier comparison table**
```
                Free        Pro         Enterprise
API calls       10,000/mo   100,000/mo  Unlimited
Storage         1GB         50GB        500GB
Support         Community   Email       Priority
Price           $0          $29/mo      $299/mo
```

4. **FAQ answering real questions**
- "What happens if I exceed my limit?"
- "How do I monitor my usage?"
- "Are there any hidden fees?"
- "Can I set spending limits?"

From jonathimer/devmarketing-skills, MIT.

More from jonathimer/devmarketing-skills