How to setup the logic for a full access free trial using Bubble and Stripe
Show your customers the best features of your app, for a time limited time.
There are many opportunities for visitors to your site to NOT become paying customers. You have a very short window to show them the value your product is offering, so it’s important to make the most of it.
To date my service at RosterBuddy.app assigns all new users to the free tier plan, which has some intentional limitations on the functionality available. It then is up to me to persuade them over time that an upgrade to the paid plan would be worth their while, but I’d like to flip this logic on its head.
I intend to instead default new signups to the fully functional ‘Team’ plan, with no limits in place, then over the course of a month they can experience the benefits of this, and then either start paying, or downgrade to the free tier.
I’ll document how to do this below:
The Logic
Here is the short version of the logic I want to set up for Free Trials:
person signs up : user account is created, plan is the free one
onboarding wizard: explain 1 month free trial, button to continue
stripe dashboard : enter credit card details, reminded no charge for 1 month, can cancel any time
redirected back to continue onboard wizard : name team, invite teammates etc
after 1 month: either remain on the paid plan with real $, or cancel the trial and revert to the free plan
Note 1: It is useful when planning to just write out a simple list like this. Using the shortest version of the plan is really quick to write up, and often more usable that a long detailed mega plan.
Note 2:
“..users who provide a credit card number generally have done more up-front research and are, essentially, committing to pay unless they affirmatively declare they are dissatisfied with the product”
See here for more info https://stripe.com/en-nz/atlas/guides/business-of-saas.
Where/When/How
Right.. this seems doable, but exactly how do I call this functionality. I know that I want this subscription trigger to happen straight after the new customer has signed up. That means there is a current user context, I know their email address, and they can begin trying the full functionality of the product early on, without an additional ‘starting a trial’ hurdle.
I also know that I want to require the customer to provide their credit card details before they get through the onboarding process and start to configure their team/invites/tasks etc.
So, I currently have a Welcome screen which manages onboarding. It consists of 1 page, with one popup. Both of the page and popup change their content depending on steps that the customers take, as part of onboarding. All I need to do then, is add 1 more step, which starts the trial. As the Stripe docs say, if the credit card is not supplied, then the workflow stops. This is great, as any partial onboarding process that is abandoned and later resumed, should present the same state.. ie. the customer just continues through the process.
Bubble Workflow
Bubble has good default integration with Stripe, via the ‘Payment’ options within a workflow Action:
I’ve not previously used any of these actions in my app, despite having written a previous article about Stripe, as the actions I was using came via the Stripe Plugin itself. What you can see though in the image above is ‘Subscribe the user to a plan’ so let’s dig in to that. From the docs here https://manual.bubble.io/core-resources/bubble-made-plugins/stripe#end-of-the-trial you can see that the concept of ‘end of the trial’ is present, which suggests that a trial is functionality that Stripe can manage for us.
If we add this action to our onboarding workflow:
Payment | Subscribe the user to a plan
we are presented with this interface
Lets go through these settings one by one:
‘Apply this action to the current user’ > yes, we’ll enable this, but also make sure that this workflow only runs ‘after’ a customer has signed up, and is logged in. Without that in place, there would be no current user context.
‘Update existing subscription'> yes. For new customers, this will allow creation of a new subscription, and for existing customers, it will update the subscription. We’ll handle repeat-trial’s in logic elsewhere in the app, by recording the number of free trials on each user record.
‘Subscription ID’ > I’m leaving this blank. I’m ‘nocoding’ for the happy path initially, i.e the most common scenario. I’ll work on edge cases later if required, for example if a customer has an existing subscription id AND later also wants a free trial
‘Dynamically Specify Plan’ > Enable this checkbox. In my case I have a Data type called Plans, which contains 3 plans. Enabling this checkbox allows me to select the correct plan based on a search.
‘Subscription type’ > I’m choosing ‘Pick one plan’. I have only 1 paid plan, so that is the least complicated action at this point.. to specify it, and only it.
‘Stripe plan name’ > Here I’m doing a search on my Plans Data Type, with a constraint based on the name of the plan that is my Paid plan (‘Team’), then selecting the first item from that search result [there is only 1 anyway, due to the constraint], and then I’m selecting the Price ID field. Weirdly, Stripe identifies products by their price id, rather than their product id.
‘Quantity’ = 1 . I just want 1 subscription per 1 customer.
‘Allow promotion codes’. I’m leaving this unchecked. This seems to be likely related to enabling coupons codes, presumably that a customer could type in as part of a sign up flow. I’m glad to see this, as I think this feature was released after I wrote this article about coupons.. ‘How to create discount coupons for your Bubble app customers using Stripe’.
‘End of the trial’ > here is the great bit. You decide how long the free trial lasts for. Since my app has a weekly activity cycle [household chores], I think that ~4 weeks would be a good time for customers to try it out for free. I’ll specify this as the current time plus 1 month:
Current date/time + (months):1
‘Add tax rate to checkout’: I’m disabling this, as my current SaaS isn’t yet profitable, and I’m aware of my local tax regulations in this regard. However, make sure that you understand your own tax obligations and make the right choice here. Stripe has added some good features lately & I also recommend you bookmark this article from Paddle about SaaS and Tax https://paddle.com/blog/global-sales-taxes-for-software-companies-what-you-need-to-know-to-sell-internationally/
‘Do not show success message’ > for now I’m leaving this enabled for testing, but later will likely handle this in the UI, rather than as a popup once I deploy to live.
OK.. after all that, here is my config:
And I have another action which follows this, that does the job of recording some of the data that results from this Subscription activity
With this constraint of the search for a plan, which essential changes the customers Plan to the fancy one :)
You can see I’ve added a FreeTrialsStarted field here, which I’ll use in the future to prevent customers signing up for multiple free trials.
Also note that the price value that is returned from Stripe is in cents, even though you define this as dollars.cents in the stripe UI. I therefore made a decision to store price values as cents in my database, and I handle this in the UI via ‘divided my hundred’:
States
It is worth a mention as this point that we are getting to the situation where there can be multiple states that a particular customer can ‘be in’. They could be one or more of these:
signed up
pre free trial [part way through onboarding]
have supplied credit card [did that action at Stripe, and now redirected to continue onboarding]
currently in trial [ie part way through the first free month]
cancelled [decided during the trial to downgrade to the free tier]
trial expired [forced to downgrade due to trial ending and not subscribing]
subscriber [ at end of trial, decided to continue with paid plan and their card now being charged]
So, you need to build the logic required so that each time a customer comes back and logs in, that their ‘state’ is accurately reconstructed, and we meet their expectations. Over the course of building your app, you’ll be evolving the business logic, so I recommend diagramming these possible states, and get some clarity about how customers transition between them.
End of Trial
So, let’s assume that customers sign up, supply their credit card, and proceed to use the app over a month. Then what? What happens when the trial period expires and nothing else changes?
As per the message from the Stripe dashboard when they signed up, their card will be charged, due to the trial period being over.
What I need to record is that this is now a fully subscribed customer, and not a time limited trialling customer.
Conversely, if trials get cancelled, I need to know this in my bubble app, so I can change their plan to the Roommate one, which limits functionality.
Stripe can send information to your app via Webhooks, which you’ll find in the Stripe web console under Developers | Webhooks in the menu
I won’t go into details here, but will do a write up in a future article about Webhooks. For now, take a look here at this video from BillFlow:
Thats all for now folks. If you found this article useful please share it, and if you want access to every article I write, then you can subscribe here: