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.

Read the compliance line as the review triggered and the reversibility spent:

• Business outcome needs a data-sharing or self-reporting clause and usually an audit right.
• Consumption turns usage records into the evidence in every billing dispute, with published caps and credit policies that cannot be quietly withdrawn.

What this order starves: consumption. It aligns price to value better than anything else here and needs metering nobody has built yet, so the ratio buries it every round. A tool whose cost to serve moves with the unit cannot afford a metric decoupled from its own COGS (see the 62% usage-only margin median in step 4). Promote it above everything when cost tracks the unit, or when the buyer already forecasts that unit for their own reasons.

Delete rather than demote, and say which:

• Nothing meterable today, with no funded quarter of billing engineering, deletes consumption instead of ranking it last.
• A product that does not move the customer's money deletes percentage-of-a-flow entirely: it is excellent where it applies and meaningless where it does not, which is why it is absent from the lines above rather than parked at the bottom.
• A product consumed by CI, service accounts or agents deletes seats: the tell is flat seat count against rising usage, and no ranking survives a unit that stops moving.

This order is a default, not a law - it shifts with context and with who executes it. Re-rank it against what you already know:

• An existing metering pipeline promotes consumption to the top, because the standing cost is already paid.
• A stateful product sized at deployment time promotes capacity further.
• A collaboration surface where humans are the load promotes seats.

Then present two or three candidate architectures, never one, in that order. For each: the unit, what a typical customer's bill looks like, what it gives up, and how it behaves when the customer succeeds. Recommend one, say why, and let the user choose before detailing further.

Most mature devtool pricing is a hybrid: a platform fee, an included allowance, metered overage, optionally a committed-spend floor. Treat the hybrid as a first-class candidate rather than a compromise - it is also how a starved consumption layer gets bought in stages, under a metric that already works.

Step 3 - Build the package ladder

Four rungs, each with contents, a trigger event that moves a customer up, and a place in the build order. A rung with no trigger is a price list, not a ladder. Full contents, gate placement and the free-limit checklist are in references/packaging-ladder-and-gates.md.

Build them in efficiency order - revenue unlocked per unit of engineering and organizational effort - not top-down from the biggest contract. Each line is descending on its own axis, highest first.

• efficiency: self-serve paid > free surface > team > enterprise
• value (annual revenue per account the rung unlocks): enterprise > team > self-serve paid > free surface
• effort: enterprise > team > free surface == self-serve paid
• compliance cost: enterprise > free surface > team > self-serve paid

Effort in magnitudes:

• The free surface and the self-serve rung are each about a quarter and share most of it. Limits sit on the same axis as the paid metric, so one meter enforces both - that shared meter is what ties them.
• The team rung adds roles, shared billing and retention, a quarter more.
• The enterprise rung is a standing job of security reviews, questionnaires, custom terms and SLA credits.

1. Free surface - permanent, no card, enough to run a real side project. In this market a time-boxed trial is a weak substitute: evaluation takes weeks of unpaid tinkering and internal advocacy.
2. Self-serve paid - one developer or one team, published price, instant provisioning, no conversation. Build this rung first; it is the only one that returns revenue without a human in the loop.
3. Team - the org becomes the unit: roles, shared billing, environments, retention, a support response target.
4. Enterprise - risk removal: enterprise identity, granular RBAC, audit logs, residency, SLA with credits, security review, invoicing, custom terms.

Read the compliance line as the review triggered and the reversibility spent:

• Enterprise signs SLAs with credits, DPAs and residency commitments that legal reviews and nobody withdraws quietly.
• The free surface ranks second on reversibility alone, since a published free limit is close to permanent - step 6 only allows shrinking it for new accounts.

What this order starves: the enterprise rung. It tops the value line and the effort line at once, so the ratio puts it last every round, and the buyers who purchase risk removal rather than features never get a rung to buy. Promote it the moment named deals stall on audit logs, an SLA or an identity requirement - a stalled deal is evidence the ratio cannot see.

Delete rather than demote:

• A product whose users never share state - a single-player CLI with no organization concept - deletes the team rung rather than shipping an empty one.
• No procurement-facing buyer at all deletes enterprise.

This order is a default, not a law. Re-rank it against what you already know: an existing enterprise support organization and a completed security certification promote the enterprise rung, because its standing cost is already paid.

Rules that hold across products:

• Gate on things an organization needs and a solo developer does not. Anything an individual also wants gets rebuilt, forked, or resented.
• Set free limits on the same axis as the paid metric, so hitting the limit is the same event as needing to pay. One or two headline limits, not five interacting ones.
• Never paywall security fundamentals, security patches, data export, or anything the community contributed. On single sign-on, the failure prospects raise unprompted is a 3x-base-price identity tier, not a modest surcharge - so put basic SSO at the team rung and keep only enterprise identity work (custom IdPs, SCIM, directory sync, session policy) at the top. The public catalogue of this failure, sso.tax, sets its inclusion bar at a 10% surcharge; sourcing and the institutional pressure behind it are in the reference.
• Publish prices as far up the ladder as the business can bear. In a bottom-up motion, "contact sales" at the entry rung is not a lead form, it is an exit.
• Add a human to the sale only where the account's revenue can carry the human's cost. The sourced anchors for that judgment: roughly six figures of annual revenue per account before field sales works (Christoph Janz), LTV/CAC ≥ 3x with CAC payback inside 12 months as the general check (David Skok - hardened convention, not a measured constant), and about 4x fully loaded cost returned per salesperson added to a self-serve motion. Below low-four-figure annual contract value, sell self-serve only.

Step 4 - Bound the price point

...