🤑 Managing billing & subscriptions for a 'no code' SaaS - Issue #6

Happy Friday!

Welcome to all my new subscribers, excited to have you joining me for the ride.

This week I’m going to be going through how best to manage subscriptions & billing in your ‘no code’ application built on Bubble.

You might think this is just as simple as charging a customer’s credit card via Stripe, but there is a lot more you need to think about.

• How do you manage your app’s plans, and monitor each customer’s usage according to their plan?

• How do you encourage users to upgrade from a freemium plan to a paid one?

• How do you manage upgrading and downgrading their accounts, and adjusting their access rights based on that?

• How do you manage your subscription email notifications & automate email flows for specific circumstances.

I’m going to cover all of these today by taking you through how I handle them in by Bubble app - UserLoop.

Let’s dive in!

First thing’s first - how many subscription plans is your app going to offer?

Depending on what kind of SaaS you’re building, you might have one or several payment plans your users subscribe to.

If you’re going for a freemium model this will start with a totally free plan and go up from there.

SaaS pricing is a massive topic in itself, so to keep things simple I’m just going to use my app’s plans as an example.

UserLoop's Pricing Plans

As you can see the plans range from free to $99 per month.

The primary difference between each plan is…

• The number of email surveys they are able to send

• Access to premium features like ‘checkout surveys’

Given we have different plans with different limits and features available, we need to build some logic in Bubble to make sure customers are only able to access the features they are entiled to.

How do you manage your app’s plans, and monitor each customer’s usage according to their plan?

To create and manage the plans available for your app, I suggest using Bubble’s Option Set feature.

This lets you set up all the different plans your app has, making them easily accessible from anywhere in the editor or workflows.

Here are how my plans are set up as Option Sets in Bubble…

Plans as Option Sets in Bubble

As you can see at the bottom, I have 4 plans (Free, Starter, Scale, Premium) and each plan has a load of fields attached to it.

These fields are important, as you use them to store the specifics of each plan, such as how many emails that plan is allowed to send and the value of the plan in $.

Storing all this data in option sets means if you want to change any of these values later, it’s super easy.

The data from these option sets even power my pricing grid itself, so any changes I make are reflected everywhere.

We need to create a field on your main ‘Company’ record which links to a plan. That way we always know which plan a user’s company is linked to.

That will mean we’re able to do things like limit access to specific features later on.

If your plans are linked to usage in some way, you need to store all that data in a table.

For example, my app limits the number of emails a user can send depending on their plan allowance.

Therefore, I need to have a table where I store a record every time a user sends an email. My table is called ‘Sends’ and a new record is created linked to the user’s ‘Company’ every time they send an email.

That means we’re able to do counts on how many emails a user has sent each month, and compare that to what their plan says they are allowed to use.

How do you encourage users to upgrade from a freemium plan to a paid one?

If your app has a fremium plan, you will want to make sure you are encouraging users as much as possible to upgrade to one of your paid plans.

There are a few ways of doing this in your application.

The first one we are going to look at is through prompts in your UI.

Here is a prompt which appears in the UserLoop UI when a user has exceeded the number of emails they are allowed to send with their current plan…

UserLoop Upgrade Prompt

As you can see, it’s telling the customer they’re over their allowance and need to upgrade to a paid plan to keep using the product.

There’s a button to our plans page where they can upgrade.

Now - what’s the logic we use to make this warning appear?

This is a group which is hidden by default and only shown when a specific rule is met.

Here’s how the rule looks in Bubble.

Rule to decide when an upgrade prompt is shown.

So what is happening here?

We’re asking Bubble to do a count of the number of emails this user’s Company has sent since the start of this month.

If that amount is > (greater than) their plan’s allowed number of emails, the prompt is set to be visible.

This all means we’re only ever showing this prompt to customers who need to upgrade.

We can also use this same logic in our backend workflows to make sure no emails are allowed to be sent when a user is over their capacity, so you can use this logic in a lot of different places.

How do you manage upgrading and downgrading their accounts, and adjusting their access rights based on that?

Let’s take a look a look at users upgrading and downgrading their accounts.

As you can see on my billing page I have a pricing grid.

The grid tells the user which plan they are currently on, how much capacity they’ve used and how to cancel their current plan.

As you can see in the image below, I have a loading bar which I use to let the user know how much of their capacity they have used this month.

Billing page showing current plan and capacity.

Here’s the logic of how to build a usage progress bar like this…

Usage Progress Bar Logic

To calculate what percentage of this progress bar is filled we are asking Bubble to do the following…

• Get a count of the number of emails the current user’s company has sent so far this month

• Divide that number by the number of emails the company’s plan is allowed to sent

• Times that number by 100 to give us a percentage

• Round that value to 1 to give us a nice clean percentage like 55%

We can then apply additional logic such as turning the bar red when the value is over 100%

The great thing is, all this is dynamic. So it will update in real time when a user changes their plan.

Here’s an example of a user upgrading their plan by making a payment on Shopify, then seeing their usage graph and current plan update…

All this makes it very easy for the user to see how much of their plan they’ve actually used and why they need to upgrade to one of your paid plans.

How do you manage your subscription email notifications & automate email flows for specific circumstances.

The final topic I want to touch on is automated email flows.

It’s important to let your users know by email if they need to upgrade their plan.

If you never tell them they’re nearing their plan’s limit, they’re never going to upgrade and pay you money!

So I always recommend setting up an automatic email flow which is sent to your users when they are nearing their plan’s limit.

To achieve this, I use a recurring event.

This recurring event runs every day at the same time on my app, and is looking for companies who have used over their allowance using the same logic we used above to show a warning.

If a company is using over their allowance, I add them to a group on Mailerlite using a simple API call.

I then have automations set up in Mailerlite which then send a series of emails to the customer (with increasing urgency!) telling them that they need to upgrade to a paid plan.

Here’s how it looks in Mailerlite…

Upgrade Prompt Emails in Mailerlite

As you can see, once the user has been added to the group by my API call from Bubble, Mailerlite handles sending them the series of emails automatically.

I can even easily see in Mailerlite which customers have opened the email message.

If you do take this approach, it’s also a good idea to set up another API call from a Backend Workflow to remove the customer from your Mailerlite group when they start a new subscription!

Thanks for reading!

Hope you found this issue interesting, please do drop me a line if you have any questions or other topics you would like to see covered in the future.

This week I wanted to give a particular shout-out to subscribers Kieran and JJ for their supportive Tweets, ridiculously thankful for your support!

I’m honestly humbled by the response I’ve had since starting this newsletter. So many people have reached out to me to share your own no code journeys and that you’ve found some of the content in this newsletter helpful.

I’m going to do my best to keep things interesting and as useful as possible.

If you have any friends building with nocode I’d really appreciate a share on Twitter! 🙌

Thanks again, until next time!

James 😁