Since we’ve gotten into the micro-SaaS game, we’ve found that clients have a hard time grasping what they’re getting in a product. So, here’s a valuable resource for all of the clients out there confused by their software offerings. In this article I’m going to explain two core components of an SaaS product: main (public) sites and tenant sites. What are these? Read more to find out!
What is SaaS?
Software as a service is defined like so in Wikipedia:
Software as a service (SaaS; pronounced /sæs/) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as “on-demand software”, and was formerly referred to as “software plus services” by Microsoft. SaaS is typically accessed by users using a thin client via a web browser. SaaS has been incorporated into the strategy of nearly all leading enterprise software companies.
A valuable addition to this definition is that users all receive the exact same look and feel of product once they’ve signed up. The help illustrate this, think about your gmail account. Once you’ve logged in, it looks like every other gmail account (except for the content and a few options). Most SaaS products are the same and a few key rules hold true:
- Centrally hosted,
- Signed-up (usually paying) users can access their service,
- Service is identical for all users.
Because I like helping people understand what they’re using and working with, I’m going to take the “Explain it Like I’m 5” (ELI5) tactic. Please don’t be offended. In fact, here’s a funny comic to help with that:
How does it work?
Let’s use Trello as an example here. You could substitute in any web service you use (Gmail, Asana, Outlook, Github, Dropbox, Bitbucket, Sharpspring, etc etc etc) and this example holds true.
The core breakdown of an SaaS product is that it has two separate types of site:
- A single, unique main, public site that describes what the product is, and
- A replicated, visually identical tenant site for anyone who signs up.
Main (Public) Site
A main site is separate from the tenants, both physically and by design. It does not receive the same content updates as the tenant and isn’t related. Take Trello, for example:
On the public site for Trello, we have screenshots of what the product is and what you can expect, how it works and helps you work as a team, and various selling points to convince you to sign up. This site serves as a valuable tool to convince users to use your product. You want this to be different from the tenant site to avoid confusing the user about what page they’re on, and what they’re currently using.
A tenant site, on the other hand, is identical to other tenants. It is a carbon copy that has the same look and feel as other tenants, and will receive the same updates as the tenants. The only differences are those defined by the database, like the name of the site, pictures, banners, and so on.
Let’s look at Trello again.
Once I’ve logged in, the Trello site has changed to show me my content. It is nothing like the public site. This is intentional, and helps keep the sites distinct.
Here’s an example from another user:
Note how the interface is the same, but the content is different. They have their own boards and their own profile picture, but otherwise one tenant is identical to the other. Now, you may have noticed that some things can be shared between tenants, like the “Christmas Lists!” board. This sharing is provided by design, and is a feature that can be built at the start of the project. The important takeaway is that data can be shared if it needs to be, but otherwise is separated.
Any new user would get another interface, identical to the other two. None of these would look like the main (public) site however, because that’s the selling page (not the product offering).
To recap, the main site and tenant sites are intentionally different from each other. The main site shows you how and why to sign up, while the tenant is what you see once you’ve done so. Some decisions, made in the design and development of the product, allow things like sharing data between tenants, or even publicly accessible content. These decisions should be determined early when working with a development team to ensure that everything run smoothly. I hope this was a fairly straightforward example of how the two parts of a tenant application work.
Email me at [email protected] if you have any questions or comments!