Why We're Building Vertical SaaS on WordPress Instead of Building Another SaaS Platform

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