Setting or fixing the price of a developer tool or technical

Dev tool pricing

by swan-gtm · MIT license · ★ 159 on GitHub · updated Sep 23

Use this skill when setting or fixing the price of a developer tool or technical product: choosing the value metric, drawing the free-to-paid line, structuring tiers, and finding the actual number. Produces a value metric, a packaging…

---
name: dev-tool-pricing
title: Pricing for developer tools
description: |
  Use this skill when setting or fixing the price of a developer tool or technical product:
  choosing the value metric, drawing the free-to-paid line, structuring tiers, and finding the
  actual number. Produces a value metric, a packaging model, and a defensible price grounded in
  evidence. Triggers on "what should I charge", "how do I price this", "free vs paid", "pricing
  tiers", "value metric", "usage-based vs per-seat", "we're too cheap", "developers won't pay",
  "should I charge yet".
category: Pricing
tags: [RevOps]
---

Applies when you are guessing at a price, priced on a gut feeling and feel stuck, don't know where the free line goes, or believe your users won't pay so you never charge. Produces a value metric, a free-to-paid packaging model, and a defensible number, from evidence rather than fear.

## The three decisions, in order

Overview

Applies when you are guessing at a price, priced on a gut feeling and feel stuck, don't know where the free line goes, or believe your users won't pay so you never charge. Produces a value metric, a free-to-paid packaging model, and a defensible number, from evidence rather than fear.

Manual install (npx, ZIP)

Claude Codenpx skills add swan-gtm/gtm-skills --skill dev-tool-pricing -g -a claude-code

Claude Code (manual)

mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/swan-gtm/gtm-skills/tar.gz/e65d97205fd2 \
  | tar -xz -C ~/.claude/skills --strip-components=3 gtm-skills-e65d97205fd2/skills/shane-oconnor/dev-tool-pricing

Windows (PowerShell)

New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/0d22546c8941633362d1/dev-tool-pricing.zip" -OutFile "$env:TEMP\dev-tool-pricing.zip"; Expand-Archive "$env:TEMP\dev-tool-pricing.zip" -DestinationPath "$HOME\.claude\skills" -Force

Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md4.7 KB

Read the files here

swan-gtm/e65d9721 file

SKILL.md4.7 KB

SKILL.md

Show the full text73 lines

dev-tool-pricing/SKILL.md73 lines · 4.7 KB

PreviewCode

Outline

RawView on GitHub

The three decisions, in order

Most founders skip to the third and wonder why nothing converts.

Value metric — what you charge per. The most important call; get it wrong and no tier structure saves you.
Packaging — what is free, paid, and enterprise, and what triggers the upgrade.
The number — the actual price on each tier.

Price against the value the customer receives, never against your cost or your fear. Your infrastructure bill is a floor, not a strategy.

Are you ready to price?

Do not gate before you have proof people come back. If second-week retention is weak, a paywall just turns a leaky funnel into a smaller one; prove retention first, then monetize. The exception: if buyers are already asking to pay you, that is a green light at any stage. Stated willingness to pay is the strongest signal there is.

The value metric

Charge for the thing that grows as the customer gets more value. A good metric scales with their success (seats, active users, projects, events, calls, data, builds), stays predictable enough to forecast, and is legible in one sentence.

Value from more people → per-seat, but watch for shared logins and bot accounts deflating it.
Value from more usage → usage-based, with a floor and caps so the bill stays predictable.

Hybrid (a platform fee plus usage) is common and fine. Never put per-seat on a machine-value product, or pure usage on a collaboration product: you tax the exact behavior you want more of.

The free-to-paid line

For an open-source or self-serve tool, the free tier is acquisition, not charity. Give away individual value; charge for team, scale, and trust.

Free: the core value for one developer or a tiny team, generous enough to live in their workflow. This is your distribution.
Paid: what a company needs that a person does not — collaboration and seats, higher limits, single sign-on, audit logs, roles, compliance, support and SLAs.
Enterprise: "contact us," wherever security review and procurement enter.

Trigger the upgrade at a moment of earned value ("you added a third teammate," "you crossed the usage threshold," "you need SSO"), never an arbitrary wall or a hidden feature the tool is useless without. Developers forgive a paywall on "my company needs this," and resent one on "the thing you advertised."

Finding the number

Never pick it alone in a room. In order of strength:

Deflected willingness to pay — the "can we pay for this" messages you already got. Ask what it cost them to go without, and what a tier needs to look like to get approved.
Value anchoring — price against what you replace and the time or money you save; capture a slice of the value delivered.
Competitor anchoring — know the number already in the buyer's head, then earn a reason to be higher or lower. "Roughly the same but a bit cheaper" loses.
The range question, asked in user interviews: "At what price is this too expensive to consider? So cheap you doubt it?" The gap is your range.

What good looks like

The value metric fits in one sentence, grows with the customer's success, and stays predictable.
The free-to-paid line falls on team, scale, and compliance, not on the core thing you advertised.
The number came from evidence, not cost or gut.
A healthy share of prospects say "that's a lot." If nobody ever pushes back, you are too cheap.
The customer gets roughly ten times the price in value; below about three times, they churn.

Rules

MUST price against the value the customer receives, not your cost.
MUST prove people return before putting up a paywall, unless buyers are already asking to pay.
NEVER ship more than three self-serve tiers, or a usage price with no cap.
NEVER discount at the first "too expensive"; it trains buyers to push and signals you do not believe your own value.

1	---
2	name: dev-tool-pricing
3	title: Pricing for developer tools
4	description: \|
5	Use this skill when setting or fixing the price of a developer tool or technical product:
6	choosing the value metric, drawing the free-to-paid line, structuring tiers, and finding the
7	actual number. Produces a value metric, a packaging model, and a defensible price grounded in
8	evidence. Triggers on "what should I charge", "how do I price this", "free vs paid", "pricing
9	tiers", "value metric", "usage-based vs per-seat", "we're too cheap", "developers won't pay",
10	"should I charge yet".
11	category: Pricing
12	tags: [RevOps]
13	---
14
15	Applies when you are guessing at a price, priced on a gut feeling and feel stuck, don't know where the free line goes, or believe your users won't pay so you never charge. Produces a value metric, a free-to-paid packaging model, and a defensible number, from evidence rather than fear.
16
17	## The three decisions, in order
18
19	Most founders skip to the third and wonder why nothing converts.
20
21	1. Value metric — what you charge per. The most important call; get it wrong and no tier structure saves you.
22	2. Packaging — what is free, paid, and enterprise, and what triggers the upgrade.
23	3. The number — the actual price on each tier.
24
25	Price against the value the customer receives, never against your cost or your fear. Your infrastructure bill is a floor, not a strategy.
26
27	## Are you ready to price?
28
29	Do not gate before you have proof people come back. If second-week retention is weak, a paywall just turns a leaky funnel into a smaller one; prove retention first, then monetize. The exception: if buyers are already asking to pay you, that is a green light at any stage. Stated willingness to pay is the strongest signal there is.
30
31	## The value metric
32
33	Charge for the thing that grows as the customer gets more value. A good metric scales with their success (seats, active users, projects, events, calls, data, builds), stays predictable enough to forecast, and is legible in one sentence.
34
35	- Value from more people → per-seat, but watch for shared logins and bot accounts deflating it.
36	- Value from more usage → usage-based, with a floor and caps so the bill stays predictable.
37
38	Hybrid (a platform fee plus usage) is common and fine. Never put per-seat on a machine-value product, or pure usage on a collaboration product: you tax the exact behavior you want more of.
39
40	## The free-to-paid line
41
42	For an open-source or self-serve tool, the free tier is acquisition, not charity. Give away individual value; charge for team, scale, and trust.
43
44	- Free: the core value for one developer or a tiny team, generous enough to live in their workflow. This is your distribution.
45	- Paid: what a company needs that a person does not — collaboration and seats, higher limits, single sign-on, audit logs, roles, compliance, support and SLAs.
46	- Enterprise: "contact us," wherever security review and procurement enter.
47
48	Trigger the upgrade at a moment of earned value ("you added a third teammate," "you crossed the usage threshold," "you need SSO"), never an arbitrary wall or a hidden feature the tool is useless without. Developers forgive a paywall on "my company needs this," and resent one on "the thing you advertised."
49
50	## Finding the number
51
52	Never pick it alone in a room. In order of strength:
53
54	1. Deflected willingness to pay — the "can we pay for this" messages you already got. Ask what it cost them to go without, and what a tier needs to look like to get approved.
55	2. Value anchoring — price against what you replace and the time or money you save; capture a slice of the value delivered.
56	3. Competitor anchoring — know the number already in the buyer's head, then earn a reason to be higher or lower. "Roughly the same but a bit cheaper" loses.
57	4. The range question, asked in user interviews: "At what price is this too expensive to consider? So cheap you doubt it?" The gap is your range.
58
59	## What good looks like
60
61	- The value metric fits in one sentence, grows with the customer's success, and stays predictable.
62	- The free-to-paid line falls on team, scale, and compliance, not on the core thing you advertised.
63	- The number came from evidence, not cost or gut.
64	- A healthy share of prospects say "that's a lot." If nobody ever pushes back, you are too cheap.
65	- The customer gets roughly ten times the price in value; below about three times, they churn.
66
67	## Rules
68
69	- MUST price against the value the customer receives, not your cost.
70	- MUST prove people return before putting up a paywall, unless buyers are already asking to pay.
71	- NEVER ship more than three self-serve tiers, or a usage price with no cap.
72	- NEVER discount at the first "too expensive"; it trains buyers to push and signals you do not believe your own value.
73