The Ultimate Guide To Building A WordPress SaaS – Part 1 (of 5)

Introduction

If you’re reading this, there’s a good chance you’re thinking about building a SaaS project using WordPress as the foundation.

There are a number of reasons to build a SaaS project on WordPress. Among these are:

• It’s faster since there are many plugins already available for almost every imaginable function. Even if the exact functionality you want doesn’t exist, chances are there’s a plugin available that is close and can be modified to do what you need.
• It’s a platform you know and are comfortable with using
• There is a TON of WordPress talent out there ready to be tapped to build what you need
• The platform has been around a long time, has proven itself, the underlying technology is well known by a ton of folks and just about everything integrates with it

As you might expect, there are a number of disadvantages you incur with WordPress when using it as the foundation for your SaaS:

• Each customer ends up with their own database – it is usually not shared.
• Each customer gets their own copy of the WordPress code inside their own isolated environment. This increases the compute power and storage required to support each customer / tenant.

There are options to bypass some of these drawbacks. For example, there are highly specialized configurations where you can create a shared database and a shared codebase. However, these configurations take longer to create & deploy and work less nicely with existing plugins unless they are modified. And, if things to wrong, it is harder to find talent who understand the custom configuration that was built.

If your goal is speed to market while maintaining scalability and flexibility in deployment, you will likely choose to incur the costs involved with extra database, diskspace and compute overhead.

WordPress SaaS Deployment Options

When thinking of building your WaaS, one of the first things you’ll need to decide upon is how the underlying server and sites will be deployed. You generally have three choices:

1. WordPress Multisite

WordPress has a feature called “Multisite”. It allows multiple sites to use the same database with a single copy of WordPress, plugins & themes.

The advantage of using this configuration is the reduction in code duplication. With only a single copy of the code required (WordPress + Plugins + Themes), you only ever have to change things in one place for every customer site to update.

However, there are significant disadvantages.

• Not all plugins and themes are built to be Multisite aware. There are special function calls and initialization calls that plugins and themes need to use when running on Multisite. If not used when they should, information can be shared across sites that should not be allowed. Or data returned by standard function calls will be incorrect and cause hidden bugs.
• All sites share a single user table. This has some ramifications. For example, if a user has accounts with multiple sites on the network, they will be forced to use the same login for both sites. But they might not realize this and will constantly end up resetting passwords, resulting in a poor user experience.
• You can only scale it vertically – i.e.: if you need more resources you need to use a bigger server.
• If you install or update a plugin or theme with bad code, all customers are affected.
• If your server gets compromised, all customers are automatically compromised.
• If you have one or two customers whose resource needs are significantly larger than your other customers, it is not easy to pull them out to a new server. Instead, you will have to get a larger server even though it’s only required for a single customer.

Assuming you configure things correctly and use the right plugins and themes, you still have a single point of failure. A single mistake can take down all your customers.

There is one very significant advantage to using Multisite though – there is a product called WPUltimo that make quickly rolling out a WaaS on a multisite relatively easy. There are still many limitations.

But, for less than $500, you can purchase it, install it on a WordPress site, convert the WordPress site to a Multisite, create a template site, create and assign pricing plans and be up and running. Though, as with all things related to WaaS deployments, the devil will be in the details since that basic template will not have a pleasant onboarding experience for customers (among other required features).

2. Multi-tenant WordPress

This configuration is similar to Multisite.

The biggest difference between this configuration and Multisite is that, in this configuration, WordPress appears to plugins and themes as a regular WordPress site (not as a Multisite). Thus, no special code needs to be included in them for it all to work as expected.

You only need a single copy of WordPress and your plugins and themes. Or, if running across multiple servers, a single copy for each server if all the servers are not using a shared disk.

There are some disadvantages.

• The feature is not easily accessible and generally requires a LOT of custom infrastructure configuration for it to work.
• There is no standard configuration so each host that offer it will use a different architecture – this means you are LOCKED into a particular vendor with no easy way out.
• As with Multisite, a bad update to a plugin or theme or a compromise of the files will affect all tenants.
• Most hosts don’t have customer billing and other customer management functions integrated so you’ll likely have to build out a lot of that.

Multi-tenant WordPress is a relatively new deployment option outside of wordpress.com. The wordpress.com site has been using a version of it for years. But it’s only recently that others have seriously started to experiment with the architecture.

Ironically, the holding company for wordpress.com is invested in many of the companies that are building out multi-tenant configurations.

3. Individual WordPress Sites

The easiest way to get your customers up on your platform is to give each of them an individual WordPress site.

Individual sites are easy to manage and plugins and themes don’t need anything special to correctly run on them.

Each site will contain a copy of WordPress and all plugin and themes which is a lot of code duplication.

The biggest issue though with this approach is management of all those individual sites.

Other issues include:

• Integrating a template site into a billing platform so that the template is automatically deployed when a user signs up.
• When it’s time to upgrade code, you’ll have more work to do.

But, there are significant advantages if you can get the individual site management and billing integration under control:

• You don’t have a central point of failure so a compromise or bad plugin or theme will not necessarily affect all your customers simultaneously.
• You can do ‘rolling’ upgrades to test out new features without impacting all your customers at the same time.
• You get the ultimate scaling flexibility with both horizontal and vertical scaling available. i.e: you can increase the size of a server or use more servers.
• You can easily use servers from different server providers so that if one provider goes down, not all your customers are affected.
• Its easier to place your sites in the region where your customer(s) are located – why place sites for a customer in France on your servers located inside the United States?
• You can easily scale up an individual customer without impacting others.
• You can move individual sites to a new host or provider anytime since they’re usually not built with any special configuration to tie them tightly to one host or another.
• You can easily build out special mods for a customer without impacting other customers.

Our Deployment Recommendation

In most cases we recommend option #3, especially if you’re just getting started and haven’t fully validated your market.

The multisite option is too limiting on the scalability side. And the multi-tenant options require additional training and education to effectively use it.

OpenSaaS offers both single-site and multi-tenant options but for most of this article we’ll be using the single-site approach.

The single-site option works well up to about 200 sites (customers), after which you’ll likely want to explore the multi-tenant options available.

However, a lot of what we talk about below is going to apply to all three options, especially when it comes to building template sites. And we’ll cover the OpenSaaS version of Multi-tenant at the very end.

However, if you’d like to use a Multisite foundation, head over to the WPUltimo site and start exploring there!

---

---

---

Getting Started With Your WordPress SaaS

Now that you know which architecture we’ll be focused on, lets get you started.

Head over to the opensaas.io pricing page, choose an option and checkout. Then, work with the team to get the deployment connected to your cloud resources.

You should be ready to go with your infrastructure in less than 24 hours if you give them immediate access to all the accounts that they request.

Once that is done you should have access to three servers:

• Your OpenSaaS Primary Control Server (aka the ‘control plane’)
• A Template server
• A Customer server

The template server should already have a basic site on it which is the one we’ll be working with in this article.

There should be no sites yet on your customer server.

---

Getting To Know Your Primary Control Server

When you log into your OpenSaaS platform for the first time, there will be TWO servers already set up for you under the OpenSaaS menu item:

Navigate to the ALL APPS menu option where you’ll see at least one app already setup for you – a template site that lives on your Template Server.

Clicking on the links in the title column (in either the server or app list) will take you to a screen filled with details about your servers and sites. The sheer amount of options presented might feel a bit overwhelming at first. But you will not be using most of them right away – they’re all there for flexibility just in case you need them in the future.

---