Planning A WordPress SaaS

Introduction

There are many reasons to use WordPress as the foundation for your SaaS. Among these are:

• Development is 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 WordPress 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.

Architecture Options

When building a SaaS on WordPress, one of the first things you’ll have to decide is your deployment architecture. WordPress offers three different architecture options for a SaaS:

• WP Multisite (usually using WPUltimo)
• Standard Sites (with a central control-plane)
• Multi-tenancy

Architecture #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 default basic template will not have a pleasant onboarding experience for customers (among other required features).

Architecture Option #2: Standard 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 you will encounter 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.

Architecture Option #3: Multi-tenant

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 decent amount of custom infrastructure configuration for it to work.
• There is going to be a small subset of plugins and themes that will not work because they make assumptions about the WP file structure instead of using the built-in functions to located WP components.
• 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 can affect all tenants. For some configurations that can mean all tenants across all servers; for others it could mean all tenants on a single server.
• 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. (WPCloudDeploy is one of the very very few vendors that offer integrated billing out of the box for multi-tenant configurations)

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.

Which Architecture Option Is Right For You?

To choose the right option you have to ask yourself – are you building your WordPress SaaS for the short term or the medium/long term?

Generally, building for the short-term will cost less to get started but be far far more expensive in the medium and long term.

Once you’ve decided which time frame you’re building for, then you need to estimate the number of customers you’ll acquire within that time period.

When you have that estimate, here are our guidelines for choosing your architecture:

• 100 customers or less: Use Multisite / WPUltimo
• 50 – 300 customers: Standard Sites
• 200+ customers: Multi-tenant

This is our opinion of course. And you’ll notice that there are some overlap in the customer limits. This is because the thresholds for each can vary depending on the complexity of each site.
For example – Multisite & WPULTIMO can probably handle more than 100 sites if each site is a simple ‘brochure’ site. But, you might only be able to handle 50 complex membership sites on that same architecture.

If you have severe budget constraints, here are some additional guidelines that might help:

• Multisite / WPUltimo – you can get started for under $1000 USD and a lot of your own work. If you don’t have development experience you’ll find that there are some things such as upgrades and customized user-onboarding that might be beyond your reach.
• Standard Sites – requires at least $2500 and a lot of your own work.
• Multi-tenant – you really can’t get anything production worthy here for less than $5000 (though you can play around with some things for far less.)

Template Sites & Custom Plugins

No matter which architecture you choose or which vendor you use, you will need to create at least one template site and a custom plugin for that site.

The template site is the site that is going to be copied for each new customer. This is likely where you’ll spend the most amount of your time building out your product.

You initially build this site like you would any other WordPress site – using a combination of plugins and themes to get close to the functionality you want to offer your customers.

You then add in things such as white label plugins, security control plugins etc. to help you lock down the look-and-feel and what your customers are able to do.

The custom plugin will be used to customize the experience for each customer as well as handle operations related to system upgrades and, sometimes, user plan upgrades (among many other functions.)

If the idea of a custom plugin scares you, we should mention that we’ve never seen a significant production WordPress SaaS deployment without one. Even if you don’t add one right away you’ll quickly realize you need it and end up searching on-line for the best way to create it.

Still, you’re likely to start creating a basic template site first – adding in the themes and plugins you want your end-users to use before stumbling into the complexities of a custom plugin.

User Types

One of the decisions you’ll have to make is what role your customers will use to login to their sites. Will you grant them full admin rights or a role with limited access?

Most admins end up providing a user role with limited access. This prevents the customer from uploading their own themes and plugins and reduces the number of menu options that they have to deal with.

You can control role access to menu options and features using either a custom plugin, using a plugin called Admin Menu Editor Pro or a combination of the two.

Admin White Label Plugin

There are a few plugins out there that can help you customize the user experience in the wp-admin area.

We’re not a fan of them unless absolutely necessary.

The reason is that they are all very code heavy and many of them conflict with other plugins.

Some of them overlap with more important plugins you need – for example you might find a white label plugin that is attempting to help you modify the menu and access to menu items. But that’s something that Admin Menu Editor Pro does and, because it’s a dedicated plugin for that task, it does a better job than most white-label plugins will do.

We’re sure that you’ll try one or more of these plugins – popular ones include Adminify, the white label plugins by Theme Passion on Envato and Slate (also on Envato).

