If you build WordPress websites for clients, you've probably encountered the same problem we kept running into.
The website itself is rarely the complicated part anymore. An agency can build a very good site with WordPress, Elementor, Bricks, Gutenberg or whatever stack they prefer. The real challenge starts when the client asks for software that sits behind the website.
A church doesn't just want pages about its ministries. It wants member management, giving, attendance, groups, events, communication and somewhere for people to log in.
A gym doesn't just need a homepage and timetable. It needs memberships, bookings, attendance and customer accounts.
A school needs something different again.
At that point, agencies usually have three options. Build the software themselves, assemble a collection of WordPress plugins and integrations, or send the client to an external SaaS product.
We've been exploring a fourth option with WPWaaS: give WordPress agencies finished, industry-specific software they can deploy alongside the websites they're already building.
That's the idea behind WPWaaS, and it's also why we're deliberately building it as infrastructure rather than trying to create another standalone SaaS platform.
The problem isn't WordPress
There's a common assumption that once a WordPress project needs serious application functionality, you should probably stop using WordPress.
I'm not convinced that's always true.
WordPress already gives agencies an enormous amount of useful infrastructure. It's familiar, flexible, widely supported, relatively easy to deploy, and there are millions of businesses whose websites are already running on it.
The problem comes when we try to turn a generic WordPress installation into a complete software product by assembling dozens of unrelated components.
A membership plugin handles members. Another plugin handles events. Another handles payments. Another handles forms. Another handles notifications. Then someone needs a dashboard, so another plugin gets added.
Individually, those plugins might be excellent. The problem is that the resulting product isn't necessarily designed as one product.
This is one of the reasons we started thinking about the difference between Website as a Service and traditional SaaS. If you're unfamiliar with the distinction, we recently put together a more detailed explanation of what Website as a Service actually means and how it differs from the more familiar SaaS model.
The distinction matters because WPWaaS isn't trying to turn WordPress agencies into SaaS developers overnight. We're trying to give them infrastructure they can use to deliver software as part of the work they're already doing.
Our first test case was a church
The first portal we built was for churches.
That wasn't because we intend WPWaaS to be a church software company. It was simply a particularly good place to test the idea because church websites expose the limitations of the traditional WordPress approach very quickly.
The public website might look relatively simple. Home, about, ministries, sermons, events, contact and giving.
Behind that website, however, is an organization with hundreds or thousands of people who need to interact with it.
Members need accounts. Administrators need to manage people. Groups need to exist. Attendance needs to be recorded. Events need to be managed. People need to be able to submit prayer requests. The organization needs online giving and communication tools. Members need access to resources.
You can build all of this with WordPress if you have enough time, technical expertise and patience.
But that's not the same thing as having a coherent software product.
We decided to build the latter.
The result is the WPWaaS Church Portal, which brings those workflows into one purpose-built dashboard rather than expecting an agency to stitch together a collection of unrelated plugins.
The important part for us wasn't simply getting the features working. It was designing the experience around the people who would actually use the software.
WordPress is great for developers. That doesn't mean it's great for everyone.
This became another important part of our thinking.
If you're a developer, WordPress's admin interface makes perfect sense. You understand Posts, Pages, Plugins, Users, Settings and all the other pieces that make up the system.
Now imagine you're a church member who just wants to see an upcoming event, check your group information, make a donation or submit a prayer request.
They don't care that the underlying system is WordPress.
They shouldn't have to understand WordPress either.
This is why the WPWaaS dashboard deliberately looks and behaves more like an application than a traditional WordPress administration panel. The objective is to give the end user an interface that feels like software built specifically for their organization.
That becomes even more important when you consider that these aren't necessarily people who spend their day inside WordPress.
A good software product should make people want to use it.
It shouldn't make them feel like they've accidentally wandered into the backend of a website.
Then we asked a much bigger question
Once the Church Portal started coming together, we kept asking ourselves why the same concept couldn't work for other industries.
The underlying problem isn't unique to churches.
A gym has customers, memberships, payments, bookings and attendance.
A real estate business has clients, properties, agents, enquiries and documents.
A school has students, parents, attendance, communication and events.
A clinic has appointments, patients and communication.
The workflows are different, but the pattern is remarkably similar: the website is the public-facing layer, while the business increasingly needs software behind it.
That's where the idea of vertical SaaS became particularly interesting.
Rather than building one giant generic dashboard and asking every business to configure it themselves, we're building a common platform that can support different industry-specific products.
One platform, different verticals
This is probably the most interesting technical direction for us.
We don't want to build ten completely unrelated applications.
We want common infrastructure underneath the different portals, while allowing the actual user experience and business logic to change significantly from one vertical to another.
Authentication, user management, roles, tenant management, branding, deployment and other infrastructure can be shared.
The actual application layer can then be specialized.
A church needs members, groups, giving and attendance.
A gym needs memberships, classes, bookings and trainers.
A school needs students, parents, attendance and communication.
A real estate business needs properties, agents, leads and client interactions.
That gives us an interesting engineering tradeoff. We get the efficiency of shared infrastructure without pretending that every industry has the same workflow.
It's also why we don't see WPWaaS as simply another collection of WordPress plugins.
The goal is to create industry-specific software that happens to use WordPress as part of its infrastructure.
Why not just build another SaaS?
This is probably the question developers will ask.
Why build on WordPress at all?
Why not build a completely independent application using Laravel, Next.js, Rails, Django or whatever stack we'd choose for a conventional SaaS product?
There are certainly situations where that would make more sense.
But we're specifically building for WordPress agencies.
Those agencies already know WordPress. They already have hosting infrastructure. They already have clients on WordPress. They already know how to build and maintain WordPress websites.
Asking them to completely change their development workflow isn't necessarily solving their problem.
Our agency model starts from a different assumption: the agency should be able to keep doing what it already does well.
Build the frontend however you like.
Then, when the client needs more than a website, deploy the relevant WPWaaS portal alongside it.
That's a much smaller change to an agency's workflow.
The agency is actually the customer
This is another part of WPWaaS that is easy to misunderstand.
We're not primarily selling these portals directly to churches, gyms, schools or clinics.
We're building infrastructure for the agencies that already serve those organizations.
That changes the entire business model.
Imagine an agency is hired to build a church website. The agency still designs and develops that website as a normal WordPress project.
But instead of sending the church to another company when it needs member management or online giving, the agency can offer a branded portal as an additional service.
The agency can set its own client pricing and retain the revenue from that subscription. WPWaaS doesn't take a percentage of the agency's client revenue.
We've written more about this model in our guide to recurring revenue for web agencies, because that's ultimately where the commercial opportunity becomes interesting.
The website project doesn't disappear.
It becomes the starting point for a longer software relationship.
This is different from simply reselling a SaaS product
There are already plenty of platforms that allow agencies to resell software.
There are also plenty of church management platforms, membership systems and client portals.
Some are excellent products.
The problem we're trying to solve is slightly different.
Take a church agency as an example. The agency might build the church's WordPress website and then recommend a platform such as Tithe.ly or Subsplash for everything that happens behind the scenes.
That works, but the agency has effectively handed that part of the client relationship to another company.
We explored that exact distinction when comparing WPWaaS with Tithe.ly and WPWaaS with Subsplash.
The WPWaaS model is much more interesting to us because the agency can remain the provider.
The client gets a branded portal.
The agency owns the relationship and controls its pricing.
And the portal lives much closer to the WordPress ecosystem the agency already understands.
It's also more than WordPress Multisite
Technically, someone familiar with WordPress might look at WPWaaS and think, "Isn't this just WordPress Multisite with some plugins?"
That's a reasonable question.
Multisite is certainly part of the infrastructure story, but simply creating a network of WordPress sites doesn't solve the product problem.
Tools such as WP Ultimo and Ultimate Multisite are useful examples of the infrastructure layer that already exists around WordPress Multisite.
WPWaaS is approaching the problem from a different direction.
We're not primarily trying to give an agency a blank multisite platform and tell them to build the product themselves. We're building the industry-specific product itself, then giving the agency the infrastructure to deploy and resell it.
That's a pretty important distinction.
The agency shouldn't have to become the software company.
Deployment needs to be boring
From an engineering perspective, this is one of the areas we're paying a lot of attention to.
If an agency has to spend hours manually configuring every new portal, we've failed.
The whole point is that deploying the software should become predictable.
The agency should be able to select the appropriate portal, deploy it, configure the branding and domain, set up the client and get on with the actual project.
That's why self-service deployment, tenant management, white-labeling and repeatable provisioning are such important parts of the platform.
We've documented the basic workflow in How WPWaaS Works, but there's a lot more engineering behind making something like this feel simple from the user's perspective.
The best infrastructure is often the infrastructure you barely notice.
Where we're going next
Church is only the beginning.
We're working toward more industry-specific portals, including areas such as fitness, real estate, clinics and dental, schools and tutoring, and other categories where WordPress agencies already have a substantial client base.
That's an important part of our strategy.
We don't want an agency to sign up for WPWaaS because it has one church client.
We want an agency to look at the growing portal library and think:
"I already have clients who could use three of these."
That's where this becomes much more interesting.
A generalist WordPress agency might work with churches, gyms, property businesses, schools, consultants and professional services companies. If the agency can access specialized software for several of those verticals through the same underlying platform, WPWaaS becomes much more useful than a single-purpose plugin.
The long-term vision is effectively a library of vertical SaaS products for WordPress agencies.
We're still figuring out the hard parts
We're deliberately building this in public to some extent because we're still early.
There are plenty of technical problems we're working through.
How much functionality should live in the shared platform versus individual verticals? How do we keep updates safe across multiple agency deployments? How much should agencies be able to customize? Where should the boundary between WordPress and application functionality sit? How do we keep each portal feeling genuinely native to its industry without creating ten completely separate codebases?
Those are much more interesting questions to us than simply building another WordPress plugin.
We're also continuing to expand the platform itself, including things such as mobile-first experiences, PWA capabilities and notifications. The reason is simple: if we're asking end users to use these portals regularly, the experience needs to feel like modern software rather than a website that happens to have a login screen.
The bigger idea behind WPWaaS
The more we work on this, the less interested we become in the idea of WPWaaS being "a WordPress plugin."
That's technically what part of the product is, but it doesn't really describe what we're trying to build.
The bigger idea is a layer between WordPress agencies and vertical SaaS.
Agencies already know how to build websites.
Businesses increasingly need software.
There is a gap between those two things.
We want to give agencies a way to fill that gap without forcing them to build and maintain every piece of software themselves.
That's why the WPWaaS pricing model is built around agency deployments rather than taking a cut from the agency's customers. The more useful the portal becomes to an agency's clients, the more opportunity the agency has to build recurring revenue around the projects it is already winning.
And that's ultimately the bet we're making.
Don't replace the WordPress website. Build what comes after it.
If you're a WordPress developer or agency owner, I'd genuinely be interested in your take. Would you build vertical SaaS on top of WordPress, or would you start from a completely separate application stack? Where do you think the line between "WordPress website" and "WordPress application" should actually be?
We're still working that out ourselves.
You can follow what we're building at WPWaaS, or dig into the WPWaaS story and the thinking behind the platform if you want to see where this started.
Top comments (0)