Why Heroku-like pricing models are hard to build

In terms of pricing, Heroku is one of the most flexible models. Many API and cloud companies we talked to want to take the same path. But, what does it look like exactly?

Creating a Heroku-like pricing model is hard, mainly because a single customer can have multiple plans, with different prices and add-ons (i.e. one plan for each application - see recording below). It’s the exact opposite of the traditional SaaS model with one plan per customer and it’s even harder if you add usage-based features on top of it.

However, this pricing model can be very useful if your customers can create different workspaces, projects or repositories. Let’s take a look.

‍

When is it useful?

Implementing a Heroku-like pricing model is useful if your platform allows customers to create multiple projects, workspaces or repositories. Here are some examples:

• ‍Webflow: one plan per website (subscription);
• ‍Shopify: one plan per store (subscription + transaction fees);
• ‍Segment: one plan per workspace (subscription + charges based on the number of monthly tracked users);
• ‍Algolia: one plan per application (pay-as-you-go); and
• ‍Column: one plan per module (specific usage-based charges for each module).

This model also makes life easier for design and marketing agencies, as they often use their account to create a new project for each of their clients. When they receive their invoice at the end of the billing period, they want to see a breakdown of costs per project so that they can bill their clients accordingly.

‍

Assigning multiple subscriptions to a single customer

A single customer can have multiple subscriptions and the same plan can be used for several projects. For example:

‍

When assigning multiple plans to a customer, your billing system needs to return a dedicated subscription_id for each plan. This identifier will be your watchtower as it will help you keep track of billing data.

Information in the subscription object includes (but is not limited to):

• Assigned plan;
• Creation date of the subscription;
• Boundaries of the subscription (i.e. start date and end date); and
• Status of the subscription.

With Lago, a new subscription object is generated each time you assign a new plan to a customer:

‍

Usage-based components split across multiple subscriptions

Complexity increases when usage-based features are consumed by the customer across multiple projects, workspaces or repositories.

Imagine a product whose price depends on the number of API calls. The price of a single API call can vary depending on the associated plan, as described below:

‍

Fortunately, as each project has its own subscription_id, it is now easier to link each usage-based event to the right project and calculate the corresponding charge.

‍

Therefore, if the customer has several projects for which they use the same API service, you will be able to allocate each call to the right project.

‍

The importance of display names for subscriptions

As mentioned before, several projects can share the same plan (e.g. two projects on the free plan). Therefore, there is a downside to displaying only the plan name on the invoice as your customer won’t be able to know which project is linked to which plan. To differentiate each subscription on the invoice, you need to add display names.

If we go back to our example with Heroku, we can see that the invoice displays the name of each project and the associated plan. It’s good practice to send the name of the workspace as the display name on the invoice, as it gives more visibility to your customers.

‍

Issuing consolidated invoices

Your customers can now have several plans and you’re able to monitor usage for each subscription. Great!

Unfortunately, here comes the hardest part… generating invoices.

As receiving dozens of invoices each month can feel overwhelming, most of the time, your customers will want to receive a consolidated invoice. This raises questions that will tear your hair out:

• What if the plan intervals are different (e.g. one plan is paid monthly and the other annually)?
• What if some plans are based on calendar dates and others on anniversary dates?
• Does a coupon apply to all subscriptions?
• Do we need prepaid credits that are subscription-specific?
• How do we handle upgrades and downgrades?

Let’s go back once again to Heroku’s example. Each month, their customers receive a consolidated invoice. To simplify the consolidation process, Heroku bills each project starting the 1st of each month. We recommend that you use the same approach, as it’s easier to consolidate an invoice with multiple plans when their billing periods are the same.

However, you may have yearly and monthly plans. The way Lago handles this situation is described in the tables below.

‍

Billing can become quite complex when customers have multiple plans and you also need to manage upgrades/downgrades, coupons and prepaid credits, so we hope you'll find this feature useful. Have a look at the feature documentation here.

‍

To learn more about Lago's new functionalities, check out our product updates or get in touch with our team.