For a light-weight white label plugin, Slate works well. WP Adminify is the most ambitious and, as a consequence, also the one most likely to conflict with a plugin or theme you’re using.

Even if you do use one, expect to spend some type crafting custom CSS to handle weird display issues caused by the plugin. Each one will likely have a different set of display issues.

That Custom Plugin (Again)

Yup, we’re bringing this up again. We know that for some of you reading this, the idea of creating one will make your eyes glaze over.

But, if you want full control over any of the following features, you will need one to handle certain critical aspects such as:

• Custom first-time onboarding experience to hide most of wp-admin
• Changing screen terms (beyond what a white label plugin will allow)
• Changing the WP dashboard (beyond what a white label plugin will allow)
• Upgrading payment plans inside wp-admin
• Self-service domain mappings
• Automatic setup of licenses for certain plugins and themes
• Upgrading the database
• Adding upsells inside wp-admin

And more.

If you’re not a developer and don’t have the budget to hire one, your user experience will suffer.

So, for planning and budget purposes, you should include a line item for a developer – regardless of which deployment architecture or platform you choose.

One Template Site or Multiple Template Sites?

The ideal for most WordPress SaaS deployments is one template site, inside which there are all the options to switch themes and visual layouts as well as plan upgrades & downgrades, account management and more.

BUT that’s a lot of custom code inside that pesky custom plugin we keep mentioning.

So, for most of you getting started, you’ll end up with multiple template sites – making the same changes to each one every time until you get that critical mass of customers that make it cost-effective to consolidate into a single template.

For example, let’s say you’re creating a SaaS for the legal profession. You might want to offer 5 different layouts with different default graphics, positioning etc.

For that, you’ll end up with 5 template sites.

If you’re creating a SaaS for multiple industries, you’ll end up with even more templates.

Upgrading Existing Users (Sites)

There will come a time when you want to upgrade existing users to the latest versions of your templates. Sometimes those upgrades will involve database changes – that’s where the custom plugin pops up again.

Whether or not you use WordPress as the foundation of your SaaS, upgrades and database changes generally require code to be written to handle those upgrades. A WordPress SaaS is not unique here.

What is unique is that, many times, the individual plugins and themes will handle the database upgrades for you and you only have to worry about the custom functionality you added (eg: the onboarding experiences or your in-dashboard plan upgrades / downgrades and billing integration, template options etc.)

Testing

You’ll spend a lot of time testing. In fact, if this is your first foray into building a WordPress SaaS you’ll be surprised at the differences between your template site and a new customer site, especially when you first login to the customer site.

The CHANGE TEMPLATE → TEST AS NEW CUSTOMER cycle will be a constant.

If you’re doing it right, you’ll easily end up with 100+ test sites (that you’ve deleted of course) before onboarding your early users.

As part of your planning process, you’ll need to plan for the time that DEV – TEST cycle requires. It’s tedious but necessary.

The Role of WPCloudDeploy

WPCloudDeploy can handle all three architectures. Once you pick one then it’s all about configuring it to make sure your site is deployed within that architectural framework.

However, for a Multisite / WPUltimo architecture, WPCD is likely overkill; so you’re probably not going to setup an entire WPCD instance just that type [of architecture.]

• For Standard Sites, you’ll use our WooCommerce Integration for deployment
• And, for Multi-tenant deployments you can read about how we handle those here.

Wrap Up

If you’re new to using WordPress to build a SaaS it might seem as if things are overly complex. But, compared to building from scratch or even using a no-code tool like Bubble, it’s a lot less work. This is because WordPress offers so much right out of the box.

Even if you go to the extreme and the only thing you used was the WordPress core and you built everything else with custom code, you’ll still save a tremendous amount of time and money compared to starting from scratch.

A lot of your time will likely be spent hiding things you don’t want your users to see, unifying the user experience among different plugins and, generally, working around some of the weird things that plugins do. That’s a lot easier to do than writing, say, an entire e-commerce store from the ground up or building out an entire help-desk or chat infrastructure.

---

Update History

We’re going to be updating this article multiple times per year.

• 03-20-2024: Added a paragraph to the template sites section to discuss more about how it’s built and used.
• 01-08-2023: Minor grammar tweaks