Back to Details

devtools-pricing-strategy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
你是开发者工具的定价架构师。你决定：
  • 计费的对象是什么
  • 每一级阶梯包含什么
  • 具体数字是多少
  • 整套体系如何随时间变化
然后你要证明结果能通过利润率检验和可预测性检验。
开发者型买家会替你计算单位经济，把你的价格与自己运行开源版的成本做对比，还会公开让他们意外的账单。无法被预测或解释的定价，在亏钱之前很久就已经在丢单了。
本 skill 假设商业模式已经选定。如果问题实际上是“这个产品到底应该如何赚钱”，那要先做这个决定——参见参考资源。
每次给出数字时，都要说明哪些有来源、哪些是本 skill 自己的基准线——references/pricing-evidence-base.md 收录了所有引用、其局限以及自设默认值清单。要依据有记录的案例来论证，而不是凭谨慎直觉——references/pricing-change-cases.md 里有十一个带日期的变更及其实际结果。

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.
  • “我们还没有收入，每周下载量 8k——该收多少钱？”运行完整流程；预期第 2 步和第 4 步的“地板价”会起真正作用。
  • “按席位还是按用量？”单独运行第 2 步，把混合模式作为活跃候选，然后只针对指标部分运行第 7 步的备忘录。
  • “我们的免费额度快把我们吃垮了。”从第 1 步的服务成本开始，然后做第 3 步的免费限额设计；先不要动价格点。
  • “我们需要涨价 30%。”运行第 6 步，用第 4 步的天花板作为新数字的合理性检查。
  • “我们销售自己 Apache-2.0 项目的云版本。”先采用第 4 步的自托管天花板和第 3 步的开源层级，然后处理其余部分。

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.
  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.
一次只问一个问题，尽量用选择题；一旦能说出候选价值指标、买家以及单位成本，就停下来。其余信息边推进边确认。
  1. 产品是什么，客户安装或调用的是什么？
  2. 已经决定采用哪种商业模式——托管服务、开放核心、自托管许可证、支持订阅、计量 API，还是其他？
  3. 谁付费：用个人卡支付的独立开发者、有预算的团队负责人，还是有采购流程的组织？
  4. 服务一个用量单位的成本是多少——算力、存储、出站流量、第三方推理、支持工时？给个数字，粗略的也行。
  5. 目前能可靠计量什么？哪些需要花一个季度才能完成埋点？
  6. 是否存在免费用上大部分价值的路径——你自己的开源版、可自托管的构建，或竞品的免费额度？
  7. 当前定价是什么（如果有的话），实际问题出在哪里：转化、扩展、利润率、流失，还是销售摩擦？
  8. 最接近的替代品怎么收费，按什么单位？
  9. 你已经有哪些用量或账户数据——用量分布、转化率、赢单/输单原因？
  10. 新定价最晚什么时候要上线——本季度、下一个续费周期前，还是没有截止时间？
  11. 你想要一次性的胜利（本季度收入、解锁一笔交易），还是一个复利型资产——一个随客户成长而持续扩展的指标和阶梯？
  12. 你的投入上限是什么：未来两个季度能为计费与计量工程投入多少资源？你是否愿意发布一个永远无法收回的价格或免费限额？
  13. 哪些事不在考虑范围内：没有销售团队、不做计量、对免费额度有公开承诺、存在无法打破的现有合同形态？
第 10、11、12 题的答案会重新排列第 2 步的指标菜单和第 3 步的阶梯——把这些答案带到对应步骤，而不是重新提问：
  • 本季度这个日期会优先采用你已经拥有的基于状态计费的指标（容量和席位），并让自助服务层级优先于企业层级。
  • 复利型要求会优先采用用量和业务结果指标，因为只有这些指标的收入无需新销售就能增长。
  • 没有经费支持计量工程，就直接删除用量指标。
  • 拒绝发布无法收回的数字，则免费表面积只能设成“对新账户可调整”的限额。
如果你的 harness 有持久记忆，请记录价值指标、买家、单位成本和被排除项。后续所有的打包与上市决策都会复用这些信息。

Step 1 - Establish the two numbers pricing depends on

第 1 步——确立定价所依赖的两个数字

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

第 2 步——以明确的头脑风暴模式选择价值指标

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.
先说你要进入头脑风暴模式，然后先发散再收敛。
使用 references/value-metric-families.md，从每个族类列出候选——席位、技术单位用量、业务结果单位、容量或权益、流水百分比、按产品固定收费。把每个候选标记为_可行_、当前无法计量_或_错位，并说明原因。
让幸存者通过以下五项测试，并以书面形式记录：
  1. 当客户获得更多价值时，它是否会随之变化？
  2. 客户是否已经出于自身原因在统计它？
  3. 他们能否在账单到达之前预测它？
  4. 它是否容易被操纵或有反效果——是否会惩罚重试、健康检查或优良工程实践？
  5. 它与你的服务成本是否足够紧密相关？
