Structuring a Bubble.io SaaS Product

A common question I get during Bubble.io coaching sessions is how to think about structuring a Bubble.io app for SaaS clients. It’s a very understandable concern, as it touches on two of the main pillars of app planning: database structure and security.

By Bubble.io SaaS application in this article, I talk about any kind of application that services multiple clients, each in their own walled garden of data. Who that client is is irrelevant; it could be a single User, an SME, a sports team or a multinational conglomerate: as long as they are logging into your platform and expect to operate in a silo of their own data, you are operating in SaaS territory.

We’re also talking about a multi-tenant solution where multiple clients share the same database, as opposed to a single-tenant solution where each client is hosted in an isolated database (which in Bubble would usually be solved with sub-applications).

The SaaS structure in Bubble

Let’s first have a look at what exactly it means to talk about a SaaS model from a structural standpoint. Structure in this case relates of course to your database: how exactly are you architecting it to prepare it for multiple clients? To answer that question, we need to start with a more fundamental one: what kind of data categories are there to begin with, and how do they relate to each other? Note that I’m not saying Data Types here: I’m going one level up and talking about categories of data.

In a typical SaaS model, there are three data categories that you need to include in your planning: the User, the Client and the Data.

The User is the person using the app. They can be in different states (such as logged in/logged out) and can have specific attributes relevant to the SaaS setup (such as which Client they belong to).

The Client is the organisation that pays for your SaaS: the Parent Company/Team/Organisation that separates collections of Users from each other. Each Client represents a collection of Users that expect to have access to data belonging to their Parent Client, and nothing else.

The Data is all the data you are storing in the database related to the everyday Use of the app. For a CRM that could be Customers, Vendors and Contacts and for a Project Management Tool that could be Projects, Tasks and Comments. Like Users, Data has attributes (such as which Client they belong to and which User created them).

These three data categories together determine the access level that any given User has to specific data:

In the Venn diagram above, we see this illustrated: access is granted based on the attributes of all three categories:

• The User needs to be logged in and belong to the same Client as the Data they are trying to access
• The Data (in addition to belonging to the same Client) may have other attributes that determine the User’s access (such as whether it’s Created by that same User)
• The Client needs to be present in both the other categories

The Client is on top of the diagram for a reason: it’s the gatekeeper for all data in the database in many cases, and moving from Venn diagram to Privacy Rules, it means in practice that potentially every single rule you set up includes the Client as one of the Conditions:

What exactly does this tell us about structuring? A few things:

• Every single Data Type in your system intended to be kept private needs to store the Client as a field
• Every single Privacy Rule you set up needs to include a condition that checks this Client against the two remaining categories: the User and the Data

Where in the process do you set that up?

Going back to the questions I get about SaaS setup, a common one is when to set things up for a SaaS structure? Many apps start out small: perhaps with one client or even just internally with your own team. The SaaS approach is a potential scaling strategy that can open up for future growth, but it may not be a priority from launch day. As The Lean Startup tells us, we should build the Minimum Viable version of a Product and then keep building it as we get validation and traction. So that means we should hold off structuring our app in preparation for a SaaS model and implement that change down the road, right?

I would argue no. The structure should be implemented from day one, and your first version should be a one-client SaaS that lets you scale to more clients as needed.

Why it makes sense to build a multi-tenant SaaS structure from day one

Let’s first discuss how fast our world is moving: The Lean Startup came out in 2011, eleven years ago at the time of writing this. It’s an excellent book and has been hugely influential on the whole tech scene for good reason. It made us all aware of the cost associated with guessing wrong and introduced a mental model that helped us avoid spending time on elaborate business plans and feature-rich software that ultimately never found a target audience. But some things have changed since its release: the point that The Lean Startup argued for was to avoid making decisions that required weeks or months of investment with a full development team to build.

As the resources needed for each feature to be implemented has shrunk over the years since its release, those same processes can be completed much faster. Bubble makes development so efficient that a major structural decision like the one we’re discussing in this article can literally mean adding just a few hours of extra development time. The book of course never argued that we should steer away from key features that required mere hours to implement: there’s no value in purposely launching a product that is as minimally viable as it can possibly be, if a better alternative could be offered with a minuscule investment. Eric Ries would agree with Bubble’s vision: he’s a member of their board of directors after all.

This doesn’t render the book worthless: not even the slightest. In my personal opinion it may still be one of the most important books you can read on your tech journey. Yes, Bubble has changed the map in the way that including a new feature requires a minimal investment, but getting stuck in an endless loop of improvements and added features before launching is still a very real challenge for many founders: we need to trim that fat still, and adopting the MVP mindset is the best guide we have to avoid the pitfall of development quagmire.

So which is it then?

The answer is, as it often is: it depends. There’s no clear line in the sand to be drawn to generally separate the necessary from the unnecessary features in your specific application. Even with a fast-paced framework like Bubble, your launch roadmap requires a mix of the build-measure-learn-cycle approach and common sense. But returning to our original question of setting up your SaaS structure early on, let’s use this as an illustration on what I mean by common sense in this discussion.

Balancing the scale

The key word here is investment. Business is a never-ending mission to invest one amount somewhere in order to get a bigger return down the road. An investment is not frozen in a point in time, but has to be seen as a whole over the entire lifetime of a Product: for example, it makes little sense to build a house on top a swamp because the land was cheap; over time the house rots and sinks and your investment will far outweigh the return. The scale tips to the cost side over time. In no-code development then, the question we need to ask ourselves is: how much investment will you have to spend in the future on the things you did not do today? How much further will the scale tip to the cost-side given enough time?

Setting up things the right way to begin with in Bubble is very fast: going back and making structural changes later is slower and opens up for making mistakes. Structuring an app for a SaaS model in my experience is a quick and easy process: it adds a very slim cost to the initial development. But as we explored earlier, the decision affects the most fundamental parts of your app: how you structure your database and plan for security. This is the land that you build your house on. Changing your mind down the road can make your investment a lot bigger than you anticipated (or even realise) over time.

As long as you are confident in your idea that your app will be multi-tenant at some point, think of your app as a one-client SaaS until the day comes when you have two. Deciding on a database and security setup that takes into account the Client as the fundamental data gatekeeper is not a big investment: it’s simply a decision made once that affects every development choice you make from then on.

As long as you know that every Data Type and workflow in your system needs to take the Client into account to maintain the expected level of security, you’ll simply set it up that way. It’s not a more demanding way to develop: just a slightly different route, adding perhaps a total of a few extra hours to your development time. Now imagine, in a complex app, to start the job of identifying every Data Type, Workflow, Action and Element that’s going to be affected by introducing the Client as a cornerstone of your security after the fact. That process ranges from time-consuming to daunting, depending on your app.

Finally, this way of thinking too should of course be subject to common sense: if you have no concrete plans to go the SaaS route, or you plan to re-build your app on Bubble or another framework after showing off a simple demo; by all means, skip the SaaS structure and postpone that decision. Also, keep in mind that structuring your app for a multi-client environment is not the same thing as making the app multi-client from launch. Having multiple clients requires sign-up forms, onboarding, Client settings, help docs, Terms and Conditions and who knows what other features: no one’s saying you need all that in your first version. I’m telling you to pick the right land for your house, not to decorate every room perfectly before you move in. Look at the fundamental structure your database and security setup needs in order to facilitate multiple clients and get that set up: the design and UX can come later.

When making fundamental structural decisions like this one early on, ask yourself two questions:

• How difficult will this decision be to backtrack?
• How likely is it that I will backtrack it?

If the answers are pretty difficult and pretty likely – invest in the right setup from day one.