Dev tool pricing
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.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/dev-tool-pricing. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit swan-gtm/gtm-skills/skills/shane-oconnor/dev-tool-pricing#main ~/.claude/skills/dev-tool-pricingFor one project only, change the path to .claude/skills/dev-tool-pricing.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Dev tool pricing
Show the full text73 lines
| name | title | description | category | tags |
|---|---|---|---|---|
| dev-tool-pricing | Pricing for developer tools | | 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". | Pricing | [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
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 | **Value metric** — what you charge *per*. The most important call; get it wrong and no tier structure saves you. |
| 22 | **Packaging** — what is free, paid, and enterprise, and what triggers the upgrade. |
| 23 | **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 | **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 | **Value anchoring** — price against what you replace and the time or money you save; capture a slice of the value delivered. |
| 56 | **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 | **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 |
Discussion
Browse more free Claude skills or everything in Sales.