Designing Usage-Based Pricing: Four Decisions and Core Meter Properties

Founders often misstep when implementing usage-based pricing. This playbook details the four critical design decisions and three essential properties of an effective meter, drawing from real-world examples.

Implementing usage-based pricing (UBP) requires navigating four distinct design decisions, a process many teams mismanage, leading to costly redesigns. Arnon Shimoni, writing on dev.to, identifies these decisions as core to avoiding common pitfalls. The challenge lies in moving beyond abstract "value alignment" to concrete choices, such as whether to meter API calls or successful transactions.

The Four Decisions of Usage-Based Pricing

Shimoni characterizes usage-based pricing as "four decisions in a trenchcoat." These foundational choices dictate the entire UBP structure. The first decision is what to meter. This involves identifying the specific action or resource consumption that directly correlates with the value a customer receives and the cost incurred by the provider. Examples include API calls for Twilio or OpenAI, gigabytes for Snowflake or Datadog, and events processed by Segment.

The second decision defines the unit to charge for. This unit must be measurable and consistent. For instance, DeepL charges per character translated. The third decision concerns the rate card structure. Pricing can be linear, tiered, or volume-discounted. The final decision addresses commits and overages, determining whether customers pay as they go, use prepaid credits, or commit to a minimum with additional charges for exceeding that commitment. These four elements combine to form the complete UBP model.

Good Meter Property: Value Correlation

A good meter directly correlates with the value a customer receives from the product. Shimoni emphasizes that if the customer's bill increases, their business value derived from the product should also increase proportionally. Adyen, for example, charges per successful transaction, not per API call. This ensures customers perceive the cost as fair because they only pay for outcomes that generate revenue for them. Snowflake similarly charges per second of compute, aligning cost with actual processing utility rather than mere query count. When this correlation breaks, customers perceive the bill as an "even bigger tax" and are more likely to churn or negotiate down their spend.

Good Meter Property: COGS Correlation

The meter must also correlate with the provider's cost of goods sold (COGS). Ignoring COGS alignment can severely impact gross margins. For an AI company, inference costs are typically per-token. If pricing is structured as a flat per-request fee, a customer sending very long prompts could quickly consume significant resources without a corresponding revenue increase. Shimoni cites a recent story of a consultancy reportedly spending $500 million on tokens, illustrating the potential for misaligned meters to create substantial financial liabilities for the provider. The meter must reflect the underlying infrastructure or operational costs to maintain profitability.

Good Meter Property: Auditable Metering

Transparency and trust are paramount in usage-based models. Both the provider and the customer must be able to independently count the usage and arrive at the same number. This ensures billing accuracy and reduces disputes. An auditable meter provides clarity, preventing situations where customers feel they are being overcharged without a clear explanation. The source text ends abruptly here, leaving the full implications of auditable metering unexplored.

What We'd Change

The framework presented by Shimoni offers a structured approach to UBP design, particularly useful for founders grappling with the initial choices. However, the piece is a high-level conceptual guide rather than a tactical implementation blueprint. It correctly identifies critical decision points but provides limited guidance on how to execute these decisions, especially in nuanced scenarios. For instance, while "auditable" is a crucial property, the article does not detail specific tooling, logging practices, or customer-facing dashboards required to achieve this transparency in practice.

The article's abrupt conclusion leaves the "auditable" property, and potentially other properties, incomplete. A comprehensive playbook would require expanding on the practical implications of each property and providing actionable steps for implementation. Furthermore, the piece focuses heavily on the initial design. It does not address the iterative nature of pricing, including how to test different meters, collect customer feedback, or adapt pricing as the product evolves or COGS shift. Founders need strategies for A/B testing pricing tiers, managing grandfathered plans, and communicating changes to existing customers, none of which are covered. The examples are strong, but the advice could benefit from more specific, less abstract implementation details.

Designing usage-based pricing demands precise decisions on metering, units, rate cards, and commitments, underpinned by meters that align with both customer value and internal costs. Ignoring these foundational choices often leads to costly rework and customer dissatisfaction. Founders must move beyond general principles to implement auditable, transparent systems that build trust and scale with their business.

Pull quote: “”