# Usage based pricing Human Guide

## What This Is For
Design pricing models that developers understand, accept, and can predict—without surprise bills or confusing metrics. It gives the agent a clearer input/output frame for go-to-market work: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Usage based pricing agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for usage based pricing.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Usage based pricing guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- Developers understand what triggers a call
- Example: Stripe charges per transaction, Twilio per message
- Clear relationship to server costs
- Predictable for consistent workloads
- Example: AWS Lambda per GB-second, Vercel build minutes
- Example: S3 per GB stored, databases per GB
- Makes sense for CDN and hosting
- Can be surprising if not monitored
- Example: Cloudflare per GB, Vercel bandwidth
- Works for auth and user-facing tools
- Aligns with customer's growth
- Example: Auth0, Firebase Auth

## Decision Points And Nuance
The original skill emphasizes: Overview, Before You Start, Usage Metrics Developers Accept, Good Metrics: Direct Value Correlation, Problematic Metrics, Metric Selection Framework, Pricing Page Clarity, Essential Pricing Page Elements, Pricing Page Examples, Price Communication Principles.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- Best for: Production, alert required
- Don't just communicate price—communicate value relative to alternatives.
- Test different price points (carefully, ethically)
- No warning, no cap, no mercy
- Penalizes customers who don't negotiate

## Copy-And-Paste Prompt
```text
Use the Usage based pricing human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the jonathimer/devmarketing-skills skill entry for `usage-based-pricing`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# 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 |