← All skills
  • Sales
  • v1.0.0
  • pricing
  • revops

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".

SKILL.md

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.

  1. Value metric — what you charge per. The most important call; get it wrong and no tier structure saves you.
  2. Packaging — what is free, paid, and enterprise, and what triggers the upgrade.
  3. 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:

  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.
  2. Value anchoring — price against what you replace and the time or money you save; capture a slice of the value delivered.
  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.
  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.

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.

Files

1 file ship with this skill. They are installed beside the SKILL.md.

NOTICE1.4 KB
Pricing for developer tools
Imported from the GTM Skills library by Swan (https://www.gtmskills.com), skills/shane-oconnor/dev-tool-pricing
at https://github.com/swan-gtm/gtm-skills/commit/5d786aad0c7b2ca59b1abf1f601f9407ca261996. Written by Shane O'Connor (https://www.linkedin.com/in/devtoolgtm).
The skill is shared under the MIT License below; this notice must stay with any copy.

MIT License

Copyright (c) 2026 Swan

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.