In the world of subscription-based businesses, finding the ideal pricing model that maximizes revenue while keeping customers satisfied is paramount. The emergence of metered pricing has opened new doors for businesses to tailor their offerings to customers' unique needs and usage patterns. Stripe Billing's metered pricing is a game-changing solution that empowers businesses to implement dynamic pricing structures based on actual usage. In this article, we will explore the concept of Stripe Billing metered pricing and delve into strategies to leverage its benefits effectively.

Stripe Billing Metered Pricing: Understanding the Fundamentals

Stripe Billing metered pricing is a flexible pricing model that allows businesses to charge customers based on their actual usage. It enables granular tracking of usage metrics and empowers businesses to align their pricing with value delivered. By employing metered pricing, businesses can move away from fixed, one-size-fits-all plans and instead introduce pricing tiers that better reflect customers' varying consumption levels.

Key Features of Stripe Billing Metered Pricing

1. Granular Usage Tracking: Stripe Billing's metered pricing allows businesses to track usage metrics with exceptional granularity. This enables businesses to accurately measure and bill customers for the services they consume.

2. Dynamic Pricing Tiers: With metered pricing, businesses can create dynamic pricing tiers that adjust according to customers' usage. This ensures customers only pay for what they actually use, fostering transparency and fairness.

3. Flexible Billing Cycles: Stripe Billing offers flexible billing cycles to accommodate different business needs. Whether it's hourly, daily, monthly, or any other interval, you can align your billing cycles with your customers' usage patterns.

4. Automated Invoicing: Stripe Billing streamlines the entire invoicing process by automating the generation and delivery of invoices based on customers' usage. This saves time and reduces the likelihood of human error.

Implementing Stripe Billing Metered Pricing: Best Practices

Implementing Stripe Billing metered pricing requires careful planning and execution. By following these best practices, you can ensure a seamless transition to this innovative pricing model:

1. Analyze Your Customer's Usage Patterns

Before implementing metered pricing, thoroughly analyze your customers' usage patterns. Identify the key metrics that will drive your pricing tiers and evaluate how different usage levels impact your business costs. This analysis will serve as the foundation for creating optimal pricing tiers.

2. Define Clear Pricing Tiers

Create well-defined pricing tiers that align with your customers' usage patterns. Consider offering multiple tiers that cater to different levels of consumption. This ensures that customers can choose the plan that best suits their needs and encourages them to upgrade as their usage increases.

3. Communicate Transparently with Customers

Transparency is key when transitioning to metered pricing. Clearly communicate the benefits and mechanics of the new pricing model to your customers. Ensure they understand how their usage will be measured, the flexibility they will gain, and the potential cost savings associated with the metered pricing model.

4. Offer Usage Analytics and Insights

To enhance customer engagement and satisfaction, provide customers with detailed usage analytics and insights. By giving them visibility into their consumption patterns, you empower them to make informed decisions about their usage and optimize their spending accordingly.

5. Optimize Billing and Invoicing Processes

Leverage Stripe Billing's automated invoicing capabilities to streamline your billing processes. Automate invoice generation and delivery based on customers' usage to reduce administrative burdens and improve accuracy. Additionally, provide customers with self-service

6. Use a PriceOps approach to simplify any changes you need to make

It's one thing to come up with a price and configure Stripe Billing for the first time, but sooner or later you will need to deploy changes to your initial pricing model. A PriceOps bases approach to implementing pricing will pay dividends as your company growth. Tier is designed from the ground up to simplify the implementation and management of all types of pricing models.

It's one of those things that feels obvious when you see it, but until you do, it can be hard to grasp why it's important. The result is that we end up with the wrong abstraction trying to do double duty.

Just as you probably wouldn't use a relational database as a message bus, mixing the concepts of Pricing and Billing can bring disaster.

The Problem

Most companies approach their pricing implementation in the following way:

1. Choose a billing engine (Stripe, Lago, etc.)

2. Have a bunch of meetings where they argue about the best pricing model (and hopefully write it down somewhere!)