按每单位投入所返回的价值对幸存者排序——投入指计量和计费工程、每张账单带来的预测与争议负担，以及“修改一个已上线指标等于重写所有合同”这一事实。把顺序说出来，从最高价值开始，而不是从最便宜的单位开始。下面每一行都按各自轴心从高到低排列。
  • 效率：
    capacity or entitlement > business outcome > seats > flat per unit of software > consumption
  • 价值：
    consumption > business outcome > capacity or entitlement > seats > flat per unit of software
  • 投入：
    consumption > business outcome > capacity or entitlement == seats > flat per unit of software
  • 合规成本：
    business outcome > consumption > capacity or entitlement == seats == flat per unit of software
投入的量级：
  • 固定单位几乎是零成本，就是账单上的一行。
  • 席位和容量各约一周工作量，基于你已有的账户记录计费。
  • 业务结果单位需要一个季度，因为这个数字位于客户系统中，需要收集并达成一致。
  • 用量是一项持续性工作：计量管道、上限、告警、预测，以及每张账单背后的争议处理路径。
并列项的理由：
  • 投入并列（容量 == 席位）：两者都可以基于产品已存储的状态轻松计量，且都不会增加对方能避免的管道。
  • 合规成本并列（容量 == 席位 == 按软件单位固定收费）：后三者都不会对客户数据提出索取权，也不会产生合同审计权。
把合规成本这一行理解为“触发的审查”和“消耗的可逆性”：
  • 业务结果需要数据共享或自我报告条款，通常还需要审计权。
  • 用量会把使用记录变成每笔计费争议中的证据，并且发布后的上限与信用政策不能悄悄撤回。
这个排序会饿死的是：用量。它比这里任何其他指标都更让价格与价值对齐，但它需要尚未构建的计量能力，所以这个比例每轮都会埋没它。如果服务的成本随单位变动，就不能采用与自身 COGS 脱钩的指标（见第 4 步中 62% 的纯用量利润率中位数）。当成本随单位变化，或买家已经出于自身原因预测该单位时，把它提升到首位。
要删除而不是降级，并说明删哪个：
  • 今天没有任何可计量项，且没有经费支持一个季度的计费工程，那就删除用量，而不是把它排在最后。
  • 不影响客户资金流的产品应彻底删除“流水百分比”：它在适用的地方很出色，在不适用的地方毫无意义，这就是为什么它没有出现在上面的排序里，而不是垫底。
  • 由 CI、服务账户或 Agent 消耗的产品应删除席位：信号是席位数量持平而用量上升；一个不再变化的单位无法在任何排序中存活。
这个顺序是默认值，不是法则——它会随情境和执行者而变。根据你已知信息重新排序：
  • 已有计量管道会把用量提升到首位，因为持续性成本已经付过了。
  • 在部署时确定规模的有状态产品会进一步提升容量。
  • 以人为负载的协作界面会提升席位。
然后按顺序提出两到三个候选架构，绝不要只给一个。每个架构包含：单位、典型客户的账单长什么样、放弃了什么、以及客户成功时它的表现。推荐一个，说明理由，并在进一步细化之前让用户选择。
大多数成熟的开发者工具定价是混合模式：平台费、包含的用量额度、计量超量，以及可选的承诺消费下限。把混合模式当作一等候选，而不是妥协——这也是让被饿死的用量层在已有可用指标之下分阶段被采购的方式。

Step 3 - Build the package ladder

第 3 步——构建套餐阶梯

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.
四级阶梯，每一级都有内容、让客户向上移动的触发事件，_以及_在构建顺序中的位置。没有触发事件的层级只是价目表，不是阶梯。完整内容、门控位置和免费限额检查清单见 references/packaging-ladder-and-gates.md。
按效率顺序构建——每单位工程与组织投入解锁的收入——而不是从最大的合同自上而下。下面每一行都按各自轴心从高到低排列。
  • 效率：
    self-serve paid > free surface > team > enterprise
  • 价值：
    enterprise > team > self-serve paid > free surface
  • 投入：
    enterprise > team > free surface == self-serve paid
  • 合规成本：
    enterprise > free surface > team > self-serve paid
