samber/developer-relations-skills已通过检查
SKILL DETAIL
devtools-pricing-strategy
samber/developer-relations-skills/devtools-pricing-strategy
Designs the pricing and packaging architecture of a developer tool - the value metric (seats, consumption, capacity, outcome, or a hybrid), free-tier limits, the tier ladder up to enterprise gating, price points bounded by a margin floor and the self-host and build-it ceilings, and a plan to change prices without a backlash. Use whenever someone asks what to charge for a developer tool, how to package tiers, where free ends and paid begins, whether to bill per seat or per usage, how to price against their own open-source edition, or how to raise prices safely - even if they only say the pricing page feels wrong. Not which business model to run - use samber/developer-relations-skills@devtools-business-model. Not pricing-page copy.
安装量 · 426查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill devtools-pricing-strategy
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "devtools-pricing-strategy",
"evals": [
{
"id": 1,
"prompt": "We're Flagstone - hosted feature-flag evaluation, 210 paying teams on $19/user/month. Seat count per account has been flat at 5.4 for fourteen months while flag evaluations went from 40M to 380M a month. Revenue is basically flat. Everyone on the team is saying go usage-based. Problem: we can read seats, projects and environments straight off our account records today, but metering evaluations per account is a solid quarter of backend work and it is not in this year's budget. What should we do about the pricing model?",
"expected_output": "A metric diagnosis naming the seat collapse, an explicit brainstorm across all metric families, consumption deleted rather than demoted because nothing is meterable and no engineering is funded, capacity or entitlement promoted for the near term, an additive repair rather than a wholesale swap, and two or three candidate architectures with a recommendation.",
"files": [],
"expectations": [
"Identifies the seat-collapse pattern, citing the flat 5.4 seats per account against the 40M to 380M evaluation growth as the diagnostic evidence",
"Deletes consumption from the candidate list outright rather than ranking it last, on the grounds that nothing is meterable today and no billing engineering is funded",
"Promotes capacity or entitlement - environments, projects or concurrency - as the near-term metric because it bills off account state the product already stores",
"Treats the metric repair as additive: keeps a seat component for the human console surface and adds a second layer for the automated load",
"Warns that a wholesale metric swap re-prices every existing account at once and turns a metric fix into a churn event",
"States explicitly that it is entering brainstorming mode before widening the candidate list",
"Lists candidates from every metric family - seats, consumption, business outcome, capacity or entitlement, percentage of a flow, flat per unit of software - and marks each plausible, unmeterable today, or misaligned with the reason",
"Puts surviving candidates through five tests in writing: moves with value, already counted by the customer, forecastable before the invoice, not gameable or perverse, and correlated with cost to serve",
"States the efficiency ranking of the metric families out loud rather than leaving it implied by the order of the list",
"Presents two or three candidate pricing architectures, never a single one, and recommends among them",
"For each candidate architecture, gives the unit, what a typical customer's bill looks like, what it gives up, and how it behaves when the customer succeeds",
"Treats a hybrid - platform fee, included allowance, metered overage, optional committed spend - as a first-class candidate rather than a compromise",
"Notes that changing a live value metric rewrites every contract, every forecast and the metering pipeline underneath, unlike packaging or price points which can be re-cut in a quarter",
"Does not recommend moving all 210 existing accounts onto a new metric on a single date"
]
},
{
"id": 2,
"prompt": "Kestrelbase is our Apache-2.0 time-series database - roughly 1,400 known self-hosted deployments. We're launching Kestrelbase Cloud next quarter. Marginal cost is $0.0009 per million points ingested plus $0.011 per GB-month stored, and our heaviest 10% of beta accounts cost about 4x the median account. A mid-sized team self-hosting spends roughly $260/month on infrastructure and about 5 engineer-hours a month keeping it alive. The nearest managed competitor lists $400/month flat. What should Cloud cost?",
"expected_output": "A floor computed from marginal cost at the 90th-percentile account with the free surface carried inside it, a self-host ceiling quantified in the customer's terms including operator time, the competitor price used only as a bound, and a margin target chosen deliberately against the usage-pricing median.",
"files": [],
"expectations": [
"Computes the floor from marginal cost plus a gross-margin target rather than from the $400 competitor price",
"Models the floor on the 90th-percentile account - the heaviest decile costing about 4x the median - rather than on the average or median account",
"Labels the 90th-percentile modelling choice as this skill's own baseline rather than an industry benchmark",
"Carries the free surface's total marginal cost as a line item inside the margin calculation rather than outside it",
"Identifies self-hosting as the binding ceiling for a product with a free self-hostable equivalent",
"Computes the self-host ceiling as infrastructure plus operator time plus upgrade risk plus on-call, quantified in the customer's terms rather than the vendor's",
"Converts the 5 engineer-hours a month into a loaded cost figure and adds it to the $260 infrastructure cost",
"Treats the $400 competitor price as a bound on the number and never as the justification for it",
"Names all four ceilings - self-host it, build it, the next best vendor, do nothing - and takes the lowest",
"States that usage-only pricing models run a 62% median gross margin against an 80% software median, because infrastructure cost sits in COGS",
"Labels the 62% and 80% margin figures as sourced, distinguishing them from the skill's self-set baselines",
"Recommends choosing a consumption-weighted margin target deliberately rather than discovering it at the first cost review",
"Recommends publishing what will always stay in the open-source edition, warning that silence is read as intent to close",
"Keeps the paid gates on operation, governance and support rather than on capability the community could rebuild in a weekend"
]
},
{
"id": 3,
"prompt": "Parchmill runs OCR plus structured extraction over scanned contracts. We charge $0.02 per document. GPU inference alone is $0.017 a document and support works out to another $0.004. Prospects keep telling us they can run the open-weights model on spot instances for about $0.006 a document. Our investors want 75% gross margin by next year. What price gets us there?",
"expected_output": "A refusal to name a price, because the lowest ceiling ($0.006 self-host) sits below the floor ($0.021 marginal cost, roughly $0.084 at a 75% target), with the diagnosis pointed at the cost structure or business model rather than the price point.",
"files": [],
"expectations": [
"States explicitly that the lowest ceiling sits below the floor",
"Refuses to pick a price point in between the floor and the ceiling, and says so rather than splitting the difference",
"Names the binding ceiling as self-hosting the open-weights model at roughly $0.006 per document",
"Computes the floor as about $0.021 per document of marginal cost - $0.017 GPU plus $0.004 support - before any margin is added",
"Shows that a 75% gross-margin target implies a price of roughly $0.084 per document",
"Attributes the problem to the cost structure or the business model rather than to the price point",
"Does not propose a willingness-to-pay survey, a Van Westendorp study or a Gabor-Granger exercise as the fix",
"Proposes changes to the cost structure, to what is sold, or to the value metric rather than a repricing",
"Notes that usage-only pricing sits at a 62% median gross margin, so a 75% target is above that median and must be chosen deliberately",
"Warns that upstream pass-through costs change without notice, so the floor needs re-checking whenever they move"
]
},
{
"id": 4,
"prompt": "Weatherline - API observability. Team plan is $240/month, Enterprise 'starts at $28k'. SSO is enterprise-only and honestly it is the single biggest reason anyone upgrades, so finance wants to keep it there. We're also planning to move data export and the raw CSV download behind the paid tier because free users burn a lot of egress, and to hold security patches for the community edition for 30 days so paying customers get them first. Sanity check the gating?",
"expected_output": "Basic SSO moved down to the team rung with only enterprise identity work left at the top, the data-export and security-patch proposals both refused against the never-paywall list, and the $240-to-$28k jump named as the identity-tier failure prospects raise unprompted.",
"files": [],
"expectations": [
"Moves basic SSO with a common identity provider down to the team rung",
"Keeps only enterprise identity work - custom IdPs, SCIM, directory sync, session policy - at the enterprise rung",
"Rejects moving data export and the CSV download behind a paid tier",
"States that data export and portability sit on the never-paywall list because withholding them blocks migration in both directions and reads as a trap",
"Rejects the 30-day embargo on security patches for the community edition, and places security patches at every rung always",
"Names visibility into the customer's own usage and bill as something never to paywall",
"Names anything the community contributed as something never to paywall",
"Cites the sso.tax catalogue's own inclusion bar - roughly a 10% price hike - as the design threshold for any SSO surcharge",
"Notes that the original sso.tax repository is dormant and the catalogue is maintained in a successor fork",
"States that the failure prospects raise unprompted is a roughly 3x-base-price identity tier rather than a modest surcharge",
"Identifies the current $240 to $28k jump as exactly that identity-tier failure",
"Mentions the CISA Secure by Design pledge naming SSO at no extra cost as a goal with 200+ signatories, while noting the pledge is voluntary rather than binding",
"Applies the gate test: a capability belongs above a rung only when an organization needs it and a solo developer does not, the crossing is observable, and the cost to serve is covered"
]
},
{
"id": 5,
"prompt": "Tollgate (CI cache-as-a-service). Two things. One: our blog post from 2024 says the free tier will 'always include 10 GB of cache storage' - we need that down to 2 GB. Two: the build-history view has been free since launch and we want it in the $49 plan. Plan is to publish the announcement and flip the switch the same day, three weeks from now, with existing customers moving at their next renewal. Draft the announcement for me.",
"expected_output": "A refusal to draft the change as specified: the retroactive gating and the reversal of the public commitment are both blocked, the free-tier reduction is scoped to new accounts only, every cohort is named with an explicit dated grandfathering decision, and notice precedes shipping.",
"files": [],
"expectations": [
"Refuses to move the build-history view from free to paid, and states that retroactive gating is the move that produces forks and front-page threads",
"Refuses to reverse the public 2024 commitment that the free tier would always include 10 GB",
"Cites Unity's September 2023 Runtime Fee as the sourced case for reversing a public pricing commitment",
"Identifies the reversal of Unity's explicit 2019 promise to charge \"a flat fee per-seat, not a royalty on all of your revenue\" - rather than the fee itself - as what made the change unsurvivable",
"Notes that Unity walked the change back under an organised threat of engine migration",
"Applies any free-tier reduction to new accounts only, and says plainly that this is what is being done",
"Names every affected cohort separately: existing paying customers, free users, self-hosted or open-source users, and anyone under contract",
"Makes the grandfathering decision explicit - indefinite, or a stated window with an end date - and puts it in the announcement",
"Rejects 'existing customers move at their next renewal' as an implicit grandfathering decision with no end date and no cohort named",
"Requires the announcement to precede shipping rather than landing the same day, with more notice where annual budgets are involved",
"States that nobody should learn about a price change from an invoice",
"Pairs any increase with delivered value, and warns that a rise with nothing new attached is read as extraction",
"Assigns a named owner to the public thread in advance, with the tone and a pre-approved concession decided before the announcement",
"Proposes introducing a new paid capability instead of taking back an existing one"
]
},
{
"id": 6,
"prompt": "Spindrift is our serverless image transform API. Last month a free-tier user's site got scraped hard and generated $9,400 of overage. We refunded the whole thing. Leadership now wants a mandatory hard cap on every account - production included - and wants to kill the free tier entirely so this can't happen again. Is that the right call?",
"expected_output": "Both cap styles offered with hard as the hobby/development default and soft as the production default, the free-tier removal rejected, the Netlify case reasoned from, and the full predictability requirement list - calculator, live usage, projection, usage API, threshold plus anomaly alerts, itemized invoices, written runaway-usage policy.",
"files": [],
"expectations": [
"Offers both cap styles rather than mandating one: a hard cap where the service pauses, and a soft cap where service continues and an alert fires",
"Sets the hard cap as the sane default for hobby and development accounts and the soft cap as the sane default for production accounts, and states the default plainly",
"Rejects removing the free tier as the fix for bill shock",
"Reasons from Netlify's February 2024 $104K bandwidth bill, caused by 190TB of traffic against a 3MB file on a free-tier site, as the documented case",
"Notes that Netlify forgave the bill and published a standing policy",
"States that a goodwill credit is a patch on a design defect, not a substitute for the cap, the alert and the anomaly detection that would have prevented it",
"States that the credit is always cheaper than the story about the bill",
"Requires an anomaly alert triggered by a sudden multiple of the normal rate, in addition to alerts at fixed thresholds",
"Requires live usage against the limit, a projection to period end, and the same data available through an API",
"Requires a public price page with real numbers plus a calculator for any metered component",
"Requires itemized invoices showing quantity, unit rate, subtotal, plan fee and credits separately",
"Requires a written policy on what happens at the limit, plus a pre-approved credit for runaway usage caused by an obvious defect or an attack, written before it is needed",
"Treats predictability as a pricing feature rather than a documentation problem",
"Recommends a hard cap or a flat price for individual developers on a personal card, because an unbounded downside suppresses adoption regardless of how fair the rate is"
]
},
{
"id": 7,
"prompt": "Our free-to-paid conversion is 4.2%. The board pulled a SaaS benchmark of 10-15% and now thinks we're broken, and they want the free tier cut to force people to pay. We're Rillwater Migrate, a CLI-first database migration tool: 22,000 signups last year, NRR 104%, three paid tiers starting at $39. Is 4.2% actually bad?",
"expected_output": "4.2% read against the developer-specific band rather than a blended B2B one, placed inside the normal range, NRR 104% read against the bottom-up band, the measurement definition stated, and the free-tier cut rejected as the response.",
"files": [],
"expectations": [
"Compares 4.2% against the developer-specific conversion band rather than a blended B2B one",
"States that developer-focused products convert free to paid at a median of about 5%, roughly half the non-developer median",
"Attributes that figure to a survey of 1,000+ products and notes it is a distribution midpoint rather than a target",
"Places 4.2% inside the 3-5% good band for freemium self-serve, with 6-8% as great",
"Notes that blended B2B benchmarks make any developer tool look broken",
"Reads NRR of 104% against the bottom-up band of roughly 100% good to 120% great rather than an enterprise band",
"Requires conversion to be measured by cohort, at account level, within six months of signup, or the bands mean nothing",
"Notes that time-limited trials convert far higher on a much smaller top of funnel, so the two numbers are not comparable",
"Rejects cutting the free tier as the response to a conversion figure sitting inside the normal band",
"Warns that a published free limit is close to permanent and can only be shrunk for new accounts",
"Does not accept the board's 10-15% figure as the applicable benchmark for this product",
"Recommends checking whether the free limits sit on the same axis as the paid value metric before changing any limit"
]
},
{
"id": 8,
"prompt": "Quarrystone is our log-search SaaS - 90 paying accounts, full usage instrumentation for two years, and complete churn records. We have three months to reset pricing. We've budgeted for a Van Westendorp study with a 300-person panel across our four segments, and an intern is scraping seven competitors' pricing pages into a sheet. What should the research plan actually look like?",
"expected_output": "Own usage-value correlation and win/loss data ranked first on both efficiency and strength, the two orderings stated separately because they disagree, competitor scraping demoted to a bound only, Van Westendorp checked against its sample requirement, and MaxDiff assigned to packaging rather than price.",
"files": [],
"expectations": [
"Ranks the team's own usage-value correlation and win/loss data first on both efficiency and evidence strength",
"States the efficiency ordering and the evidence-strength ordering separately, and notes that they disagree",
"Places competitor price scraping second on efficiency and last on evidence strength",
"States that competitor prices may be used to bound a number but never to justify one",
"Describes a competitor's published price as evidence of what someone else guessed",
"Ranks Gabor-Granger above Van Westendorp on evidence strength",
"Notes that Van Westendorp needs roughly 100+ respondents per segment, and checks the 300-person panel against the four segments",
"States that stated willingness to pay on a described product is weaker evidence than observed behaviour on a live one",
"Prioritises reading the existing usage and churn data, which costs about a day, ahead of fielding a survey that costs weeks and a respondent panel",
"Recommends win/loss and churn interviews as the only source of real price objections with the alternative named",
"Excludes MaxDiff or feature-ranking research from the price decision and assigns it to packaging instead",
"Identifies the usage threshold at which customers call the product load-bearing as an output of the usage-value correlation work"
]
},
{
"id": 9,
"prompt": "Vaultstream, 6 engineers, developer secrets-sync CLI. We have a free tier and one enterprise deal in the pipeline worth $180k a year that is blocked on audit logs and SCIM. Roadmap for the next two quarters: build the enterprise tier first (SSO, RBAC, audit logs, SOC 2), then a team tier, then figure out self-serve some time after. Entry tier will be 'contact us' so we can qualify every lead. Sanity check this plan?",
"expected_output": "The efficiency build order stated with self-serve paid first, enterprise named as the rung the order starves plus the stalled-deal condition that promotes it anyway, 'contact us' at the entry rung rejected as an exit, every rung given a written trigger, and the field-sales economics checked.",
"files": [],
"expectations": [
"States the ladder build order in efficiency terms: self-serve paid first, then the free surface, then team, then enterprise",
"Names the self-serve paid rung as the only one that returns revenue without a human in the loop",
"Names enterprise as the rung the efficiency order starves, because it tops the value line and the effort line at once",
"Applies the promotion condition for enterprise - a named deal stalled on audit logs, an SLA or an identity requirement - to the blocked $180k deal",
"Describes a stalled named deal as evidence the efficiency ratio cannot see",
"Rejects 'contact us' at the entry rung, stating that in a bottom-up motion it is an exit rather than a lead form",
"Recommends publishing prices as far up the ladder as the business can bear",
"Requires every rung to carry a written trigger event that moves a customer up, and states that a rung with no trigger is a price list rather than a ladder",
"Notes that the free surface and the self-serve rung share most of their effort because one meter enforces both, with free limits sitting on the same axis as the paid metric",
"Gives the effort magnitudes: the free surface and self-serve rung about a quarter each and largely shared, the team rung about a quarter more, and enterprise as a standing job of security reviews, questionnaires, custom terms and SLA credits",
"Checks the account economics before putting a human in the sale, citing roughly six figures of annual revenue per account, attributed to Christoph Janz, as the anchor for field sales",
"Cites LTV/CAC of at least 3x with CAC payback inside 12 months, attributed to David Skok and labelled a hardened convention rather than a measured constant",
"States that below low-four-figure annual contract value the motion should be self-serve only",
"Warns that enterprise commitments - SLAs with credits, DPAs, residency - are reviewed by legal and are not quietly withdrawn"
]
},
{
"id": 10,
"prompt": "I'm CTO at Ambergate - 30 people, $6M ARR, hosted API gateway. Board meeting next Tuesday and I need the complete pricing document end to end, all sections, in one go. We bill per gateway instance today at $450/month, cost to serve is about $95 per instance, our top decile costs closer to $310, and we have no free tier. Also tell me who should own pricing here going forward - I keep getting asked and we have no one.",
"expected_output": "The memo presented one section at a time with agreement before the next, following the ten-section structure, plus an ownership recommendation keyed to company stage: a standing group with a review date at $6M ARR, not a dedicated pricing hire.",
"files": [],
"expectations": [
"Presents the memo one section at a time and gets agreement before writing the next, rather than delivering every section at once",
"Justifies section-by-section validation by noting that a wrong value metric propagates into every line below it and is far cheaper to catch at the second heading than at the ninth",
"Uses the ten-section memo structure: inputs, value metric, ladder, free surface, price points, mechanics, predictability, change plan, measurement, revisit triggers",
"Places the value metric section second, immediately after inputs",
"Requires the value metric section to name the chosen unit and the rejected candidates with the specific reason each was rejected",
"Assigns pricing ownership by company stage rather than by org chart",
"States that more than two-thirds of expansion-stage SaaS companies report the CEO or company leadership ultimately owns pricing, attributed to an OpenView survey of 1,000+ SaaS executives",
"Notes that a dedicated pricing hire typically does not arrive before roughly $50M ARR, attributed to Kyle Poyar, and that $6M ARR sits far below that line",
"Names a standing group - product, finance, one customer-facing voice - with a review date, rather than a single functional owner or a new pricing hire",
"States that the risk at this stage is neglect",
"Cites the frequently quoted figure of roughly 10 to 14 hours a year spent on pricing, attributed to Patrick Campbell, and labels the hour count directional rather than measured",
"States that a memo with no named owner is a document rather than a decision",
"Models the floor on the $310 top-decile cost rather than the $95 average cost to serve",
"Reports the threshold check explicitly at the end, labelling each line sourced or self-set"
]
},
{
"id": 11,
"prompt": "Northmoor (managed Postgres with branching) - the free tier is bleeding us. Today free gives unlimited branches, 5 GB storage, 100 compute-hours, 3 projects, 10 GB egress and 7-day point-in-time recovery. Paid starts at $29 and is billed on compute-hours. Free costs us about $31k a month. Plan: halve every limit, add a 90-day inactivity expiry, and delete data on dormant free projects. Tell me how to execute it.",
"expected_output": "The free surface cut to one or two headline limits on the compute-hour axis, the inactivity expiry and data deletion both refused, warning thresholds and a stated enforcement behaviour added, the $31k expressed as a share of paid gross profit against an agreed ceiling, and the reduction applied to new accounts only.",
"files": [],
"expectations": [
"Cuts the free surface to one or two headline limits rather than the six currently listed",
"Sets the headline free limit on the same axis as the paid value metric - compute-hours - so hitting the limit is the same event as needing to pay",
"States that five or more interacting limits cannot be evaluated without a spreadsheet",
"Rejects the 90-day inactivity expiry as a time bomb on the free tier",
"Rejects deleting data on dormant free projects, and states that data must never be deleted as enforcement",
"Requires warnings at 70%, 85% and 95% of a limit, followed by a stated behaviour - throttle, queue, pause, or bill overage",
"Labels the 70/85/95 warning thresholds as this skill's own baseline rather than an industry standard",
"Expresses the $31k per month free-surface cost as a share of paid gross profit, with a ceiling the team agrees to",
"Applies the reduced limits to new accounts only, and says plainly that this is what is being done",
"Requires a written abuse policy with rate ceilings, covering mining, spam and multi-account farming, instead of a smaller limit for every honest user",
"Requires the free surface to run a real side project comfortably while failing a small company's production workload",
"Rejects replacing the permanent free surface with a time-boxed trial, noting evaluation in this market takes weeks of unpaid tinkering and internal advocacy",
"Rejects describing the free tier in adjectives such as 'generous' instead of numbers",
"Requires the marginal cost of a single free account to be computed, not only the $31k aggregate"
]
},
{
"id": 12,
"prompt": "Brightwell, AI code review. New model we're about to ship: 'Brightwell Credits' at $0.10 each - roughly one credit per review action, though the exact conversion moves as model costs change so we would rather not publish a table - plus $12 per seat per month plus a $0.60 per-repository-per-month platform fee. Finance likes it because all three lines grow independently. Poke holes in it.",
"expected_output": "The three compounding metrics rejected, the unpublished credit conversion refused, the three conditions an invented unit must meet stated, and the design failed against the two-minute / plus-or-minus-20% predictability test on three usage profiles.",
"files": [],
"expectations": [
"Rejects the three compounding metrics, stating that each may be defensible alone but together they require a spreadsheet",
"States that a bill which needs a spreadsheet does not get approved",
"Requires the credit conversion table to be published, and rejects the plan to keep it unpublished",
"Requires a calculator that takes the customer's own numbers",
"Requires stability in what a credit buys, and states that silently reducing it is a price rise plus a deception and gets read as both",
"States that without all three of a published conversion, a calculator and stability, an invented unit reads as obfuscation whatever the intent",
"Applies the predictability test: a target customer estimates their monthly bill from public materials in under two minutes, landing within plus or minus 20% of the actual invoice",
"Requires that predictability test to be run on three real usage profiles",
"Labels the two-minute, plus-or-minus-20% predictability test as this skill's own baseline rather than an industry benchmark",
"States that failing the predictability test means the metric or the tier structure is too complicated to sell, not that the documentation needs work",
"Recommends collapsing to one headline metric, at most with a platform fee and metered overage above an included allowance",
"Checks the composite unit against the five value-metric tests, in particular whether the customer can forecast it before the invoice arrives"
]
},
{
"id": 13,
"prompt": "Fernbrook is a local-first sync engine. Two very different buyers: indie developers paying on their own cards, and platform teams inside banks. I've read everywhere that developers are extremely price sensitive, so the plan is to cap everything at $9/month and let it spread bottom-up. Separately: what's the dollar amount where a purchase stops being a corporate card swipe and starts needing procurement? I want to price just under it.",
"expected_output": "The price-sensitivity claim declined as an unmeasured practitioner belief, the card-to-procurement dollar threshold refused as folklore with the question turned back to the user, and the two buyers priced as different products with a hard cap or flat price for individuals.",
"files": [],
"expectations": [
"Declines to affirm that developers are unusually price sensitive, and identifies it as a widely held practitioner belief rather than a measured effect",
"States that the price-sensitivity claim has never been measured against a control group",
"Refuses to supply a dollar threshold at which a purchase stops being a corporate card swipe and starts needing procurement",
"States that the personal-card, corporate-card, then security-review-and-procurement escalation is real while the dollar figures attached to it are folklore",
"Asks the user where their own buyers cross those lines instead of supplying a number",
"Rejects pricing both audiences identically, and states that doing so fails both",
"Prices individual developers with a hard cap or a flat price, because an unbounded downside suppresses adoption regardless of how fair the rate is",
"Describes organizations as paying for risk removal and governance, tolerating approval cycles, and expecting notice measured in quarters",
"Notes that organizations will negotiate a committed floor and need paperwork before money moves",
"Cites Stephen O'Grady's The New Kingmakers as a sourced argument about the sequence of developer adoption preceding the organizational purchase, and does not extend it into a claim about price sensitivity",
"Names the two points on which organizations and individual developers agree: the metric should be something the payer already counts, and the bill should be predictable",
"Treats a price aimed at a personal card and a price aimed at a procurement cycle as different products rather than different discounts"
]
}
],
"trigger_queries": [
{ "query": "What should we charge for our developer tool?", "should_trigger": true },
{ "query": "How do I price my API product?", "should_trigger": true },
{ "query": "We're pre-revenue with 8k weekly downloads, what do we charge?", "should_trigger": true },
{ "query": "Help me set price points for our hosted service", "should_trigger": true },
{ "query": "How much should the paid tier of our CLI cost?", "should_trigger": true },
{ "query": "I need to decide on a price for our managed database service", "should_trigger": true },
{ "query": "We have no idea what to charge and no customers yet", "should_trigger": true },
{ "query": "What's a sensible entry price for a self-serve developer product?", "should_trigger": true },
{ "query": "Design the pricing for our new SDK product", "should_trigger": true },
{ "query": "Can you help me put numbers on our plans?", "should_trigger": true },
{ "query": "How do I price a cloud version of my own open-source project?", "should_trigger": true },
{ "query": "What should our enterprise tier start at?", "should_trigger": true },
{ "query": "Per seat or per usage for our tool?", "should_trigger": true },
{ "query": "Should we bill per API call or per user?", "should_trigger": true },
{ "query": "What's the right value metric for a CI product?", "should_trigger": true },
{ "query": "Our seat count is flat while usage triples, what do we bill on?", "should_trigger": true },
{ "query": "Is usage-based pricing right for us?", "should_trigger": true },
{ "query": "Should we charge per repository or per developer?", "should_trigger": true },
{ "query": "We want to move to credits, does that work?", "should_trigger": true },
{ "query": "Help me pick the unit our invoice multiplies", "should_trigger": true },
{ "query": "Per-environment or per-concurrent-job pricing?", "should_trigger": true },
{ "query": "Our CI drives all the usage and nobody logs in, how do we bill?", "should_trigger": true },
{ "query": "Thinking about a hybrid of platform fee plus metered overage", "should_trigger": true },
{ "query": "Should we switch from per-seat to consumption pricing?", "should_trigger": true },
{ "query": "Where should our free tier end and paid begin?", "should_trigger": true },
{ "query": "Our free tier is eating us alive", "should_trigger": true },
{ "query": "How generous should the free plan be?", "should_trigger": true },
{ "query": "What limits should we put on the free tier?", "should_trigger": true },
{ "query": "Should we do a permanent free tier or a 14-day trial?", "should_trigger": true },
{ "query": "We want to shrink our free plan, how do we do it without a riot?", "should_trigger": true },
{ "query": "How do I stop free users costing us so much?", "should_trigger": true },
{ "query": "What belongs in the free plan of a developer tool?", "should_trigger": true },
{ "query": "Should the free tier expire after 90 days of inactivity?", "should_trigger": true },
{ "query": "How many limits should a free tier have?", "should_trigger": true },
{ "query": "How should I package our tiers?", "should_trigger": true },
{ "query": "How many plans should we have?", "should_trigger": true },
{ "query": "What goes in the team plan versus enterprise?", "should_trigger": true },
{ "query": "Should SSO be an enterprise-only feature?", "should_trigger": true },
{ "query": "Where do audit logs belong in our tier structure?", "should_trigger": true },
{ "query": "Add-on or a new tier for our compliance package?", "should_trigger": true },
{ "query": "Help me design the plan ladder for our devtool", "should_trigger": true },
{ "query": "Should we publish enterprise pricing or say contact sales?", "should_trigger": true },
{ "query": "Which features should we gate behind paid plans?", "should_trigger": true },
{ "query": "We have four tiers and seven add-ons, is that too many?", "should_trigger": true },
{ "query": "We need to raise prices 30%", "should_trigger": true },
{ "query": "How do we announce a price increase without a backlash?", "should_trigger": true },
{ "query": "We're retiring our free plan, what's the plan?", "should_trigger": true },
{ "query": "How long should we grandfather existing customers?", "should_trigger": true },
{ "query": "Planning a price change, what could go wrong?", "should_trigger": true },
{ "query": "Is it ok to move a currently free feature into a paid plan?", "should_trigger": true },
{ "query": "We promised something about pricing on our blog and now need to change it", "should_trigger": true },
{ "query": "How much notice should we give before a price rise?", "should_trigger": true },
{ "query": "We want to reprice every customer at once next month", "should_trigger": true },
{ "query": "What's the safest way to change our pricing model?", "should_trigger": true },
{ "query": "What gross margin should a usage-priced devtool target?", "should_trigger": true },
{ "query": "How do I price against people just self-hosting our open-source version?", "should_trigger": true },
{ "query": "Our cost per request is high, how do we work out the price floor?", "should_trigger": true },
{ "query": "How do I know if our price is too low?", "should_trigger": true },
{ "query": "What's the ceiling on what we can charge?", "should_trigger": true },
{ "query": "Should I set our price off what our competitor charges?", "should_trigger": true },
{ "query": "Is a Van Westendorp survey worth running for our pricing?", "should_trigger": true },
{ "query": "How do we work out willingness to pay with only 90 accounts?", "should_trigger": true },
{ "query": "How do we stop customers getting surprise bills?", "should_trigger": true },
{ "query": "Should we offer spend caps?", "should_trigger": true },
{ "query": "Do we need a pricing calculator on the site?", "should_trigger": true },
{ "query": "How should we design overage billing?", "should_trigger": true },
{ "query": "What alerts should fire before a customer hits their limit?", "should_trigger": true },
{ "query": "Hard cap or soft cap as the default?", "should_trigger": true },
{ "query": "Our pricing page feels wrong and I can't put my finger on why", "should_trigger": true },
{ "query": "Everyone signs up, hits our limits, and leaves instead of paying", "should_trigger": true },
{ "query": "A customer posted a $40k invoice from us on Hacker News this morning", "should_trigger": true },
{ "query": "Revenue is flat but usage has tripled this year", "should_trigger": true },
{ "query": "The board wants 80% gross margin and I don't think our numbers work", "should_trigger": true },
{ "query": "Sales keeps losing deals over one missing feature in our top plan", "should_trigger": true },
{ "query": "Should we be open core or a hosted managed service?", "should_trigger": false },
{ "query": "How should our developer tool make money at all?", "should_trigger": false },
{ "query": "Open core versus a support subscription for our project?", "should_trigger": false },
{ "query": "Is a marketplace take-rate a viable model for us?", "should_trigger": false },
{ "query": "Should we open-source the product and sell a managed cloud?", "should_trigger": false },
{ "query": "Adoption is huge and revenue is zero, which revenue model fixes that?", "should_trigger": false },
{ "query": "Dual licensing or source-available for our commercial model?", "should_trigger": false },
{ "query": "What business model do infrastructure companies usually run?", "should_trigger": false },
{ "query": "MIT or Apache-2.0 for our new library?", "should_trigger": false },
{ "query": "Does AGPL actually protect us from cloud providers?", "should_trigger": false },
{ "query": "Should we require a CLA or a DCO sign-off?", "should_trigger": false },
{ "query": "How do we relicense an existing project to BUSL?", "should_trigger": false },
{ "query": "What should we open source and what stays proprietary?", "should_trigger": false },
{ "query": "Which LICENSE, SPDX and NOTICE files do we need to ship?", "should_trigger": false },
{ "query": "Is the Functional Source License a good fit for us?", "should_trigger": false },
{ "query": "Who signs off on open sourcing this internal tool?", "should_trigger": false },
{ "query": "Bottom-up self-serve or hire a sales team?", "should_trigger": false },
{ "query": "When should we contact a free user for a sales conversation?", "should_trigger": false },
{ "query": "How do landed teams expand across an enterprise?", "should_trigger": false },
{ "query": "Design the land-and-expand path for our product", "should_trigger": false },
{ "query": "Our funnel is broken, which go-to-market motion should we run?", "should_trigger": false },
{ "query": "How does developer adoption turn into revenue?", "should_trigger": false },
{ "query": "What does our first sales hire for a developer product look like?", "should_trigger": false },
{ "query": "How do I set up GitHub Sponsors tiers for my library?", "should_trigger": false },
{ "query": "Nobody sponsors my widely used open-source project, why?", "should_trigger": false },
{ "query": "Write sponsor reward tiers for our Open Collective page", "should_trigger": false },
{ "query": "How do I get a company to fund my maintenance work?", "should_trigger": false },
{ "query": "What should our FUNDING.yml point at?", "should_trigger": false },
{ "query": "Is sponsorware a good idea for my project?", "should_trigger": false },
{ "query": "Implement Stripe metered billing in our Next.js app", "should_trigger": false },
{ "query": "How do I wire up subscription webhooks without double-charging?", "should_trigger": false },
{ "query": "Write the invoice generation job for our billing service", "should_trigger": false },
{ "query": "Our proration logic is wrong on mid-cycle upgrades, help me debug it", "should_trigger": false },
{ "query": "Set up usage records against the Stripe API", "should_trigger": false },
{ "query": "How do I model subscriptions and plan changes in Postgres?", "should_trigger": false },
{ "query": "Automate dunning emails for failed payments", "should_trigger": false },
{ "query": "Build a customer billing portal with Clerk", "should_trigger": false },
{ "query": "Our AWS bill doubled, help me cut it", "should_trigger": false },
{ "query": "How do I estimate the cost of an Azure deployment?", "should_trigger": false },
{ "query": "Which savings plan should we buy for our EC2 fleet?", "should_trigger": false },
{ "query": "Explain the pricing model of S3 storage classes", "should_trigger": false },
{ "query": "Reduce our Datadog spend", "should_trigger": false },
{ "query": "Tag our cloud resources for cost allocation", "should_trigger": false },
{ "query": "What's the cheapest way to run GPUs for inference?", "should_trigger": false },
{ "query": "Price my meal-kit subscription box", "should_trigger": false },
{ "query": "What should I charge for my freelance design work?", "should_trigger": false },
{ "query": "How do I price a consumer mobile game's in-app purchases?", "should_trigger": false },
{ "query": "Set pricing for our yoga studio memberships", "should_trigger": false },
{ "query": "How should a marketing agency package its retainers?", "should_trigger": false },
{ "query": "Pricing strategy for a B2C wellness app", "should_trigger": false },
{ "query": "What's the right hourly rate for consulting?", "should_trigger": false },
{ "query": "Write the headline and CTA copy for our pricing page", "should_trigger": false },
{ "query": "Redesign our pricing page layout so it converts better", "should_trigger": false },
{ "query": "What FAQ questions should go under our pricing table?", "should_trigger": false },
{ "query": "Rewrite our plan descriptions to sound less corporate", "should_trigger": false },
{ "query": "Pick the colour scheme and button styles for our pricing table", "should_trigger": false },
{ "query": "Who are our developers actually, and which segment do we serve first?", "should_trigger": false },
{ "query": "Map the developer journey from discovery to advocacy", "should_trigger": false },
{ "query": "Which devrel metrics should we report to the board?", "should_trigger": false },
{ "query": "How should we split our devrel budget across conferences and content?", "should_trigger": false },
{ "query": "Audit our documentation structure", "should_trigger": false },
{ "query": "Write the release notes for version 3.2", "should_trigger": false },
{ "query": "Should we sponsor this conference at the gold tier?", "should_trigger": false },
{ "query": "How do we launch our Discord community?", "should_trigger": false },
{ "query": "Optimize our README for new contributors", "should_trigger": false },
{ "query": "How do we rank our docs pages in search?", "should_trigger": false },
{ "query": "Write a CFP submission for our platform talk", "should_trigger": false },
{ "query": "Benchmark our competitor's developer experience", "should_trigger": false },
{ "query": "Design the quota enforcement service behind our API", "should_trigger": false },
{ "query": "How should we structure API keys and scopes?", "should_trigger": false },
{ "query": "Build the rate-limit policy for our public API", "should_trigger": false },
{ "query": "How do we expose a usage endpoint in our REST API?", "should_trigger": false },
{ "query": "What should our API error body look like when a quota is exceeded?", "should_trigger": false },
{ "query": "Architect the metering pipeline that aggregates request counts", "should_trigger": false }
]
}
references/packaging-ladder-and-gates.md›
# Packaging ladder and gate placement
Contents: the four rungs · gate placement per capability · the never-paywall list · free-limit checklist · add-ons versus tiers · pricing on top of your own open source.
## The four rungs
Each rung needs contents, a price shape, and a **trigger** - the event in the customer's life that moves them up. Contents without a trigger is a price list. The table runs in customer-journey order; the order to _build_ them in is the efficiency order in the skill's step 3.
| Rung | Purpose | Typical contents | Price shape | Trigger to leave |
| --------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------- |
| Free surface | evaluation and real small-scale use, permanently, no card | full core capability, all SDKs, standard auth, own-usage visibility, community support | $0 with one or two headline limits | growth past a limit, or moving to production |
| Self-serve paid | one developer or one team buys without a conversation | higher limits, basic collaboration, email support with a stated response window | published, card, instant provisioning | a second team, an admin who is not a user, a procurement requirement |
| Team / business | the org becomes the unit of purchase | roles and permissions, shared billing, multiple environments, longer retention, support target, basic SSO | published, per the value metric, annual option | security review, residency, SLA, custom terms |
| Enterprise | risk removal for an organization with procurement | enterprise identity (custom IdP, SCIM, directory sync), granular RBAC, audit logs, residency, SLA with credits, private or dedicated deployment, invoicing | "starts at $X", negotiated | - |
## Gate placement per capability
A capability belongs above a rung only if an _organization_ needs it and a solo developer does not, the crossing is observable, and the cost to serve is covered.
| Capability | Belongs at | Why |
| ------------------------------------------------------------ | -------------------- | ----------------------------------------------------------------------------- |
| Core functionality, SDKs, CLI | free | gating it makes evaluation impossible and the free tier pointless |
| Standard authentication, basic SSO with a common provider | free or team | security fundamentals; gating them is the most criticised move in this market |
| Usage visibility and data export | free | withholding either reads as a trap and blocks migration in both directions |
| Higher limits, more environments, longer retention | self-serve and above | scales with value, observable, costs you money |
| Roles, permissions, shared billing | team | meaningless to a solo developer, essential to an org |
| Audit logs, enterprise identity, residency, SLA with credits | enterprise | bought by compliance and risk functions, not by users |
| Priority support, dedicated contacts | team and enterprise | genuine marginal cost, scales with headcount not usage |
| Security patches | every rung, always | withholding them turns users into adversaries and attracts CVE coverage |
## The never-paywall list
- Security fundamentals and security patches for the free edition.
- Data export and portability.
- Anything the community contributed.
- Visibility into the customer's own usage and bill.
Each of these has produced public backlash or a hostile fork somewhere in this market. The single-sign-on case is catalogued publicly - sso.tax, whose original repository is dormant and whose maintained successor is the `stopthessotax/sso-wall-of-shame` fork - and is the one prospects will bring up unprompted.
The catalogue's own inclusion bar is a useful design threshold: "if your SSO support is a 10% price hike, you're not on this list." Institutional pressure points the same way: the CISA Secure by Design pledge, with 200+ signatories, names SSO at no extra cost as a goal.
## Free-limit checklist
- Limits sit on the same axis as the paid value metric, so hitting the limit _is_ the moment paying becomes necessary.
- One or two headline numbers. Five interacting limits cannot be evaluated without a spreadsheet.
- A real side project runs comfortably; a small company's production workload does not.
- The marginal cost of a free account is computed, and the free surface's total cost is capped as a share of paid gross profit.
- No time bomb: no expiry, no "free tier ends after 90 days of inactivity", no quiet degradation of speed or reliability.
- Warnings at 70/85/95% of a limit, then a stated behaviour - throttle, queue, pause, or bill overage. Never delete data as enforcement.
- An abuse policy exists in writing (mining, spam, multi-account farming) with rate ceilings, instead of a smaller limit for every honest user.
## Add-ons versus tiers
Use a **tier** when needs move together with size. Use an **add-on** when a need is orthogonal to size: an extra region, a compliance package, premium support, extended retention, a specialised connector.
Cap the count. Three add-ons across four tiers is already twelve configurations a price page must explain and a sales conversation must quote. When add-ons multiply, fold the most-attached one into the tier above it.
## Pricing on top of your own open source
When a free self-hostable edition exists, it is the bottom rung and it competes with every paid rung above it.
- Price the hosted offering against the true cost of self-hosting: infrastructure, operator time, upgrade risk, and the on-call burden.
- Keep the paid gates on operation, governance and support rather than on capability the community could rebuild in a weekend.
- Publish what will always stay in the open edition. Silence is read as intent to close, and the community prices that in immediately.
- Expect self-hosted users to be your best advocates and your worst prospects at the same time; that is the deal, not a problem to fix with restrictions.
references/price-point-method.md›
# Placing the number: floor, ceilings, evidence, mechanics
Contents: computing the floor · the four ceilings · research methods by evidence strength · structural mechanics · signals that a price is wrong.
## Computing the floor
1. Take one unit of the chosen value metric and add every marginal cost it triggers: compute, storage, egress, third-party API or inference spend, and the support hours the account consumes at that volume.
2. Model the **90th-percentile account**, not the average. In consumption products the top decile sets the margin, and averages hide the accounts that lose money.
3. Add the free surface as a line item: its total marginal cost is paid for by the paid rungs, so it belongs inside the margin calculation, not outside it.
4. Set a gross-margin target and price above it. A 2026 study of 342 SaaS and AI companies puts the software median at 80% and the top quartile at 86%; usage-only pricing models sit at a 62% median because infrastructure cost lands directly in COGS. Infrastructure- and inference-heavy products therefore choose a lower target deliberately rather than discovering it in the first cost review.
5. Re-check whenever an upstream cost moves. Pass-through costs change without notice, and a price set once against them silently drifts below the floor.
## The four ceilings
Take the **lowest** one; it is the number the buyer will reason with.
1. **Self-host it.** For anything with a free self-hostable equivalent: infrastructure plus operator time plus upgrade risk plus on-call. Quantify all four in the customer's terms, not yours.
2. **Build it.** Developers price your product against a sprint of their own work. The honest comparison includes maintenance, on-call and opportunity cost - not just the first implementation.
3. **The next best vendor.** Their published price anchors the conversation whether or not the products are comparable.
4. **Do nothing.** A real competitor for tools that improve rather than enable.
If the lowest ceiling sits below the floor, no price works. The problem is the cost structure or the business model, and pricing cannot fix it.
## Research methods, by strength of evidence
| Method | What it gives | Strength | Cost |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ----------------------------- |
| Usage-value correlation on your own data | which usage patterns predict retention and expansion, and the threshold where customers call the product load-bearing | strongest for an existing product | low, if usage is instrumented |
| Win/loss and churn interviews | price as an actual decision, with the alternative named | strong; the only source of real objections | medium |
| Live price experiments on new signups | observed behaviour at different numbers | strong, but slow and awkward to run fairly | medium |
| Gabor-Granger | "would you buy at $X" across randomized points → a demand curve | medium; better than asking people to name a price | medium |
| Van Westendorp | four questions → an acceptable range and an optimal zone | medium; needs ~100+ respondents per segment | medium |
| MaxDiff / best-worst scaling | feature importance ranking | packaging input, not a price input | medium |
| Competitor price scraping | the anchor buyers will quote at you | weak alone; reproduces someone else's mistake | trivial |
Stated willingness to pay on a described product is always weaker evidence than observed behaviour on a live one. For a product with users, weight your own data above every survey.
With no data at all: price from the floor plus the target margin, sanity-check against the self-host and build ceilings, publish it as an experiment with a review date. Under-pricing is the more common error and the harder one to reverse, because every existing customer becomes an argument against the correction.
## Structural mechanics
- **Annual discount.** The "two months free" anchor is 16.7%; in a sample of 100 SaaS companies over half discount between 15% and 20%, with the full range running roughly 3.5-44%. Buys cash and cuts churn; do not stack it with volume and commitment discounts without a floor.
- **Volume breakpoints.** Published breaks on the metered unit reward growth without a renegotiation. Publishing them also removes the incentive to call sales purely to ask.
- **Committed spend.** A floor in exchange for a lower rate. Makes revenue forecastable on both sides and is the natural bridge from self-serve to contract.
- **Anchoring.** The top published tier makes the recommended tier look reasonable - and stops working entirely when the top tier is obviously unbuyable.
- **Discount ceiling.** Decide the maximum discount and who can approve it before the first negotiation. In sales-assisted motions the discount ladder, not the list price, is the real price.
- **Price presentation.** Charm pricing suits value positioning, round numbers suit premium positioning; neither survives a bill the customer cannot predict.
## Signals that the price is wrong
- **Raise it:** nobody objects to price, win rates are unusually high, churn is very low, discounts are rarely requested, prospects say some version of "that's cheap".
- **Lower it or re-package:** losses cluster on price against one competitor, self-serve conversion collapses at the first paid step, or the entry price sits above what an individual will put on a personal card for a tool individuals adopt.
- **Change the metric instead of the number:** revenue is flat while usage grows, or customers systematically buy the smallest tier and over-consume it.
references/pricing-change-cases.md›
# Pricing changes that went public
Contents: eleven documented changes and their outcomes · the shape shared by the backlash cases · a negative example worked through · the positive counterpart.
Every row below is a real, dated change with a public reaction. Use them instead of a hypothetical warning: a founder who has read the Unity timeline argues differently from one who has read "be careful with price rises".
## The corpus
| Company | Date | Change | Reaction | Outcome |
| -------------- | -------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| Heroku | announced Aug 2022, effective Nov 2022 | removed all free dynos, Postgres and Redis | large community backlash; third-party migration guides proliferated | held; paid Eco/Mini tiers introduced |
| Netlify | Feb 2024 | $104K bandwidth bill after a traffic spike on a free-tier site | viral on Reddit and Hacker News | bill forgiven; standing no-charge-for-legitimate-mistakes policy stated |
| PlanetScale | Mar-Apr 2024 | retired the free Hobby tier, alongside layoffs | strong backlash, largely about tone | held; a $5/month tier added Oct 2025 |
| GitHub Copilot | Jun 2025, then Jun 2026 | premium requests, then a full move to usage-based billing | community FAQ thread with 435 comments, 904 downvotes against 22 upvotes | base prices held; annual plans grandfathered to expiry |
| Unity | Sep 2023 | per-install Runtime Fee | severe backlash, reported death threats, office closures | public apology and major walk-back: Personal tier exempted, cap raised, no retroactive application |
| HashiCorp | Aug 2023 | Terraform et al. relicensed MPL 2.0 → BSL 1.1 | OpenTF Manifesto, 32,000+ GitHub stars | OpenTofu fork adopted by the Linux Foundation; a cease-and-desist failed |
| Redis | Mar 2024 | BSD → dual SSPLv1/RSALv2 | Valkey forked within days, backed by AWS, Google, Oracle, Ericsson, Snap | AGPLv3 added back in Redis 8.0 (May 2025); Redis said the change "hurt our relationship with the Redis community" |
| Sentry | 2019, then Nov 2023 | BSD-3 → BSL, then the Functional Source License | mixed | FSL kept, framed as "freedom without free-riding" |
| Docker | Aug 2021 | Docker Desktop paid for businesses ≥250 employees or ≥$10M revenue | backlash over the short effective date | held; still free for personal, education and non-commercial OSS use |
| Vercel | 2024-2025 | four compute-pricing model changes in ~20 months | continuing discussion about bill complexity | Active CPU pricing is the current model |
| Datadog | 2022-2023 | a large usage-based bill became a public story | Hacker News threads | addressed on earnings calls rather than reversed |
## What the worst cases have in common
Short notice, every tenant moved onto the new model at once, and a user base technically capable of imposing real costs back. The strongest evidence that this is not merely noise is the set of cases where the community changed the outcome:
- HashiCorp could not suppress OpenTofu even with legal action.
- Valkey's cloud-vendor backing drove Redis to re-add AGPLv3 about a year later.
- Unity reversed outright under an organised threat of engine migration.
Note the counterexamples in the same table. Heroku, PlanetScale and Docker all absorbed loud backlash and held their changes.
Backlash alone does not force a reversal - a credible substitute does. Before assuming a change is unsurvivable, ask whether the affected users have somewhere to go.
## Negative example: the change most likely to be attempted
**What a team writes.** "We're moving the audit log to the Business tier next month. It's been free since launch, but it's an enterprise feature and it costs us storage. Existing customers move on their next renewal."
Why this fails, point by point:
- It takes back a capability customers already build on. New paid capabilities are legitimate; retroactive gating is the move that produces forks and front-page threads.
- One month is not notice for anything a budget covers.
- The justification is the vendor's cost, not the customer's value. Cost justifications invite the customer to compute your margin, and developers will.
- "Next renewal" is a grandfathering decision made implicitly, with no end date stated and no cohort named.
- Nobody is assigned to the public thread, and no concession is pre-approved.
Unity is the sourced version of this failure, and the specific detail worth carrying: the Runtime Fee's core problem was not the fee but that it reversed an explicit 2019 commitment to charge "a flat fee per-seat, not a royalty on all of your revenue". Breaking a stated pricing promise reads as materially worse than an ordinary increase.
**The same intent, written to survive.** Keep the audit log where it is for every existing account, indefinitely, and say so. Introduce the _new_ governance capability - retention beyond 30 days, export to a customer-owned bucket, tamper-evident storage - at the Business tier, priced against the storage it actually consumes. Announce a quarter ahead, name the three cohorts (free, self-serve, contracted) with what changes for each, publish the FAQ with the announcement, and decide in advance who answers the thread and what they may concede.
## Positive example: what a good response to bill shock looks like
Netlify's $104K bill came from 190TB of traffic hitting a 3MB file on a free-tier site at $55/100GB overage - the canonical missing-spend-cap failure. The response is the citable part: forgive the bill, and state a standing policy of not shutting down free sites during traffic spikes while forgiving bills from legitimate mistakes after the fact.
Two things to take from it:
- The credit is always cheaper than the story - write the runaway-usage policy before you need it.
- A goodwill credit is a patch on a design defect, not a substitute for the cap, the alert and the anomaly detection that would have prevented it.
references/pricing-evidence-base.md›
# Pricing evidence base
Contents: sourced figures and what each one does not prove · claims deliberately not used · this skill's own baselines.
Read this before quoting any number back to a user. A figure used without its limit becomes a fake benchmark the moment the user repeats it in a board deck.
## Sourced figures
| Figure | Value | Source | What it does not prove |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Software gross margin | median 80%, top quartile 86%, blended total-revenue 76% | Aleph x Benchmarkit _SaaS & AI Performance Benchmarks_ 2026, full-year 2025 data, 342 companies | A target for one company. Cross-sector median of self-reported figures. |
| Gross margin, usage-only pricing | 62% median | same study | Causation. Consumption pricing correlates with lower margin because infrastructure cost sits in COGS; it does not make margin fall. |
| A public devtool at scale | Datadog GAAP gross margin 81.7% in Q4 2024, down from 83.4% | Datadog Q4 2024 earnings call | Anything about a pre-scale company's cost structure. |
| Annual-vs-monthly discount | anchor "two months free" ≈ 16.7%; over half of 100 SaaS companies discount 15-20%; full range 7.4-44% (lower-priced packages), 3.5-34% (higher-priced) | InnerTrends analysis of 100 SaaS companies | That 16.7% is optimal. It is legible ("12 months for the price of 10"), which is a different property. |
| Field-sales viability | roughly six-figure annual revenue per account: "if you're not able to extract six figures from each customer, you're not going to be able to build a profitable and scalable customer acquisition engine" | Christoph Janz, _Five ways to build a $100M business_ (Point Nine, 2014, updated 2019) | A measured threshold. It is an argument from unit economics, widely adopted. |
| Sales economics check | LTV/CAC ≥ 3x, CAC payback ≤ 12 months | David Skok, _SaaS Metrics 2.0_ (Matrix Partners) | A derived constant. Hardened convention; treat as a heuristic. |
| One salesperson on a self-serve motion | should return ~4x fully loaded cost in incremental revenue | Lenny's Newsletter, _The Transition: layering sales onto a bottom-up self-serve product_ | Applicability below the ACV where a human can pay for themselves at all. |
| Free-to-paid, developer products | **median 5%, about half the non-developer median** | Lenny's Newsletter, _What is good free-to-paid conversion_ (survey of 1,000+ products) | That 5% is a target. It is a distribution midpoint, and blended B2B benchmarks make any devtool look broken. |
| Free-to-paid by free surface | freemium self-serve 3-5% good / 6-8% great; freemium with sales assist 5-7% / 10-15%; free trial 8-12% / 15-25% | same post | Comparability across different definitions - see the measurement note below. |
| Net revenue retention, bottom-up | ~100% good, ~120% great (land-and-expand SMB ~90%/~110%; enterprise ~110%/~130%) | Lenny's Newsletter, _What is good retention?_ | That NRR bands transfer between motions; network effects lift bottom-up figures. |
| Who owns pricing | more than two-thirds of expansion-stage companies say the CEO or company leadership owns it | OpenView survey of 1,000+ SaaS executives | That leadership ownership is correct, only that it is normal. |
| When a pricing specialist arrives | typically not before ~$50M ARR | Kyle Poyar (formerly OpenView, now Growth Unhinged) | A rule. Use as a trigger to revisit ad-hoc ownership. |
| Deliberate time spent on pricing | "10 to 14 hours a year" | Patrick Campbell, ProfitWell | A precise measurement. Directional; the citable claim is that pricing gets almost no deliberate attention. |
| Acceptable SSO surcharge | "If your SSO support is a 10% price hike, you're not on this list" | Rob Chahin, sso.tax - original repository dormant, maintained at the `stopthessotax/sso-wall-of-shame` fork | That 10% is a safe harbour with buyers; it is one maintainer's inclusion threshold. |
| Institutional pressure on SSO | "SSO available at no extra cost" named as a goal, 200+ signatories | CISA Secure by Design pledge | A binding requirement. The pledge is voluntary. |
Measurement definitions the conversion bands assume, since quoting a band while measuring differently is how these get misused:
- Free-to-paid = accounts that begin paying within their first six months ÷ accounts created in the window, measured **by cohort** (a lifetime ratio flatters any product whose sign-ups grew) and at **account** level, not per user.
- NRR = a cohort's MRR today ÷ the same cohort's MRR twelve months ago.
## Claims deliberately not used
- **"Developers are unusually price sensitive."** Repeated constantly in practitioner writing, and never measured against a control group. Present it as a widely held belief, never as a measured effect.
- **Personal-card, corporate-card and procurement dollar thresholds.** The escalation is real and well described; the specific dollar figures attached to it at named vendors are unverified. Use the concept, never a number.
- **"40% of SaaS companies place pricing with product / 98% call it strategic / 56% have dedicated resources."** Circulated as a summary of a 2023 Paddle survey, and not confirmed in the survey itself.
- **"26% of new ARR comes from annual contracts."** Attributed to a 2022 OpenView survey, unverified against the survey itself.
- **Vendor limits and rates as benchmarks.** Competitor free-tier numbers age within a quarter. Use the pattern, quote the number only with its date.
## This skill's own baselines
None of these is an industry standard. They are defensible and measurable, which is not the same thing - say which they are whenever you report them.
- The predictability test: a target customer estimates their bill within ±20% in under two minutes, checked on three usage profiles.
- Warn at 70/85/95% of a free limit before enforcing it.
- One or two headline free limits, never five interacting ones.
- Cap the add-on count; three add-ons across four tiers is already twelve configurations to explain.
- Model margin at the 90th-percentile account rather than the median one.
- A rung is only a rung if it has a written trigger event.
references/pricing-memo-example.md›
# Worked pricing memo, and weak versus strong sections
The product below is fictional and every number is invented. It exists to show the level of specificity a finished memo needs - not to supply benchmarks.
**Situation.** A team of nine runs a hosted service that replays production traffic against pre-release builds. There is an Apache-2.0 self-hostable engine with roughly 900 known deployments; the hosted service has 40 paying teams on a legacy per-seat price of $25/user/month. Revenue is flat while usage has tripled, because customers drive the product from CI rather than from the console.
---
## Pricing - Replayer Cloud
### Inputs
Model already chosen: hosted open source, with the engine staying Apache-2.0. Buyer: a platform or QA lead with a team budget; procurement enters above roughly $25k annual. Cost per unit: $0.021 per replay-hour of compute, plus $0.004/GB of captured traffic stored, plus about 0.4 support hours per account per month. Free alternative's true cost: self-hosting the engine on the customer's own cluster runs about $340/month of infrastructure for a mid-sized team, plus an estimated 6 engineer-hours a month of operation and upgrade work - call it $1,100/month all-in at their loaded rate.
### Value metric
**Replay-hours**, with a small seat component retained for console access. Replay-hours move exactly when the customer gets more value, teams already track them in their CI dashboards, and the number correlates with our dominant cost within 8%. Rejected: per-seat alone (the collapse we already have - seat count is flat at 4.2 per account while replay volume tripled); per-repository (uncorrelated: one monorepo dwarfs thirty small services); per-test-case (perverse - it pushes teams to bundle tests, which hides real usage); captured-traffic GB (a storage proxy, not a value proxy, and it punishes exactly the teams capturing the most useful data).
### Ladder
| Rung | Contents | Price shape | Trigger to climb |
| ---------- | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------- |
| Free | self-hosted engine, or 20 hosted replay-hours/month, 7-day capture retention, community support | $0 | exceeding 20 replay-hours, or needing retention past a week |
| Starter | 200 replay-hours included, 30-day retention, 3 console seats, email support (2 business days) | $99/month + $0.34/replay-hour overage | a second team, or an admin who never runs replays |
| Team | 1,000 replay-hours included, 90-day retention, unlimited seats, roles, shared billing, basic SSO, 1 business day support | $690/month + $0.29/replay-hour overage, 15% off annually | security review, residency, or an SLA requirement |
| Enterprise | custom IdP + SCIM, granular RBAC, audit logs, EU/US residency, 99.9% SLA with credits, private deployment option, invoicing | starts at $30k/year, committed replay-hours at $0.21 | - |
### Free surface
20 replay-hours per month, 7-day retention, one project, no card. That comfortably covers a personal project and a proof of concept, and comfortably fails a team running replays on every pull request. Total marginal cost of the free surface at current signup rate: $1,850/month, 6% of paid gross profit; the agreed ceiling is 12%, reviewed quarterly. Abuse policy: 5 concurrent replays maximum, one free workspace per verified organisation domain, mining and load-generation workloads terminated on detection.
### Price points
Floor: $0.021/replay-hour marginal cost; at the 90th-percentile account (heavy captures, 3.1 support hours/month) the effective cost is $0.058. The 75% gross-margin target puts the metered floor at $0.23. Ceiling: self-hosting at $1,100/month for a team consuming ~1,000 replay-hours puts the binding ceiling at $1.10/replay-hour; the nearest vendor charges a flat $1,200/month with no self-hostable option. Chosen $0.29 on Team sits at 4.2x the 90th-percentile cost and 26% of the self-host ceiling - deliberately far below it, because self-hosting is our own project and we want the conversion to feel obvious. Evidence: usage-value correlation on 40 accounts (teams above 400 replay-hours/month renew at 96%, below 100 at 61%), plus 14 win/loss interviews in which price was decisive twice, both against self-hosting.
### Mechanics
Annual: 15% off, no stacking with volume breaks. Volume breaks published at 2,500 and 10,000 replay-hours/month ($0.26 and $0.23). Committed spend available from $30k/year at $0.21. Discount ceiling 20%, approvable only by the founder; anything deeper requires a multi-year commitment.
### Predictability
Public price page with all three published rungs and a calculator taking replay-hours and retention. In-product usage against the included allowance, projection to period end, and the same figures on a `/usage` API endpoint. Alerts at 70/85/95% and an anomaly alert at 3x the trailing daily average. Hard cap default on Free and Starter (replays queue and the workspace pauses), soft cap default on Team and Enterprise. Invoices itemise plan fee, included allowance, overage hours at the effective rate, and credits separately. A runaway-usage credit up to $500 is pre-approved for support to grant without escalation.
### Change plan
- **Existing 40 paying teams** on per-seat: grandfathered 12 months to 2027-09-01, then migrated to Team. Modelled impact: 31 accounts pay less, 9 pay between 15% and 60% more; those 9 get a call before the announcement and a 12-month price lock at the midpoint.
- **Free hosted users**: unchanged.
- **Self-hosted users**: unaffected, and the announcement says so in the first paragraph, because that community will read it first.
- **Notice**: 60 days, published on the blog and emailed, with the FAQ live the same hour. Founder answers the public thread; the pre-approved concession is the 12-month lock.
### Measurement
Free-to-paid conversion (baseline 4.1%, target 6% in two quarters), median days from signup to first payment (baseline 34), net revenue retention (baseline 101%, target 115% once the metric change lands), share of accounts within 15% of their included allowance, average discount (baseline 11%, ceiling 20%), gross margin per account (floor 70%), billing-related support tickets per 100 accounts. Reviewed monthly, full pricing review at 2027-03-01.
### Revisit triggers
- Gross margin per account below 70% for two consecutive months.
- Overage revenue exceeding 45% of total revenue, which would mean the allowances are set wrong.
- Any competitor publishing a self-hostable equivalent with a free hosted tier.
- More than 5% of accounts hitting the anomaly alert in a month, which would mean the cap defaults are wrong.
---
## Weak versus strong sections
### Value metric
**Weak.** "We'll move to usage-based pricing since seats aren't working anymore."
**Strong.** The version above: the unit named, the rejected candidates named with the specific reason each fails, and the evidence that the current metric is broken (seats flat at 4.2 while volume tripled). A rejection with a stated reason stops the idea being re-litigated every quarter.
### Free surface
**Weak.** "Generous free tier so developers can try it properly."
**Strong.** A number, what it does and does not cover, the total marginal cost as a share of paid gross profit, an agreed ceiling for that share, and an abuse policy. "Generous" is not a quantity, and nobody notices the cost until growth becomes expensive.
### Price points
**Weak.** "$690/month for Team, roughly in line with the market."
**Strong.** Floor with the 90th-percentile cost, the binding ceiling identified as self-hosting with its computation, the chosen number expressed as a multiple of both, and the evidence behind it. In-line-with-the-market is a description of someone else's decision.
### Change plan
**Weak.** "We'll grandfather existing customers for a while and announce it soon."
**Strong.** Every cohort named, the number of accounts that pay more with the size of the increase, a dated end to grandfathering, who calls the nine unhappy accounts first, and the pre-approved concession for the public thread. Vagueness here is what turns a price change into an incident.
references/value-metric-families.md›
# Value metric families
Contents: the six families · the hybrid stack · composite units and credits · seat-collapse diagnostics · a worked metric choice.
The value metric is the unit the invoice multiplies. Packaging and price points can be re-cut in a quarter; changing the metric rewrites every contract, every forecast and the metering pipeline underneath. Spend the analysis here.
## The six families
| Family | Unit examples | Fits | Breaks when | Meterability |
| ------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------- |
| Seats / users | named user, active user, admin | collaboration surfaces, IDE-side tools, consoles | value grows through automation, CI, service accounts or agents | trivial |
| Consumption | requests, messages, builds, minutes, GB stored or transferred, rows scanned, tokens | infrastructure and API products where your cost moves with the unit | the customer cannot forecast their own volume | needs real metering |
| Business outcome | transactions processed, the customer's monthly active end-users, endpoints monitored, devices managed | products whose benefit is legible in the customer's own business terms | the outcome is only partly attributable to you | usually easy, sometimes self-reported |
| Capacity / entitlement | concurrent jobs, environments, clusters, projects, retention window | products sized at deployment time; stateful systems | traffic varies wildly inside a fixed capacity | trivial |
| Percentage of a flow | share of payment volume or revenue processed | payments and money movement | the customer does not see the flow as yours | easy where the flow is yours |
| Flat per unit of software | per repository, per service, per product | simple tools, small teams, first pricing of a new product | the top of the market outgrows it and the bottom cannot afford it | none needed |
Read each candidate against the five tests in the skill body: value correlation, already counted, forecastable, non-perverse, cost-correlated.
## The hybrid stack
Most mature devtool pricing composes four layers. Add a layer only when it earns its place:
1. **Platform fee** - covers the fixed cost of an account and buys entitlements, support and governance. Add it when accounts cost you money before they generate usage.
2. **Included allowance** - usage bundled into the fee. Add it to make the modal bill predictable and to give the price page a single number.
3. **Metered overage** - captures growth above the allowance. Add it when usage varies by an order of magnitude across accounts.
4. **Committed spend** - an annual floor in exchange for a lower unit rate. Add it once accounts are large enough that both sides want a forecast.
A hybrid is not a compromise between seats and usage; it is the normal shape once a product serves both humans and machines.
## Composite units and credits
Vendor-defined units (credits, points, compute units) decouple the invoice from a shifting cost mix - useful when the underlying resources change often. The price of that abstraction is that customers cannot map it to numbers they already track, so it only works with:
- a published conversion table from credits to real units,
- a calculator that takes the customer's own numbers,
- stability: silently reducing what a credit buys is a price rise plus a deception, and gets read as both.
Without all three, an invented unit reads as obfuscation regardless of intent.
## Seat-collapse diagnostics
Per-seat pricing assumes one human ≈ one unit of value. Check for these before defaulting to it:
- Seat count flat or falling while usage rises.
- Shared logins, service accounts, or requests to buy discounted "bot seats".
- The product's own roadmap is about doing more work with fewer people.
- Expansion revenue arrives only through upsells, never through usage.
The repair is normally additive: keep a small seat component for the human surface, add consumption or capacity for the automated load. A wholesale swap re-prices every existing account at once and turns a metric fix into a churn event.
## Worked metric choice
**Product.** A hosted service that runs integration test suites on every pull request. Customers are engineering teams; the pipeline is triggered by CI, not by humans.
- _Seats_ - rejected. The people who benefit never log in; CI does. Seat count would stay near the number of platform engineers while test volume grows tenfold.
- _Test runs_ - rejected as the headline unit. Encourages teams to bundle tests into fewer runs, which is worse engineering and hides real usage.
- _Compute minutes_ - plausible. Tracks the vendor's dominant cost almost exactly, and teams already watch CI minutes elsewhere, so it is forecastable and already counted.
- _Concurrency_ - plausible. Teams size their own runners this way, it is trivially meterable, and it is stable month to month; it correlates with cost only loosely at low utilisation.
- _Repositories_ - rejected. Uncorrelated with value: one busy monorepo dwarfs fifty dormant repositories.
**Chosen architecture.** Concurrency as the entitlement (predictable, already counted, sold as tiers) plus metered compute minutes above a generous included allowance (captures growth, tracks cost). A committed-spend option appears above the point where a customer's monthly overage exceeds the platform fee.
SKILL.md›
---
name: devtools-pricing-strategy
description: Designs the pricing and packaging architecture of a developer tool - the value metric (seats, consumption, capacity, outcome, or a hybrid), free-tier limits, the tier ladder up to enterprise gating, price points bounded by a margin floor and the self-host and build-it ceilings, and a plan to change prices without a backlash. Use whenever someone asks what to charge for a developer tool, how to package tiers, where free ends and paid begins, whether to bill per seat or per usage, how to price against their own open-source edition, or how to raise prices safely - even if they only say the pricing page feels wrong. Not which business model to run - use samber/developer-relations-skills@devtools-business-model. Not pricing-page copy.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# 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](./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](./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](./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](./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 points, then place them
A number is defensible only when both bounds are written down. Method, research techniques and structural mechanics are in [references/price-point-method.md](./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](./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.
## Step 5 - Make the bill predictable
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.
## Step 6 - Plan the change (only when repricing)
Changing a live price is a trust event. Work through it cohort by cohort, and read [references/pricing-change-cases.md](./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.
## Step 7 - Write the pricing memo, validated section by section
```markdown
# Pricing - <product>
## Inputs model, buyer, cost per unit, free alternative's true cost
## Value metric the unit, the four rejected candidates and why
## Ladder the four rungs: contents, trigger to climb, price shape
## Free surface limits with numbers, total marginal cost, abuse policy
## Price points floor, binding ceiling, chosen numbers, evidence behind each
## Mechanics annual, volume breaks, commitments, discount ceiling
## Predictability caps, alerts, calculator, invoice shape, overage policy
## Change plan cohorts, grandfathering, notice period, migration path
## Measurement the metrics watched, targets, and the review date
## 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).
## 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.
## 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.
## 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](./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.
## 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.
## References
- [references/value-metric-families.md](./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](./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](./references/price-point-method.md) - floor and ceiling computation, research methods with their evidence strength, discount and commitment mechanics.
- [references/pricing-memo-example.md](./references/pricing-memo-example.md) - a full worked memo, plus weak versus strong versions of each section.
- [references/pricing-evidence-base.md](./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](./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.