3. Configure the billing engine with the model they decided on (or realize it's too complicated, and go back to step 2).

4. Store all the information that the billing engine needs in their application database (identifiers for prices, products, customer IDs associated with each user, etc.), and add the required reporting logic in the application in the appropriate places.

5. Pray that no one ever has to touch it again. (Or failing that, hope you've got a new job somewhere else before that happens.)

Where does the pricing model live? Typically, it's smeared across a variety of loosely connected components, some of which store it as implicit assumptions.

• The billing engine

• The application code

• The CFO's spreadsheets

• The /pricing page

• The terms and conditions of various customer contracts

• Feature requests from PMs and PMMs who want to make changes

• The fallible human brains of everyone on the team

Billing Engine vs Pricing Engine

A lot of value can be unlocked by separating these two abstractions.

A Billing Engine is the component in the stack that bills customers. Its "one job" is to send an invoice at the right time, in the right amount, to the right buyer.

To do this, it needs to know some information about the customer, what thing they bought, the price they should be charged for it, and in the case of metered billing, the amount of that thing that they consumed.

A Pricing Engine is the component in the stack that manages and implements the pricing model. You can think of it as "the thing that does PriceOps". It knows what the various pricing plans are, and where they live in the Billing Engine, and thus can present a clean API surface for application code to create subscriptions and report usage.

To do its job (and prevent other components from trying to take over!) it needs to store the pricing model itself, and present a clean abstraction to the application code, billing engine, and all other technical and business components that need access to price information.

And perhaps most importantly, it must support making changes to the pricing model, without its abstractions leaking out to consumers.

Benefits

The most tangible immediate benefit of a comprehensive Pricing Engine is that it can simplify the process of setting up a Billing Engine, and reduce the amount of billing-related metadata that needs to be tracked and managed by application code.

While this is enough of a reason to use it, it doesn't always feel like a huge win. Integrating with a whole new component in the stack feels like adding complexity in one place to maybe save it elsewhere. Even if it makes your code cleaner and simpler, it's not that bad, right? Isn't "having too many customers and complicated deals" sort of a problem I can worry about when I'm rich and successful?

However, the trouble with this line of thinking (which all of us at Tier have learned through painful expensive experience) is that it can be very difficult for a company to become successful if they cannot easily iterate on their approach to pricing and packaging.

Streamlining pricing with a comprehensive Pricing Engine lets everyone focus on their specialty. This unlocks growth that would otherwise be lost to inefficient processes.

Why We Made Tier

What we've found is that the most experienced and insightful practitioners in this space follow exactly this kind of approach. That's how the concept of PriceOps was born.

Tier is a comprehensive Pricing Engine, which drives your billing engine and application code from a single source of pricing model truth, so that everything in your company can work in concert, even as your business changes and grows.

Tier Cloud

Tier Cloud is available in Alpha and is now running v0.10.0.

We’ve seen many users migrating from using tier serve to Tier Cloud. We encourage you to give it a try. It’s a seamless process. Just set TIER_API_KEY to your Stripe key, and the SDK will do the right thing. See an example here.

Join our support channel if you have any questions: https://tier-community.slack.com/archives/C04V6K76G7K

Model Builder Preview

Pricing.json has been a powerful way to model pricing. It's flexible, versioned and easy to share. As more companies adopt a PriceOps approach to pricing, it's important that non-technical members of your team have the ability to create pricing models.

Model Builder is a WYSIWYG pricing model builder that natively supports plan creation, collaboration, push, pull, and Checkout links.

We will have more to share soon, but if you are interested in testing Model Builder, please sign up here.

API Changes

Base prices support decimals

The plans["plan:name@0"].features["feature:name"].base may now contain decimals with up to 12 decimal places, which is the limit Stripe imposes.

Test Clocks

The API is now aware of Stripe Test Clocks and will pass test clock IDs along with requests to Stripe that support them, for any tier request that provides them. The SDKs have also been updated to make using test clocks easy.

Support for Metered+Per Unit pricing

Tier no longer uses tiered pricing for features with only a single tier that does not contain a base price.

Features with a single tier that has a base price of 0 will now be converted to metered+per_unit in Stripe. This is useful for models such as per-seat pricing and the change will have no effect on any existing features with single tiers in Stripe. See an example here.

Pricing Transforms

Tier models now support a Stripe’s division transform, which transforms the quantity before multiplying the base price to determine the amount to bill. Stripe restricts transforms to metered+per_unit (see above for how to create these features).

The transform takes two fields: by and rounding. The by must be an integer to divide by, and rounding must be "up" or "down".

To specify a division transform:

Updates to the /v1/phase endpoint

Trial field

The /v1/phase endpoint now returns a trial boolean that is true if the current phase is a trial.

End field

The /v1/phase endpoint now returns an end field specifying the date and time the current phase ends (not the period end).

SDKs

Cancel

Both the Go and Node SDKs now provide a cancel function on their respective clients, as sugar for canceling subscriptions, which has always been supported by scheduling a phase containing zero features. Once the phase's effective date passes, the org's limits will report 0 per feature’s limits.

Test Clocks

The Go and Node SDKs now support Stripe Test Clocks via the new Tier API addition.

Misc

The SDKs also include various bug fixes and additions for supporting new API changes.

CLI

Price link fixes

On tier push the resulting price links should no longer link to incorrect accounts or live mode, preventing confusion.

New Features

Listing Payment Methods

The new, experimental, /v1/payment_methods?org=org:acme API returns all payment methods associated with an org. It can be used with the latest addition to the /v1/subscribe endpoint to associate a payment method with an orgs subscription managed by Tier.

Subscription Payment Methods

Clients may now specify a payment method other than a customer's default payment method for the Tier managed subscription using the /v1/subscribe endpoint.

Use subscription-specific payment methods to avoid conflicts with other subscriptions that may have already or may later exist in your Stripe account that Tier does not manage.

Require Billing Address with Checkout

Users may now require a billing address when using Checkout. The Go SDK has been updated with a new RequireBillingAddress option on Checkout, and the CLI now accepts --require_billing_address as a flag to the subscribe sub command.

Bug Fixes

Tier 0.9.0 also includes some bug fixes, the most notable is a fix for canceling subscriptions without active schedules. Canceling a subscription no longer requires the subscription to have an active schedule.

We hope that these changes improve your experience with our product. Please let us know if you have any questions or feedback.

The v0.9.0 release is here: https://tier.run/releases.

As always, please let us know if anything doesn’t work as expected by filing issues at https://tier.run/issues/new.

Tier now supports Stripe Checkout using Tier plans, enabling both licensed and metered features in Stripe Checkout.

Here is the full rundown of the updates in Tier v0.8.0:

Checkout

Now in Alpha. We've added support for metered billing to Stripe Checkout! This means that the Node and Go SDKs as well as the CLI now support checkout.

To try it out, simply set the --checkout flag when using tier subscribe in the CLI. For example:

tier subscribe --checkout=https://example.com/success org:acme plan:pro@2

This will return a Stripe Checkout link that you can send to your customer, and you can even test it out by visiting the link yourself. Don't forget that you can set the optional --cancel_url flag to redirect users if they cancel out of the checkout session.

Clobber usage with tier report

The CLI subcommand report now accepts a --clobber flag for setting usage versus incrementing. This will help you keep better track of your usage and avoid any surprises along the way.

Create a test environment on push

You can now use the -c flag on tier push to create a new test environment, switch to it, and push the supplied pricing.json pricing model. This will return a link for the newly created environment.

To give it a go, try running:

tier push -c pricing.json

We hope you enjoy using Tier v0.8.0 as much as we enjoyed creating it!

Please head over to https://tier.run/releases to check out more changes and install options. As always, brew upgrade tierrun/tap/tier works too!

If you haven't used Tier yet, these resources are a good place to get started:

• Hello World! example - Step by step guide to adding Tier to your new or existing codebase

• Quick Start Guide - Step by step to getting up and running with Tier.

• Recipes - Example common pricing models and their corresponding Tier pricing.json representations.

• CLI Reference - Documentation for the Tier command line tool.

• Support for canceling subscriptions

• Free Trials support

• Detection and reporting of lingering Stripe idempotency keys

We are also releasing several bug fixes and enhancements which you can find in the release notes here: https://github.com/tierrun/tier/releases/tag/v0.7.0

Getting started with Tier

Please head over to https://tier.run/releases to check out more changes and install options. As always, brew upgrade tierrun/tap/tier works too!

If you haven't used Tier yet, these resources are a good place to get started:

• Hello World! example - Step-by-step guide to adding Tier to your new or existing codebase

• Quick Start Guide - Step-by-step to getting up and running with Tier.

• Recipes - Example common pricing models and their corresponding Tier pricing.json representations.

• CLI Reference - Documentation for the Tier command line tool.

This template will provision Tier as a private service on Fly.io.

Setup

Create an app out of this template.

sh flyctl launch --no-deploy

Then we set the stripe api key secret, and deploy it

sh flyctl secrets set STRIPE_API_KEY=sk_live_...

Usage

The app is now available internally at http://<app>.internal/.

Support

For further questions, please join our Community Slack.

This buildback installs and runs the Tier sidecar in Heroku dynos.

Install

heroku buildpacks:add https://github.com/tierrun/tier-run-buildpack

Environment

The below environment variables can be set using heroku config:set X=Y or via the Heroku dashboard.

• STRIPE_API_KEY: The required Stripe key (live or test) to use. If a live key is used, the -live flag will be automatically passed to tier serve.

• TIER_VERSION: The optional Tier sidecar version (default is 0.6.2)

• TIER_ADDR: The optional address the sidecar will listen on (default is 127.0.0.1:8080)

• TIER_RUN_DYNOS: An optional comma seperated list of process type names (e.g. "web") to run the sidecar in. If unset, all process types will run the sidecar.

Support

For further questions, please join our Community Slack.

Updated images will be available here:

• https://hub.docker.com/r/tierrun/tier/tags

and you can get the latest at any time via

$ docker pull tierrun/tier

Stripe Glossary available at github.com/tierrun/tier/wiki/Stripe-Glossary

Getting to know Stripe can take some time. Not only are there a lot of new concepts to learn, Stripe sometimes likes to use esoteric definitions for some things, such as "Good-better-best".

We have developed a Stripe Glossary that can be used as a reference. This is useful as you navigate Stripe's documentation and should help demystify the meaning of all these new terms you will encounter.

We will continue to update and evolve the glossary and hope it can be a useful resource for anyone who is in the process of developing their understanding of Stripe and its capabilities.

You can find the working glossary here: https://github.com/tierrun/tier/wiki/Stripe-Glossary. We welcome any suggested updates that you might have.

Here is the current list of terms, with direct links to their definitions.

• 3D Secure

• Aggregate Metered Usage

• Aggregation Mode

• Australian Business Numbers

• Billing Cycle Anchor

• Billing Threshold

• Client Platform

• Create a Session

• Custom Accounts

• Customer Portal (session)

• Dashboard

• Destination Charge

• Direct Charge

• Dunning Email

• European VAT Numbers

• Exclusive (Tax behavior)

• Express Account

• Freemium

• Good-better-best

• Graduated Pricing

• Inclusive (Tax Behavior)

• Inline Pricing

• Landing Page

• Licensed Usage

• Metered Billing

• Metered Usage

• Multi-currency Prices

• Package Pricing

• Pay-what-you-want Pricing

• Pause (Payment Collection)

• PaymentIntent

• Payment Form

• Payment Status

• Payment Window.

• Per-seat

• Pricing Page

• PriceOps

• Product Catalog

• Provision

• Quotes

• Revenue Recognition

• Reverse Charge

• Roll Ups

• SetupIntents

• Sigma (queries)

• Smart Retries

• Standard Account

• Standard Pricing

• Stripe

• Stripe CLI

• Stripe-hosted UI

• Stripe Ruby Library

• Stripe Tax

• Subscription

• Subscription Events

• Subscription Lifecycle.

• Subscription Phases

• Subscription Schedules

• Tax Exempt

• Tax Rates

• Tiered Pricing

• Trials

• Usage-based Pricing

• Variable Pricing

• Volume Based Billing

• Upsell

• Webhook

• Webhook Endpoint

• Webhook Events

The v0.6 release introduces a way to manage customer data stored in stripe for any Tier managed org.

To set the email, description, name, phone, or user-defined metadata, for an org, set the new info field for /v1/subscribe request. In addition to this change, a minimum of one phase for a /v1/subscribe request is no longer required.

The new fields are:

• description
• name
• phone
• email
• metadata

Additionally, the /v1/whois endpoint will now report up-to-date attributes if the query parameter include=info is present.

Both the Go and Node SDKs have been updated.

Please head over to https://tier.run/releases to check out more changes and install options. As always, brew upgrade tierrun/tap/tier works too!

If you haven't used Tier yet, these resources are a good place to get started:

• Hello World! example - Step by step guide to adding Tier to your new or existing codebase
• Quick Start Guide - Step by step to getting up and running with Tier.
• Recipes - Example common pricing models and their corresponding Tier pricing.json representations.
• CLI Reference - Documentation for the Tier command line tool.

• Switch preallocations: The tier switch -c command now preallocates switch accounts which means after the first switch account is created, subsequent uses of tier switch -c should be noticeably faster, like, complete in 10us fast! This is because it can now avoid waiting on slow API calls to Stripe.

• Plan immutability: Plans are now 100% immutable, as was originally planned. To upgrade all existing Tier plans to be 100% immutable, please run tier pull | tier push - 2 times; The second should produce output saying [plan already exists], which is your confirmation the migration was successful.

• Deep links: Push now outputs deep links to the corresponding prices in Stripe.

• Clean command: We added the tier clean -switchaccounts command. As you might guess, it cleans up accounts in Test Mode that were created by the switch command. The full command takes a duration of time for specifying the maximum age to use when considering an account for removal. Please see tier clean -h for more information.

Please head over to https://tier.run/releases to check out more changes and install options. As always, brew upgrade tierrun/tap/tier works too!

As we encountered these issues while building Tier, we decided to create tier switch to make it easy to spin up test and preview environments.

To learn more about the switch command and how to use it to avoid these issues, please read this post and give it a try today.

Inconsistent UI

One quirk of test mode is how it shows up in the stripe Dashboard. It’s easy to miss as you move between modes.

Test Clocks will usually isolate some objects from each other in the API, however, they do not show up that way when using the UI in Test Mode.

For example, if you list all customers in the API without specifying a test clock, you will only see customers without test clocks, but in the UI, you will see all customers with and without test clocks.

To distinguish between objects with test clocks, and those without, objects associated with a test clock get orange banners and/or an icon indicating they are part of a test clock. This is helpful, but it does not show any indication of which objects are grouped together by a test clock. To see this, you’ll need a new skill to operate and see in a new dimension, as we’ll quickly see:

In the above screenshot, there are two test clocks. Which customers are on the same clock? You can probably deduce which are associated by looking at the CREATED field, but what if I advance both clocks to the same time, or what if I ran two simulations each with nearly identical timelines? It all becomes blurry in the “normal” UI mode.

The only way to find out who is associated with what clock is to drill down to the test clock’s screen.

Having to keep this in mind as you navigate around the UI requires a new mental shift. One you must enter into and switch out of rapidly to gain a sense of what you're looking at depending on the screen, and how the things you're seeing all relate to each other in this new, additional dimension.

Product and Price Debris

Products and Prices remain unisolated from subscriptions associated with a test clock, as well as with subscriptions not associated with a test clock. This means products and prices will not be cleaned up when a test clock cleans up (if you ever clean up test clocks right away or just wait for them to GC on their own).

This may not seem like a big deal, but when you’re in a trial-and-error mode, working out the kinks of your pricing model, or running an integration test, this quickly becomes a major source of friction and frustration. That is because you cannot start a new simulation in a totally clean room, so you must manually delete each product and price you modified, otherwise it may interfere with the next simulation.

Key and ID Collisions

It's important to note that deleting products and prices can not happen if they have been burned into the audit log. In this situation, you can only archive them, but their IDs and lookup keys remain. This will often cause collisions across simulations and tests.

One of my favorite things about the product and price APIs in Stripe is that you can bring your own IDs and lookup keys. This allows you to assign a unique ID or lookup key that may only be used by a single product or price, respectively, at a time.

But if you can’t delete the price or product because a subscription has burned the price into the audit log, then the next test run might get an error if attempting to create a new price with the same lookup key or product with the same ID.

We can side-step this by namespacing our keys across tests, but this means our code must be very smart and careful to not let this behavior leak into production, and know how to plumb the namespace from the request received by the user all the way to stripe, or risk clobbering or duplicating objects on write and potentially reading back the wrong one. This isn’t ideal either.

The Manual process of Deleting Test Data

With the above gotchas in mind, we probably want to think about wiping the slate clean.

Unfortunately, there is no Stripe API to start with a fresh Test Mode. To do so programmatically requires cascading delete calls to the API per object, which is a slow and error-prone process.

Even if “done right”, you’re likely to run into the problem where you can’t delete prices already burned into the audit trail (which in production is a good thing, but the reality is different for your test environments as they become impossible to clean completely).

Keep the babies. Ignore the bath water.

When you hit that “Delete Test Data” button, you’re potentially erasing the artifacts of valuable lessons learned. Lessons that could be used to refer back to as you experiment with new approaches to your pricing and billing.

To keep these for reference, a common approach is to simply sign up for a new Stripe account. Maybe we call it “test2”, but this comes with new problems:

• Extra API keys to manage
• Extra login credentials to manage

This also does not fix the problem of throwing out our history, because this new account could end up with data as valuable as the previous, so away we go again to sign up for a new Stripe account, and then again, and so on.

We can delay decluttering our account drop-down by triaging all of those accounts until another day.

Continuous Integration

It isn’t hard to imagine getting into a situation where changing a price or a product in the “Holy” CI Stripe account wreaks havoc on CI. This usually happens because the once “pristine” account is now out of whack according to the code expecting Stripe to look another way.

If engineering was already sheepish about making changes to the pricing model, this just further adds ammo to their argument against it, because no one wants to breathe on that code, for fear of breaking it.

Make the switch

Tier is your new set of power tools for Stripe. By using the switch command, you can avoid the 5 gotchas of test mode and gain the power of a PriceOps-compatible approach to monetization while building powerful new workflows on top of Stripe. This gives you the best of both worlds: The power of Tier and the reliability and reach of Stripe.

With Tier, you get powerful features such as switch along with our SDKs, metering, and feature flagging style entitlement checking.

If you aren't already a Tier user, you can get started quickly and easily.

• Read Tier Docs
• Hello World! getting started example

tier switch is a command that creates on-demand, lightweight and isolated environments in Stripe. These are great for things like experiments and running integration tests. They are also perfect for sharing any results and collaborating with your team.

We were heavily inspired by many of our favorite tools. Like our first time opening a PR on GitHub, viewing changes in a live preview environment on Vercel, or rehearsing a schema change in a branch on Planetscale, these little features can make you, and your team, wildly productive. They do this by giving you the confidence you need to iterate quickly and in isolation, but with the ability to share and collaborate.

Visit https://tier.run/docs/cli/switch, and get started with Tier Switch now!

Before tier switch, our Stripe workflow looked much like everyone else

1. Manually switch to one of the special "test" mode accounts 🕺
2. Find and click on "Delete all test data" . . . then wait. 🗑️
3. Reset the idempotency key prefix 🔑
4. Run test or experiment 🔜
5. Take screenshot of result to share with team 📸

This isn’t just tedious, it’s messy and it’s brittle. Few of these steps can be reliably reproduced.

The missing Test Env for Stripe

tier switch builds on Stripe’s existing test mode but is designed to be more compatible with modern workflows. Each time you invoke tier switch, a new clean-slate and ephemeral test account is created. This environment is immediately accessible without the need to re-authenticate and can be seeded and ready for use in seconds.

tier switch will:

• Retain test results without impacting past or future experiments and tests
• Give each test and experiment its own dashboard, like it would have in production.
• Make this possible with a single Stripe account or org.

Why is this important? In our work developing Tier, we've been heavy users of Stripe's test mode. While it is as well designed and useful tool for an initial integration, it quickly became harder to use than we expected.

Make the switch

Tier is your new set of power tools for Stripe. By using the switch command, you can avoid the 5 gotchas of test mode and gain the power of a PriceOps compatible approach to monetization while building powerful new workflows on top of Stripe. This gives you the best of both worlds: The power of Tier and the reliability and reach of Stripe.

With Tier you get powerful features such as switch along with our SDKs, metering and feature flagging style entitlement checking.

If you aren't already a Tier user, you can get started quickly and easily.

• Read Tier Docs
• Hello World! getting started example

TL;DR

The schema for pricing.json files is available at https://www.tier.run/docs/pricing.schema.json. Plug that URL into whatever tool you use to validate JSON, and associate it with pricing.json files.

VS Code

More info on editing JSON is available in the VSCode docs.

1. Open the User and Workspace Settings menu.

2. Click Extensions and then JSON in the left sidebar.

3. Look for the option "JSON > Schema Download: Enable" and ensure that the box is checked.

4. Underneath that, look for the option "JSON: Schemas" and click "Edit in settings.json"

1. Add the following section:

    "json.schemas": [
      {
        "fileMatch": ["pricing.json"],
        "url": "https://www.tier.run/docs/pricing.schema.json"
      }
    ],
   

Here's the result:

vim/neovim and COC

If you use vim with COC, you can add support for validating pricing.json files like so:

1. Ensure that coc-json is enabled. You can do this by running :CocInstall coc-json or by having something like the following in your ~/.vimrc:

    let g:coc_global_extensions = ['coc-json']
   

2. Run :CocConfig to option the configuration file for coc. (By default this is ~/.config/nvim/coc-settings.json.)

3. Add the following field to the object there (if it already exists) or add it as a new top level object:

    {
      "json.schemas": [
        {
          "fileMatch": ["pricing.json"],
          "url": "https://www.tier.run/docs/pricing.schema.json"
        }
      ]
    }
   

Here's what it looks like in action:

That's it!

The example app is exceedingly simple, but the principles are flexible enough to easily be put into practice in much more complicated applications.

All of the code for this demo is available on GitHub, at tierrun/tier-node-demo.

The App

The application we'll be monetizing is a simple temperature conversion app. If you give it a Fahrenheit temperature, it'll convert it to Celsius, and vice versa. This is provided via a simple site built on express.

To see the app as it exists before adding any Tier integration, check out the pre-tier branch.

Nothing Up Our Sleeves

Nothing described here relies on any services running on https://tier.run, or anything at all other than Stripe.

You can think of Tier as a very fancy Stripe client that manages metadata and connections. It sets up your system so that the path of least resistance is also the path of optimum PriceOps.

Setting Up Tier

First, we'll have to install the Tier binary. On macOS machines, you can do this with Homebrew:

brew install tierrun/tap/tier

Binaries for major architectures can be found on GitHub.

You can also install it using go version 1.19 or later:

go install tier.run/cmd/tier@latest

Once it's installed, use the tier connect command to give Tier access to your Stripe account. By default, Tier will only work on test mode Stripe data, using a restricted key with permissions that you can easily lock down.

Alternatively, you can set the STRIPE_API_KEY in the environment, if you have a key that you'd like Tier to use.

Installing Tier SDK

In the app, we install the Tier SDK by running:

npm install tier

f32b5b4

Create Pricing Model

We create a pricing model by writing a pricing.json file.

The pricing model is a simple free/pro scheme. Free accounts get 10 free temperature conversions per month, then they have to upgrade.

Pro accounts cost $10 per month, and get 100 conversions per month included with that base price. Beyond that, they will be charged $0.01 per conversion.

To do this, we define two plans in our pricing.json file with the appropriate tiers. We're calling the feature feature:convert.

{
  "plans": {
    "plan:free@1": {
      "title": "Convert (free)",
      "features": {
        "feature:convert": {
          "title": "Temperature Conversions",
          "tiers": [
            {
              "upto": 10,
              "price": 0
            }
          ]
        }
      }
    },
    "plan:pro@1": {
      "title": "Convert (Pro)",
      "features": {
        "feature:convert": {
          "title": "Temperature Conversions",
          "tiers": [
            {
              "base": 1000,
              "price": 0,
              "upto": 100
            },
            {
              "price": 1
            }
          ]
        }
      }
    }
  }
}

The most important part is that plans are named like plan:<name>@<version>, and features start with feature:. But if you try to do something against the rules, Tier will give you an error telling you what's wrong.

When we want to change this scheme, we can add a new plan (or a new version of the free or pro plan). Any customers still on the old version will be unaffected.

To push the pricing model live, run:

tier push pricing.json

3f6e7cf

The /pricing Page

In order to create a nice little two-column page showing the plan options, we can pull the highest version of each plan with the tier.pullLatest() method, and hand that object off to our template to turn into HTML. I'm using EJS in this example, because it's so dead simple to throw together an example like this, but you can of course do the same thing with React, nunjucks, or any other templating system.

Note: beware that this is definitely some demo magic. We're just sorting the plan versions lexically, but in practice, you'll probably want a config or some other system to say what the "public" version of any given plan is, so you don't end up with something like plan:free@zzzZZZ:final2.final.latest.final. The tier.pullLatest() method is marked as "experimental" in the Node SDK for this reason, we expect to add more utility in this area soon.

The important part is that we're not reading the file from disk, or hard-coding the plan details into our app. Instead, we pull from the single source of truth, and let that drive the rest of the system.

c0a7859

Subscribing Users To Plans

Stripe doesn't really have a concept of a "plan". There are Products which have Prices, and multiple Price objects can be attached to a customer's subscription.

Each of those Price objects has a unique identifier. So, if you want to treat multiple "Prices" as a "plan", you have to keep track of them to use the right ones when creating a subscription. As you add more tracked features, and test more different iterations of packaging them up into plans for customers, the complexity increases geometrically.

Thankfully, using Tier, we can just do:

await tier.subscribe(org, plan)

All of the Price objects associated with the plan will be attached automatically.

The org is an opaque string that identifies the customer. It must start with org:, and it must be unique, but you can use whatever identifier you use for customers in your system already. These are all perfectly acceptable: org:user@email.com, org:beefcafebad1d3a, org:213415-221321-4321. There's (almost) never any reason to deal with the Stripe Customer ID.

The plan is the plan:<name>@<version> from your pricing.json model. You should not hard code this! In the demo, you'll note that we get it from a POST request when the user clicks the "Subscribe" button on the programmatically generated pricing page.

No matter how many versions of your plans you have, the plan identifier is all you need to create the correct subscription for your customer.

Note: you can still create subscriptions using Tier that mix and match any prices and entitlements you like. We'll cover that in a future "advanced usage" blog post, as it's out of scope for a "Hello, World" app such as this.

ecb1cf1

Reporting Usage

Just like with subscriptions, rather than having to track Price objects to know how to report feature usage to Stripe, using Tier, we just need the org:... identifier and the feature name from your pricing model.

await tier.report(org, 'feature:convert')

The default count is 1, but if you want to report more than 1 of something, you can just pass n as the third argument:

await tier.report(org, 'feature:morethanone', 100)

In this demo, we're reporting feature usage right at the point of delivery. For many use cases, that's perfectly fine. But, for example, if you're tracking download bandwidth or some other high-volume metric, you can of course roll that up and report it in a batch at any cadence that makes sense for your application.

The caveat, of course, is that the usage data you pull from Tier won't be fully up to date if you haven't yet updated it.

18bfb50

Limiting Access

We said that users on the free account can only get 10 conversions per month. In order to make sure they haven't gone over (and that they're on a plan that has access to the feature at all!) we can call the tier.limit method, like this:

const usage = await tier.limit(org, feature)

This method will return an object with used and limit fields, which you can check to see whether the feature should be enabled.

Again, there's no need to keep track of Customer or Price objects, or even know what plan a user is subscribed to. Just check whether they have access to the feature, and if so, give them the feature.

920f8c1

Changing Plans

You can try out changing the pricing model any time you like, as often as you like:

tier push pricing-2.json

When you do this, the /pricing page gets updated with the new version of the plan, but importantly, the customer's plan isn't changed. With Tier, grandparenting in your existing userbase is the default, so you never have a situation where you try a different price, and make everyone upset.

In fact, you could even have multiple versions of a plan living side by side, and see which one encourages better user behavior or gets better conversions.

Collecting Payment Info

For this, we still will need to go direct to Stripe, so that the user can submit their credit card information directly to Stripe from their browser, using stripe.Elements.

Thankfully, the tier.whois(org) method will give us their Stripe Customer ID.

cd8b1ae

That's it!

In this demo, we took a working application and monetized it, without ever having to worry about managing Stripe object identifiers, and any future change to our pricing model is trivial.

There's a lot more documentation available on the Tier website. Try it out, and let us know what you think!

Think about your design partner program as a secret club where you only want to let a specific group of customers in.

It is difficult and time-consuming to make a design partner successful, so you want to keep the bar high for participation. You also need to be sure your partner understands the nature of what they are signing up for (more on that in a later post).

What makes a good design partner?

A good design partner understands what makes you unique

The ideal partner is motivated by a design to make your vision a reality. Why are you building something that is better than what can be purchased from a competitor?

As part of your acceptance criteria, you need to be confident that your prospect understands this clearly. If they don't, they go into your regular sales/engagement funnel.

Design partners have a selfish motivation

It's not enough that they want to see you succeed, a design partner needs to clearly understand the benefits for themselves.

Of course, every customer needs to understand this, but a design partner needs to be able to justify an above-average commitment of time and attention. That's a high bar and if you don't meet it then you will find your design partners lose interest quickly.

Regular check-ins are critical to maintaining excitement and alignment around your program. Without that, customers will lose interest and find it hard to continue to invest their time.

Design partners can prioritize work

Your partner needs to be able to dedicate their own time and often their team's time. That often means that the right design partner isn't an IC or even an executive. Often it's a Product or Engineering Manager who desperately wants to solve the problem you are addressing

Design partners engage quickly

One way prospects show their commitment is with their money. The other way is with their time and attention.

How do you know if a prospective partner is serious to not? They don't waste time.

If they join your Slack, show up for recurring meetings, and prioritize the work they need to do to unlock great feedback, then you've found yourself a diamond in the rough.

Design Partner qualification checklist: 📝

1. Understands what makes you unique
2. Have clear and defined goals for themselves
3. Can prioritize the work needed.
4. Engage quickly and reliably

Now that you know who and what to look for, it's time to go find these mythical unicorns.

Hold on tight, now things are about to get real!

Sign up for our newsletter to get all future articles in the Design Partner series, along with our templates and step by step guide to help get you started.