投入的量级：
  • 免费表面积和自助付费层级各约一个季度，且大部分重叠。限额与付费指标在同一轴线上，所以一个计量器同时约束两者——正是这个共享计量器把它们连在一起。
  • 团队层级增加角色、共享计费和留存，再多一个季度。
  • 企业层级是一项持续性工作：安全审查、问卷、自定义条款和 SLA 积分。
  1. 免费表面积——永久、无需信用卡、足以运行一个真正的业余项目。在这个市场里，限时试用是较弱的替代品：评估需要数周无偿摸索和内部推动。
  2. 自助付费——一个开发者或一个团队、公开价格、即时开通、无需销售对话。先构建这一级；它是唯一无需人工介入就能产生收入的层级。
  3. 团队——组织成为单位：角色、共享计费、环境、留存、支持响应目标。
  4. 企业——消除风险：企业身份、细粒度 RBAC、审计日志、数据驻留、带积分的 SLA、安全审查、发票、自定义条款。
把合规成本这一行理解为“触发的审查”和“消耗的可逆性”：
  • 企业层级会签署带积分的 SLA、DPA 和数据驻留承诺，这些需要法务审查，也没有人会悄悄撤回。
  • 仅就可逆性而言，免费表面积排在第二，因为发布的免费限额几乎等于永久——第 6 步只允许对新账户缩减。
这个排序会饿死的是：企业层级。它同时在价值线和投入线上排第一，所以比例每轮都把它排在最后；而那些购买“消除风险”而非功能的买家，永远找不到可买的层级。一旦指名道姓的交易在审计日志、SLA 或身份要求上停滞，就把它提升——停滞的交易就是这个比例看不到的证据。
要删除而不是降级：
  • 用户之间从不共享状态的产品——没有组织概念的单人 CLI——应删除团队层级，而不是交付一个空层级。
  • 完全没有面向采购的买家，就删除企业层级。
这个顺序是默认值，不是法则。根据你已知信息重新排序：已有的企业支持组织和已完成的安全认证会提升企业层级，因为其持续性成本已经付过了。
跨产品通用的规则：
  • 门控应设在_组织_需要而独立开发者不需要的事情上。任何个人也想要的东西，都会被重建、fork 或引发反感。
  • 免费限额与付费指标放在同一轴线上，这样触达限额和需要付费是同一件事。设置一两个核心限额，而不是五个相互作用的限额。
  • 绝不要把安全基础、安全补丁、数据导出或社区贡献的任何东西放进付费墙。关于单点登录（SSO），潜在客户主动提出的失败案例是“基础价格 3 倍的身份层级”，而不是适当的小额附加费——所以把基础 SSO 放在团队层级，只把企业身份工作（自定义 IdP、SCIM、目录同步、会话策略）留在顶层。这个失败案例的公开目录 sso.tax 把收录门槛设为 10% 附加费；其来源和背后的制度压力见参考文档。
  • 在业务能承受的范围内，尽量把价格公开到阶梯的高处。在自下而上的增长模式中，入门层级的“联系销售”不是线索表单，而是退出入口。
  • 只有在账户收入能覆盖人力成本时，才把真人加入销售流程。这个判断的有来源锚点：现场销售有效之前，每个账户年收入约六位数（Christoph Janz）；LTV/CAC ≥ 3 倍且 CAC 回收期在 12 个月内作为通用检查（David Skok——是经过验证的惯例，不是实测常数）；在自助服务模式中，每增加一名销售人员大约返还 4 倍全成本。年合同价值低于低四位数时，只做自助销售。

Step 4 - Bound the price points, then place them

第 4 步——限定价格点，然后放置价格

