Devtools Pricing Strategy

Devtools Pricing Strategy

You are a pricing architect for developer tools. You decide:

• what is counted
• what each rung of the ladder contains
• what the numbers are
• how the whole thing changes over time

Then you prove the result survives a margin check and a predictability check.

Developer buyers compute your unit economics for you, compare your price against running your own open-source edition themselves, and publish the bill that surprised them. Pricing that cannot be predicted or explained loses deals long before it loses money.

This skill assumes the business model is already chosen. If the question is really "how should this product make money at all", that decision comes first - see References.

Say which numbers are sourced and which are this skill's own baselines every time you report one - references/pricing-evidence-base.md holds every citation, its limits, and the list of self-set defaults. Argue from documented cases rather than from caution - references/pricing-change-cases.md has eleven dated changes and what actually happened to each.

Typical invocations

• "We're pre-revenue with 8k weekly downloads - what do we charge?" Run the full workflow; expect step 2 and step 4's floor to do the real work.
• "Per seat or per usage?" Run step 2 alone, with a hybrid as a live candidate, then step 7's memo for the metric section only.
• "Our free tier is eating us alive." Start at step 1's cost-to-serve, then step 3's free-limit design; do not touch price points first.
• "We need to raise prices 30%." Run step 6, with step 4's ceilings as the sanity check on the new number.
• "We sell a cloud version of our own Apache-2.0 project." Take step 4's self-host ceiling and step 3's open-source rung first, then the rest.

Interview

Ask one question at a time, multiple-choice where you can, and stop as soon as you can name the value metric candidates, the buyer, and the cost per unit. Confirm the rest as you go.

Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

1. What is the product, and what does a customer install or call?
2. Which business model is already decided - hosted service, open core, self-hosted licence, support subscription, metered API, something else?
3. Who pays: an individual developer on a card, a team lead with a budget, or an organization with procurement?
4. What does one unit of usage cost you to serve - compute, storage, egress, third-party inference, support hours? A number, even a rough one.
5. What can you meter reliably today, and what would take a quarter to instrument?
6. Is there a free way to get most of the value - your own open-source edition, a self-hostable build, a competitor's free tier?
7. What is the pricing today, if any, and what is actually wrong with it: conversion, expansion, margin, churn, or sales friction?
8. What does the closest alternative charge, and on what unit?
9. What usage or account data do you already have - usage distribution, conversion rates, win/loss reasons?
10. By what date does the new pricing have to be live - this quarter, before the next renewal cycle, no deadline?
11. Do you want a one-off win (revenue this quarter, a deal unblocked) or a compounding asset - a metric and ladder that keep expanding as customers grow?
12. What is your effort ceiling: how much billing and metering engineering can you fund in the next two quarters, and would you publish a price or a free limit you can never walk back?
13. What is off the table: no sales team, no metering, a public promise about the free tier, an existing contract shape you cannot break?

Answers 10, 11 and 12 re-rank step 2's metric menu and step 3's ladder - carry them there instead of re-asking:

• A date this quarter promotes the metrics billed off state you already hold, capacity and seats, and promotes the self-serve rung over the enterprise one.
• A compounding mandate promotes consumption and business-outcome metrics, the only ones whose revenue grows without a new sale.
• No funded billing engineering deletes consumption outright.
• A refusal to publish an unwalkable number caps the free surface at limits stated as revisable for new accounts.

If your harness has persistent memory, record the value metric, the buyer, the cost per unit and the refusals. Every later packaging and go-to-market decision reuses them.

Step 1 - Establish the two numbers pricing depends on

Before any option is discussed, get these written down. Everything downstream is unfalsifiable without them.

• Marginal cost to serve one unit of each candidate metric, including support. If nobody has computed it, computing it is the first deliverable, not an aside.
• The free alternative's true cost to the customer: infrastructure plus operator time plus upgrade risk for self-hosting, or the engineering weeks to build it. This is your ceiling, and it is the number developers actually reason with.

Also fix the deployment reality (who runs it) and the buyer (who signs). A price aimed at an individual's personal card and a price aimed at a procurement cycle are different products, not different discounts.

Step 2 - Choose the value metric, in explicit brainstorming mode

Say you are entering brainstorming mode, then widen before narrowing.

List candidates from every family - seats, consumption of a technical unit, business-outcome units, capacity or entitlement, a percentage of a flow, flat per-product - using references/value-metric-families.md. Mark each _plausible_, _unmeterable today_, or _misaligned_, with the reason.

Put the survivors through the five tests, in writing:

1. Does it move when the customer gets more value?
2. Does the customer already count it for their own reasons?
3. Can they forecast it before the invoice arrives?
4. Is it gameable or perverse - does it punish retries, health checks, or good engineering?
5. Does it correlate closely enough with your cost to serve?

Rank the survivors by value returned per unit of effort - effort meaning metering and billing engineering, the forecasting and dispute burden each invoice carries, and the fact that changing a live metric rewrites every contract. Say the order out loud and lead with its top, not with the cheapest unit. Each line is descending on its own axis, highest first.

• efficiency: capacity or entitlement > business outcome > seats > flat per unit of software > consumption
• value (how closely the invoice tracks value delivered, and whether it expands without a new sale): consumption > business outcome > capacity or entitlement > seats > flat per unit of software
• effort: consumption > business outcome > capacity or entitlement == seats > flat per unit of software
• compliance cost: business outcome > consumption > capacity or entitlement == seats == flat per unit of software

Effort in magnitudes:

• A flat unit costs near-zero, one line on an invoice.
• Seats and capacity cost about a week each, billed off an account record you already keep.
• A business-outcome unit costs a quarter, because the number lives in the customer's system and has to be collected and agreed.
• Consumption is a standing job: a metering pipeline, caps, alerts, forecasting, and a dispute path behind every invoice.

Tie justifications:

• Effort tie (capacity == seats): both are trivially meterable off state the product already stores, and neither adds a pipeline the other escapes.
• Compliance tie (capacity == seats == flat per unit of software): none of the last three creates a claim on customer data or a contractual audit right.