WordSaas 2: A SaaS Architecture

Let’s talk about what it might look like to build a SaaS on WordPress. For this article, let’s talk about the broad outlines of what we’re likely to need, how that might map onto WordPress and some potentially relevant plugins, and the choices that I’m planning on using in my own case.

As mentioned when I was introducing this little project, I think people don’t often enough consider WordPress as a good base for a SaaS business. And you can read my speculation on why that is in the previous piece. But let’s talk about what WordPress gives you for free if you opt to build on it.

Things you don’t have to build

First, you get user account management and authentication. Of course, you can build your own, but doing it right is harder than most people realize if they haven’t had a go at it before. Do you really want to spend time writing the code that sends the password reset email? Do you really want to figure out, should it become desirable, how to support logins through Google and Facebook accounts? There are still things to work out (we’ll come back to this), but a lot of user-related stuff just works out of the box.

You get a content management system. A really good, highly customizable one.

You get plugins that provide an enormous amount of other functionality you may well need. For starters, you get lots of options for the whole range of payment-related chores. That includes shopping carts, checkout processes, subscription management, and built-in integrations to Stripe and all the rest of the payment processors.

Need to manage different membership levels? There are several well-tested options for that.

Need control over the access that members have to various pages and functions? Several plugins.

Pretty charts? Of course.

I’ll stop there, because I think for the most part I’m preaching to the choir here.

What you’ve got to build

You don’t get everything, of course. Indeed, there are two fundamental things you’re very likely going to wind up coding on your own.

First, there’s whatever it is that your SaaS actually provides in return for hard-earned cash. The secret sauce. Unless your play is specifically about offering content or providing some kind of directory or two-sided marketplace, you’re going to need to roll your own (and, actually, you’ll have to do some cobbling for the two-sided marketplace, I suspect).

But you were going to have to do that anyway, right?

The question is: are you comfortable writing that stuff in native WordPress, or do you want to write something that provides REST endpoints and make calls from WordPress, or perhaps you want to handle all the business signup, account admin, payment and so on within WordPress, but then hand off to a separate application written in whatever you like, perhaps using a bearer token to confirm that the authentication was successful.

I’ve been mulling over whether there’s a general best answer for this basic question. If you know your way around WordPress development, then it’s fairly likely to be best to write your code in PHP and JavaScript within the traditional WordPress framework.

What intrigues me is the idea of tying together the WordPress pieces into a SaaS-enabled arrangement and then having a gutenberg block that you configure with a REST call that returns the rendered block dynamically. In other words, it’s just a regular dynamic block, but the dynamic rendering is handed off to another server or app (or edge function, for that matter) written in any language at all. More on this in later posts, where I hope to play with the concept a bit.

There’s one other thing

So sure, the bits that make your SaaS unique in the world you’re going to have to supply. But there’s also a more SaaS-general issue that you have to sort out in most instances: segregating user-specific data.

Let’s say you’ve created some sort of dog walker management application. You’re going to sell subscriptions to lots of dog walkers (you hope), and they are going to manage their clients (and their dogs) on your platform.

Let’s further imagine that when a new user shows up and signs on to your application, you take their payment and then create a WordPress user account with a custom Walker Admin role. So far, so good.

This customer then signs up dog owners as customers. There’s a portal in this application that an owner can sign into for self service (one of your service’s key benefits). When that owner signs in to the portal, are they signing in to a WordPress user account, or is there a custom table with owner info that includes a hash of a non-WordPress, unique-to-this-application password?

There are potential benefits to having them sign into an actual WordPress account. It makes simpler work of integrating with email campaign/newsletter software, for instance. But it makes it harder to deal with an important requirement: each of your dog walkers must be restricted to viewing only their customers. They can’t be allowed to have any inkling that anyone else uses this platform. Each account is it’s own closed universe.

Multisite or otherwise

A potentially clever way to deal with this is to use WordPress’s often overlooked multisite option. In this scenario, each dog walker gets their own copy of the application site and all of their customers are congregated on that site. Done right, it’s wonderfully powerful and clean. We’ll have more to say about this approach.

Another way is to build multi-tenancy directly into your application. Now you’re only dealing with one server and you store customer data in a custom table, where each customer is keyed to a particular dog walker. You write your code so that each dog walker only sees data tied to their account.

This is a pretty solid approach and I’m surprised that there’s no plugin that, in one way or another, makes this easy to do. As we’ll see, PeakZebra’s data tables support multi-tenancy (each record has a tenant identifier field), but that only provides the tooling–you still have to make your code respect the separation.

For now, we won’t solve this particular problem. The point here is that it’s an issue that, in one way or another, you’ll most likely have to deal with in order to build a SaaS site.

Funnily enough, I don’t have to solve the multi-tenancy problem in my particular use case. That’s because each PeakZebra SaaS user will have a WordPress user account with a bunch of data tied to it, and this data is then used as configuration data for their own site, where they’ve installed PeakZebra blocks. So I get to cheat a little bit, but in the interest of furthering the general WordPress SaaS cause, I’ll have more to say in the future about how to manage full-blown multi-tenancy.