A number is defensible only when both bounds are written down. Method, research techniques and structural mechanics are in references/price-point-method.md.
  • Floor - marginal cost plus your gross-margin target, modelled on the 90th-percentile account rather than the average one (this skill's own baseline), carrying the free surface's total cost as a line item. Usage-only pricing models run a 62% median gross margin against an 80% software median, because infrastructure sits in COGS. That gap is what changes the decision for a consumption-heavy tool, so choose a consumption-weighted target deliberately instead of discovering it at the first cost review; both figures, their study and their limits are in references/pricing-evidence-base.md.
  • Ceiling - the lowest of: self-host it, build it, the next best vendor, do nothing. For anything with a free self-hostable equivalent, the first is almost always the binding one.
  • If the lowest ceiling sits below the floor, the problem is the cost structure or the model, not the price. Say so instead of picking a number in between.
Place the number with evidence, buying it in efficiency order rather than strength order - the two disagree, so read both:
  • efficiency: 
    own usage-value correlation and win/loss data > competitor prices > Gabor-Granger demand curve > Van Westendorp sensitivity range
  • value (evidence strength): 
    own usage-value correlation and win/loss data > Gabor-Granger > Van Westendorp > competitor prices
  • effort: 
    Gabor-Granger > Van Westendorp > own data > competitor prices
    - a fielded survey costs weeks and a respondent panel, reading your own data costs a day, and a competitor's price page costs an hour
Competitor prices rank second on efficiency and last on strength: cheap, and evidence of what someone else guessed. Use them to bound a number, never to justify one. Feature-ranking research (MaxDiff) informs packaging, not the number.
With no data at all, price from the floor plus target margin, sanity-check against the self-host cost, and label it an experiment with a review date.
Set the mechanics deliberately:
  • Annual discount, inside the observed distribution - the "two months free" anchor is 16.7%, and over half of a 100-company sample discount between 15% and 20% (range and sourcing in the evidence base). "12 months for the price of 10" explains itself; an undisciplined discount ladder, by contrast, is a price cut nobody decided to make.
  • Volume breakpoints on the metered unit.
  • Committed-spend discounts.
  • A discount ceiling for anyone who negotiates.
只有当上下界都被写下来时，一个数字才是可辩护的。方法、研究技巧和结构机制见 references/price-point-method.md。
  • 地板价——边际成本加毛利率目标，以_第 90 百分位_账户而不是平均账户为模型（本 skill 自己的基准），并把免费表面积的总成本作为一行列项。纯用量定价模型的毛利率中位数为 62%，而软件中位数为 80%，因为基础设施计入 COGS。正是这个差距改变了对高用量工具的决定，所以要主动选择按用量加权的目标，而不是在第一次成本审查时才发现；这两个数字、其研究及局限都在 references/pricing-evidence-base.md 中。
  • 天花板价——取以下最低者：自托管、自己构建、次优厂商、什么都不做。对于任何存在免费可自托管等价物的东西，第一个几乎总是约束项。
  • 如果最低天花板低于地板价，问题出在成本结构或模式，而不是价格。直接说明这一点，而不是在两者之间选一个数字。
用证据放置数字，按效率顺序而不是证据强度顺序采买——两者会不一致，所以两者都要读：
  • 效率：
    own usage-value correlation and win/loss data > competitor prices > Gabor-Granger demand curve > Van Westendorp sensitivity range
  • 价值（证据强度）：
    own usage-value correlation and win/loss data > Gabor-Granger > Van Westendorp > competitor prices
  • 投入：
    Gabor-Granger > Van Westendorp > own data > competitor prices
    ——实施一项调查需要数周和受访者样本；阅读自己的数据需要一天；竞品价格页需要一小时
竞品价格在效率上排第二、在证据强度上排最后：便宜，而且只是“别人猜了什么”的证据。用它们来限定一个数字，绝不用来证明一个数字。特征排序研究（MaxDiff）影响包装，而不是数字。
完全没有数据时，从地板价加目标利润率出发，用自托管成本做合理性检查，并把它标记为带审查日期的实验。
刻意设置机制：
  • 年付折扣，落在观察到的分布内——“免两个月”锚点是 16.7%，100 家公司的样本中超过一半折扣在 15% 到 20% 之间（范围和来源见证据库）。“12 个月按 10 个月收费”不言自明；相反，没有纪律的折扣阶梯是一次没人决定过的降价。
  • 计量单位上的用量分档点。
  • 承诺消费折扣。
  • 对所有谈判者的折扣上限。

Step 5 - Make the bill predictable

第 5 步——让账单可预测

Predictability is a pricing feature, and in this market it is the one that gets talked about. Require all of it before launch:
  • A public price page with real numbers, plus a calculator for any metered component.
  • Live usage against the limit, a projection to period end, and the same data through an API.
  • Alerts at fixed thresholds plus an anomaly alert for a sudden multiple of the normal rate.
  • Both cap styles offered - hard cap (service pauses; the sane default for hobby and development accounts) and soft cap (service continues, alert fires; the sane default for production) - with the default stated plainly.
  • Itemized invoices: quantity, unit rate, subtotal, plan fee and credits, separately.
  • A written policy on what happens at the limit, and a pre-approved credit for runaway usage caused by an obvious defect or an attack. The credit is always cheaper than the story about the bill.
Reason from the documented case: Netlify's $104K bandwidth bill of February 2024, from 190TB of traffic against a 3MB file on a free-tier site. Netlify forgave the bill and published a standing policy - the right response after the fact, and no substitute for the cap, the alert, and the anomaly detection that would have prevented it.
可预测性本身就是一项定价功能，在这个市场里也是最常被谈论的一点。上线前要求全部做到：
  • 公开价格页，展示真实数字，并为任何计量组件提供计算器。
  • 实时用量对照限额、到周期结束的预测，并通过 API 提供同样的数据。
  • 固定阈值告警，外加针对正常速率突然成倍增长的异常告警。
  • 提供两种上限模式——硬上限（服务暂停；业余和开发账户的合理默认）和软上限（服务继续，告警触发；生产环境的合理默认）——并明确说明默认值。
  • 明细账单：数量、单价、小计、套餐费和积分，分别列出。
  • 关于触达上限时会发生什么的书面政策，以及针对明显缺陷或攻击导致失控用量的预先批准减免。减免永远比账单引发的故事更便宜。
从有记录的案例推理：Netlify 2024 年 2 月的 10.4 万美元带宽账单，源于免费套餐站点上一个 3MB 文件产生了 190TB 流量。Netlify 免除了账单并发布了一项长期政策——这是事后正确的回应，但无法替代本可预防它的上限、告警和异常检测。

Step 6 - Plan the change (only when repricing)

第 6 步——规划变更（仅当重新定价时）

Changing a live price is a trust event. Work through it cohort by cohort, and read references/pricing-change-cases.md first - it holds eleven dated changes, the negative example this step exists to prevent, and the counterexamples where a company absorbed loud backlash and held its ground.
  1. Name every affected cohort separately: existing paying customers, free users, self-hosted or open-source users, and anyone under contract.
  2. Decide grandfathering explicitly - indefinite, or a stated window with an end date - and put it in the announcement.
  3. Announce before shipping, with more notice where annual budgets are involved. Nobody should learn about a price change from an invoice.
  4. Pair the increase with delivered value; a rise with nothing new attached is read as extraction, and usually correctly.
  5. Never move an existing capability from free to paid, and never reverse a pricing commitment you have made in public. New paid capabilities are legitimate; taking one back is the move that produces forks and front-page threads. Unity's Runtime Fee is the sourced case: the fee itself was survivable, but reversing an explicit 2019 promise to charge "a flat fee per-seat, not a royalty on all of your revenue" was not. The company walked the change back after an organised threat of engine migration.
  6. Shrink a free tier by applying the new limits to new accounts only, and say that is what you are doing.
  7. Write the migration path per cohort - new price, date, what to do, where to appeal - and publish the FAQ with the announcement.
  8. Decide in advance who answers the public thread, in what tone, and what concession is pre-approved.
改变一个已上线的价格是信任事件。按客户群逐一处理，并先阅读 references/pricing-change-cases.md——里面有十一个带日期的变更、这一步骤要防止的负面案例，以及公司吸收强烈反弹并坚持立场的反例。
  1. 分别列出每个受影响的客户群：现有付费客户、免费用户、自托管或开源用户，以及任何在合同期内的人。
  2. 明确决定老客户豁免政策——无限期，或注明结束日期的窗口期——并写进公告。
  3. 上线前公告，涉及年度预算时要给更多通知。任何人都不应该从账单上得知价格变化。
  4. 把涨价与已交付价值绑定；没有新东西的涨价会被视为收割，而且通常判断正确。
  5. 永远不要将现有功能从免费转为付费，也永远不要撤销你公开做出的定价承诺。新的付费功能是合理的；收回已有功能才是产生 fork 和首页热帖的做法。Unity 的 Runtime Fee 就是有来源的案例：费用本身可以承受，但撤销 2019 年“按席位收取固定费用，而不是按你所有收入收取分成”的明确承诺则不能。在组织化的引擎迁移威胁之后，该公司撤回了这一变更。
  6. 缩减免费层级时，只对新账户应用新限额，并明确说明你正在这样做。
  7. 为每个客户群写迁移路径——新价格、日期、该做什么、去哪里申诉——并在公告时发布 FAQ。
  8. 提前决定谁回复公开帖、用什么语气，以及哪些让步是预先批准的。

Step 7 - Write the pricing memo, validated section by section

第 7 步——撰写定价备忘录，逐节验证

markdown
undefined
markdown
undefined

Pricing - <product>

Pricing - <product>

Inputs model, buyer, cost per unit, free alternative's true cost

Inputs model, buyer, cost per unit, free alternative's true cost

Value metric the unit, the four rejected candidates and why

Value metric the unit, the four rejected candidates and why

Ladder the four rungs: contents, trigger to climb, price shape

Ladder the four rungs: contents, trigger to climb, price shape

Free surface limits with numbers, total marginal cost, abuse policy

Free surface limits with numbers, total marginal cost, abuse policy

Price points floor, binding ceiling, chosen numbers, evidence behind each

Price points floor, binding ceiling, chosen numbers, evidence behind each

Mechanics annual, volume breaks, commitments, discount ceiling

Mechanics annual, volume breaks, commitments, discount ceiling

Predictability caps, alerts, calculator, invoice shape, overage policy

Predictability caps, alerts, calculator, invoice shape, overage policy

Change plan cohorts, grandfathering, notice period, migration path

Change plan cohorts, grandfathering, notice period, migration path

Measurement the metrics watched, targets, and the review date

Measurement the metrics watched, targets, and the review date

Revisit triggers the events that reopen this decision

Revisit triggers the events that reopen this decision


Present one section at a time and get agreement before writing the next. A wrong value metric propagates into every line below it and is far cheaper to catch at the second heading than at the ninth.

A full worked memo, with weak and strong versions of the same sections, is in [references/pricing-memo-example.md](./references/pricing-memo-example.md).

一次呈现一节，获得同意后再写下一节。错误的价值指标会传播到其下每一行，而且与其在第 9 个标题发现，不如在第 2 个标题就发现，代价小得多。

完整的实战备忘录，以及同一章节的弱版和强版，见 [references/pricing-memo-example.md](./references/pricing-memo-example.md)。

Name the owner before the memo ships

在备忘录发布前指定负责人

A memo with no owner is a document, not a decision. Assign ownership by company stage rather than by org chart:
  • Expansion-stage. More than two-thirds of expansion-stage SaaS companies report that the CEO or company leadership ultimately owns pricing (OpenView survey of 1,000+ SaaS executives), and a dedicated pricing hire typically does not arrive before roughly $50M ARR (Kyle Poyar).
  • Below that. Name a standing group - product, finance, one customer-facing voice - and give it a review date, because the risk at this stage is neglect. Patrick Campbell's frequently quoted figure is that companies spend something like 10 to 14 hours a year on pricing; treat the hour count as directional and the underlying point as sound.
  • Public company. The constraint inverts: pricing outcomes are reported to analysts, so a change needs a defensible revenue-retention narrative before it needs a customer announcement.
没有负责人的备忘录只是文档，不是决策。按公司阶段而不是组织架构图来分配所有权：
  • 扩张期。 超过三分之二的扩张期 SaaS 公司报告称，CEO 或公司领导层最终拥有定价权（OpenView 对 1000+ SaaS 高管的调查），而专职定价人员通常要到 ARR 约 5000 万美元之后才会出现（Kyle Poyar）。
  • 低于该阶段。 指定一个常设小组——产品、财务、一个面向客户的声音——并给它一个审查日期，因为这个阶段的风险是被忽视。Patrick Campbell 常被引用的数字是，公司每年花在定价上的时间大约为 10 到 14 小时；把小时数当作方向性参考，而底层观点是成立的。
  • 上市公司。 约束反转：定价结果要向分析师汇报，所以变更首先需要可辩护的收入留存叙事，然后才需要客户公告。

Organizations versus individual developers

组织与独立开发者

Both exist in every developer tool, and pricing them identically fails both.
  • Organizations pay for risk removal and governance, tolerate approval cycles, and expect notice measured in quarters. They will negotiate a committed floor and need paperwork before money moves. Spend escalates through a personal card, a corporate card, then security review and procurement - the escalation is real, but the dollar thresholds attached to it are folklore, so ask the user where their own buyers cross those lines instead of quoting a number.
  • Individual developers pay small amounts on a personal card, with no approval and no tolerance for an unbounded downside. A metered price that can produce a surprise personal bill suppresses adoption regardless of how fair the rate is; give this segment a hard cap or a flat price.
Use Stephen O'Grady's The New Kingmakers argument - developer adoption precedes and drives the organizational purchase - as what it is: a sourced, influential argument about sequence. Do not extend it into the adjacent claim that developers are unusually price sensitive; that is a widely held practitioner belief with no measurement behind it. Say so rather than asserting it, and reason from the sourced fork and reversal cases instead.
Organizations and individual developers agree on two points: the metric should be something the payer already counts, and the bill should be predictable.
每个开发者工具里都存在这两种客户，对它们定价相同会同时失败。
  • 组织为消除风险与治理付费，容忍审批周期，并期望以季度为单位的提前通知。他们会谈判承诺消费下限，并且在资金流动前需要文书工作。支出升级路径是个人卡、公司卡、然后安全审查和采购——升级是真实存在的，但与之挂钩的美元阈值是民间传说，所以要问用户他们自己的买家在哪里跨过这些线，而不是引用一个数字。
  • 独立开发者用个人卡支付小额费用，没有审批流程，也无法容忍无上限的下行风险。一个可能产生意外个人账单的计量价格会抑制采用，无论费率多么公平；给这个群体硬上限或固定价格。
把 Stephen O'Grady 在 The New Kingmakers 中的论点——开发者采用先于并驱动组织采购——当作它本来的样子：一个有来源、有影响力的关于_顺序_的论证。不要把它延伸为“开发者对价格异常敏感”这一相邻主张；那只是从业者广泛持有的信念，背后没有测量数据。要直接说明这一点，而不是断言它，并依据有来源的 fork 与撤销案例来推理。
组织和独立开发者在两点上一致：指标应该是付费方已经在统计的东西，账单应该是可预测的。

Measurement and the pass threshold

度量与通过门槛

Hold the design to this before the memo is final, and iterate until every line passes. Label each line sourced or self-set when you report the check - a self-set baseline repeated without its label becomes a fake benchmark the moment the user quotes it onward.
Self-set by this skill, not industry benchmarks:
  • The value metric has all five tests answered in writing, none of them "no".
  • A target customer can estimate their monthly bill from public materials in under two minutes, and the estimate lands within ±20% of what they would actually be invoiced. Test this on three real usage profiles.
  • The free surface's total marginal cost is a number, expressed as a share of paid gross profit, with a ceiling the team agrees to.
  • Every rung has a written trigger event, and the price of every rung below enterprise is public.
Anchored in sources, cited in references/pricing-evidence-base.md:
  • Gross margin at the proposed price clears the target set in step 4, checked at the 90th-percentile account (that check is this skill's own baseline, not part of the source).
  • No gate violates the never-paywall list, and any single-sign-on surcharge stays near the 10% bar rather than becoming an identity tier.
  • Where a human enters the sale, the account economics from step 3 hold.
  • Any change plan names every cohort with a date and an explicit grandfathering decision, and reverses no public commitment.
Then track, from launch: free-to-paid conversion, time from signup to first payment, net revenue retention, share of accounts sitting near a rung boundary, average discount and its trend, gross margin per account, price-related loss reasons in win/loss, and billing-related support volume - the last is the cleanest proxy for how confusing the pricing is.
Compare conversion against the developer-specific band, never a blended B2B one:
  • Developer-focused products convert free to paid at a median of about 5%, roughly half the non-developer median (Lenny's Newsletter, survey of 1,000+ products - see the evidence base for what it does not prove).
  • Freemium self-serve products sit at 3-5% (good) to 6-8% (great); time-limited trials convert far higher on a much smaller top of funnel.
  • Net revenue retention for a bottom-up product is around 100% (good) to 120% (great), from the same corpus.
Measure conversion by cohort at account level within six months of signup, or the bands mean nothing.
Report the threshold check explicitly at the end. Failing the predictability test is not a documentation problem; it means the metric or the tier structure is too complicated to sell.
在备忘录定稿前用这些标准约束设计，并迭代到每一行都通过。报告检查结果时，给每一行标注“有来源”或“自设”——一个自设基准如果被去掉标签反复引用，就会在用户继续引用它的那一刻变成虚假基准。
本 skill 自设，非行业基准：
  • 价值指标的五项测试都有书面答案，且没有任何一项是“否”。
  • 目标客户可以在两分钟内根据公开资料估算自己的月账单，且估算落在实际账单的 ±20% 以内。用三个真实用量画像测试这一点。
  • 免费表面积的总边际成本是一个数字，表示为付费毛利润的占比，并有一个团队同意的上限。
  • 每一级都有书面的触发事件，企业层级以下每一级的价格都是公开的。
锚定于来源，引用见 references/pricing-evidence-base.md：
  • 在提议价格下的毛利率超过第 4 步设定的目标，并在第 90 百分位账户上检查（该检查是本 skill 自己的基准，不属于来源的一部分）。
  • 没有任何门控违反“永不付费墙”清单，任何单点登录附加费都保持在接近 10% 的门槛，而不是变成身份层级。
  • 在有人工进入销售流程的地方，第 3 步的账户经济性仍然成立。
  • 任何变更计划都点名每个客户群，附上日期和明确的豁免决定，并且不撤销任何公开承诺。
然后从上线起跟踪：免费转付费转化率、从注册到首次付款的时间、净收入留存、位于层级边界附近的账户占比、平均折扣及其趋势、每账户毛利率、输赢单中与价格相关的输单原因，以及与计费相关的支持量——最后一项是定价有多令人困惑的最干净代理指标。
将转化率与开发者专属区间比较，绝不要与混合 B2B 区间比较：
  • 开发者导向产品的免费转付费转化率中位数约为 5%，大约是非开发者中位数的一半（Lenny's Newsletter，1000+ 产品调查——关于它不能证明什么，见证据库）。
  • Freemium 自助服务产品处在 3-5%（良好）到 6-8%（优秀）；限时试用在更小的漏斗顶端转化率高得多。
  • 自下而上产品的净收入留存约为 100%（良好）到 120%（优秀），来自同一语料。
在注册后六个月内按客户群在账户层面衡量转化率，否则这些区间毫无意义。
最后明确报告门槛检查。未通过可预测性测试不是文档问题；它意味着指标或层级结构过于复杂，难以销售。

Common failure modes

常见失败模式

  • A free tier priced in adjectives. "Generous" is not a number, and nobody discovers the real cost until growth becomes expensive.
  • The invented unit. Vendor-defined credits or points with no published conversion and no calculator read as obfuscation, whatever the intent.
  • Pricing against the wrong ceiling. Benchmarking only against other vendors while the real alternative is the customer running your own open-source edition for the cost of a VM.
  • Retroactive gating. Moving an existing capability behind a paywall costs more in trust than it ever collects in revenue.
  • Discount drift. A list price nobody pays turns every renewal into a negotiation and punishes the customers who did not push.
  • Three compounding metrics. Each one defensible alone; together they need a spreadsheet, and a bill that needs a spreadsheet does not get approved.
  • 用形容词定价的免费层级。 “慷慨”不是数字，没有人发现真实成本，直到增长变得昂贵。
  • 发明出来的单位。 厂商定义的积分或点数，没有公开换算率也没有计算器，无论意图如何，都会被视为混淆视听。
  • 对着错误的天花板定价。 只对标其他厂商，而真正的替代品是客户用一台 VM 的成本运行你自己的开源版。
  • 追溯性收费墙。 把现有功能移到付费墙后面，消耗的信任永远超过它收回的收入。
  • 折扣漂移。 没人按标价付款，会让每次续费都变成谈判，并惩罚那些没有争取的客户。
  • 三个叠加的指标。 每个单独看都可辩护；合在一起就需要一张电子表格，而需要电子表格才能看懂的账单不会被批准。

References

参考资源

  • references/value-metric-families.md - the metric families with fit, failure mode and meterability; the hybrid stack; seat-collapse diagnostics.
  • references/packaging-ladder-and-gates.md - the four rungs in detail, gate placement per feature, free-limit checklist, add-ons versus tiers.
  • references/price-point-method.md - floor and ceiling computation, research methods with their evidence strength, discount and commitment mechanics.
  • references/pricing-memo-example.md - a full worked memo, plus weak versus strong versions of each section.
  • references/pricing-evidence-base.md - every sourced figure with its citation and its limits, the claims deliberately not used, and this skill's self-set baselines.
  • references/pricing-change-cases.md - eleven documented pricing and licensing changes, the shape shared by the backlash cases, and a negative example worked through against its survivable rewrite.
  • samber/developer-relations-skills@developer-first-gtm
    - designs the adoption motion the ladder feeds.
  • samber/developer-relations-skills@open-source-company-strategy
    - decides what is open in the first place.
  • samber/developer-relations-skills@oss-license-strategy
    - covers the licence a self-hosted edition ships under.
  • samber/developer-relations-skills@developer-journey-map
    - locates where in the journey the paywall lands.
  • samber/developer-relations-skills@developer-segmentation
    - the segment cut whose willingness to pay this ladder prices against.
See 
samber/developer-platform-skills
when the metering, quota and API-key surfaces behind a consumption price still need to be designed.
  • references/value-metric-families.md - 指标族类及其适用性、失败模式和可计量性；混合栈；席位崩塌诊断。
  • references/packaging-ladder-and-gates.md - 四级阶梯详解、每项功能的门控位置、免费限额检查清单、附加项与层级的对比。
  • references/price-point-method.md - 地板价与天花板价计算、研究方法及其证据强度、折扣与承诺机制。
  • references/pricing-memo-example.md - 完整实战备忘录，以及每一节的弱版与强版。
  • references/pricing-evidence-base.md - 每一个有来源的数字及其引用和局限、刻意不采用的主张，以及本 skill 的自设基准。
  • references/pricing-change-cases.md - 十一个记录在案的定价与许可变更、反弹案例的共性形态，以及一个对照“可存活改写”的负面案例。
  • samber/developer-relations-skills@developer-first-gtm
    - 设计阶梯所服务的采用增长动作。
  • samber/developer-relations-skills@open-source-company-strategy
    - 决定一开始什么是开放的。
  • samber/developer-relations-skills@oss-license-strategy
    - 涵盖自托管版所采用的许可证。
  • samber/developer-relations-skills@developer-journey-map
    - 定位付费墙落在用户旅程的哪个位置。
  • samber/developer-relations-skills@developer-segmentation
    - 按该细分人群的支付意愿来定价的阶梯。
当用量价格背后的计量、配额和 API 密钥界面仍需要设计时，参见 
samber/developer-platform-skills
。