The Hybrid Plugin/SaaS Business Model

WordPress commercial plugins have traditionally been monetized in one of two ways:

1. By charging directly for the plugins (possibly as add-ons).
2. By acting as “APIware” for a separate software as a service (SaaS) offering.

The advantages of being a SaaS are numerous: easier development, easier support (less code running on a server you don’t control) and recurring revenue. But traditional WordPress plugins also have a lot of advantages, for both developers—lower cost for the company to operate—and users—easier customization, control of their own data, and possibly lower cost.

This article examines a hybrid model—a plugin with a SaaS service—and how to get the pros of both models while minimizing the cons.

Both models have pros and cons. I believe that simply moving to SaaS in order to improve the developer experience and company revenue isn’t a recipe for happy users.

Instead, my plugin Caldera Forms recently moved to a hybrid approach: a traditional freemium plugin with a SaaS platform that solves problems we can’t solve in the plugin.

This article will examine the hybrid approach, and how to get the pros of both models while minimizing the cons. I’ll be explaining how we found the problems to solve for our users, how to determine what is “plugin territory” and what is “SaaS territory,” and some developer decisions we made in creating the app.

Don’t Forget the Why Of WordPress

There are a lot of reasons why WordPress is so popular. Google Forms, Wufu, FormStack are really solid web form services, but I don’t use them because I want to be able to customize my forms (WordPress hooks) and control my own data in the WordPress database. This is why people like WordPress—plugins are a part of a system that they are putting together.

If you’re thinking about a hybrid plugin business, don’t take away the extensibility and data ownership that users come to WordPress for.

If you’re thinking about a hybrid plugin business, don’t take away the extensibility and data ownership that users come to WordPress for. Or maybe being a platform-agnostic SaaS business with a WordPress APIware plugin is right for your business, but keep in mind what benefits you’re taking from the user.

Also, let’s not delude ourselves: people like WordPress because it’s cheap. But as an industry, we know that $19 lifetime purchase plugins and $5/month shared hosting are not ending well for users, or creating sustainable business models that drive innovation. Higher price points are clearly possible in this industry. The best companies are going in the reverse of the race to the bottom, but they are providing real value and that’s key.

Solve Real User Problems

The first iteration of Caldera Forms Pro was a service we know call Caldera Forms PDF, because all it did was create PDFs from form submission entries. We decided to build it for two reasons: form to PDF was an in demand feature, and our prototype WordPress plugin for self-hosted form to PDF wasn’t reliable.

Converting HTML to PDF is a memory-intensive process, and isn’t a great fit for the world of plugins running on unpredictable WordPress hosts. Form to PDF was the perfect problem to solve with a SaaS product: real user need, and something that wasn’t solved well with a plugin.

A hybrid business model requires you to find a cross-over where the market needs a solution, and where a self-hosted WordPress site is a bad way to provide that solution.

It’s easy to think “because users want it” is sufficient reason to build something. It’s good reason, but if building it doesn’t grow the business, if the way you’re building the feature doesn’t make end-users happy, and if it doesn’t generate more in revenue than it costs you to operate and support, then what’s the point?

If you’re thinking of adopting this kind of hybrid business model, you need to find a cross-over where the market needs a solution, and where a self-hosted WordPress site is a bad way to provide that solution. Lucky for us, WordPress has a mountain of technical debt. Anything involving emails or requiring background processing—think subscriptions—is a great candidate.

Think In Value Add

Dropbox probably has the simplest freemium SaaS model: 5GB for free, 100GB is paid. If you like Dropbox and you need more storage than the value add of the paid version is pretty obvious. For a hybrid WordPress-plugin-plus-SaaS-app, making the value add of the paid component as obvious as possible is the key.

For a hybrid WordPress-plugin-plus-SaaS-app, making the value add of the paid component as obvious as possible is the key.

It’s pretty cliche advice at this point, but the quote “If you are not embarrassed by the first version of your product, you’ve launched too late,” from LinkedIn’s Reid Hoffman, is so true. We launched Caldera Forms Pro as soon as we were not embarrassed by it so we could talk to users about why they would or wouldn’t buy it.

Our original tagline was “Makes forms more awesome” which was pretty much meaningless. After talking to users we landed on “Stop worrying about contact form emails.” That’s the real value add. The other things it does—visual layout builder, email stats, form to PDF—are cool, but that’s what we found is the key value add.

Before we launched Caldera Forms Pro, I wrote a very detailed roadmap, based on what I wanted to build and what I thought would be exciting. The first big revision to the product wasn’t on that roadmap at all. We spent time talking to users of our plugin, paid and free and so many of them highlighted our support. So we made the second revision about making support better. Emails is something that like all contact form plugins we were hurting on, but tools to improve support were about making something we were already doing well even better. If people see the value in something already, adding more value there makes sense.

Plugin Territory vs. App Territory

When I got started in WordPress, the big debate was “plugin territory” vs “theme territory.” It was pretty common at the time for themes to come with tons of functionality that went beyond templates. These all in one themes created really bad user lock-in. You couldn’t switch theme or your posts in the portfolio post type were not accessible and you no longer had a contact form.

Taking your data from WordPress into an app makes it unavailable to other plugins or custom code. But if you can provide better or more reliable service with your app, then you’re clearly in app territory.

For the most part we’ve decided that functionality goes in plugins and themes are templating systems. When designing a hybrid plugin/app business you need to define a similar line. I think the answers come from a similar value: avoiding user lock-in and providing the best end result.

Again, keep in mind why people are choosing WordPress: extensibility and control of their own data. Your app might be able to do better things with user data, but not having that data in the WordPress database—and accessible to other plugins or custom code as needed—makes for less value, not more. But if you can provide more reliable service, something that is easier or looks better with your app, then you’re clearly in app territory.

Building Your App

I’ve spent the last few years writing about the WordPress REST API. One reason why many people—including me—have said the WordPress REST API is so important is that it lets us build apps using WordPress. I’ve seen some really amazing things built using WordPress as the backend for an app, and apps integrated with the WordPress REST API.

Going with Laravel Instead of WordPress

I’m a little sad that my app’s back-end is mostly built using Laravel, but WordPress couldn’t meet many of my needs.

Given my excitement about the REST API, I’m a little sad to say that Caldera Forms Pro’s back-end is mostly built using Laravel. WordPress clearly met the need for REST API endpoints defined in code, not in settings. But WordPress couldn’t meet many of my other needs, including first-class Composer support, user management decoupled from the app, flexible schedule tasks, or a database ORM.

Yes, WordPress works with Composer. I use Composer to manage my site and for plugin development. But there is a big difference between working with a framework built around Composer and NPM versus hacking support in later. Similarly, WordPress has a task management system, wp-cron, but it’s not reliable.

WordPress’s custom post types and custom taxonomies are great, if they fit your needs and you get a ton of code and UI “for free.” But in our case, that had no benefit for us. WordPress doesn’t have a standard API for modeling the relationship of data to database tables. We have WP_Query and similar APIs, but they don’t really represent models with all related fields and content types.

I’ll also say that part of my decision to use Laravel, along with VueJS, was to satisfy my desire to play with cool toys. I wouldn’t be a PHP/ JavaScript developer if WordPress hadn’t given me an easy way to learn these skills. But, I’m a nerd and I want to learn more and use the new shiny, which isn’t always possible in a WordPress context.

Finding technologies that let me learn new things, and avoid many of the shortcomings and frustrations of WordPress—lack of autoloader, application state defined in code, etc.—was a big win. Just using the latest and greatest because it’s fun isn’t a good reason to use it. But I also think it’s important as a developer to design your products in a way that allow you to advance your learning, when that’s compatible with your business needs.

eCommerce and Marketing Automation

WordPress is a fantastic eCommerce tool. Not just because it has great eCommerce solutions that just work, but because those tools are really well integrated with tools for marketing automation. Also, since we were adding a SaaS product to our existing product, keeping everything in one account on our existing WordPress eCommerce site made a lot of sense.

For our first SaaS product, Caldera Forms PDF, I built all of the eCommerce in Laravel. It was pretty simple and required less code than I used to make WordPress power the eCommerce for Caldera Forms Pro. I wrote about that process and the comparison with working with WordPress eCommerce in two articles for Torque.

As simple as that was, it meant users had two different accounts with us. Also, I never did get around to integrating those accounts with our email list integrations we have running on our WordPress site.

For Caldera Forms Pro, we are using exactly the same eCommerce system as for our WordPress plugins: Easy Digital Downloads (EDD). EDD gives us subscription-based billing, multiple payment gateways, and eCommerce integration. I wrote a plugin I called “Taco” to handle interactions with the non-WordPress parts of the app.

Taco hooks into EDD and checks if a subscription that is being created, updated or cancelled is for Caldera Forms Pro and updates data as needed in the app. It also makes the API keys for the app available in purchase history and provides authentication for the app UI.

What’s really great about this approach is user-facing and shop-manager facing UI for the app is all handled by EDD. That’s something they’ve been working on for years and have done a fantastic job on. These screens are integrated with the management for other purchases seamlessly, and I didn’t have to build them!

The WordPress Monolith

WordPress is fundamentally a distributed system: we each have our own site that does everything. That has tons of advantages, but it also has weaknesses.

WordPress is fundamentally a distributed system: we each have our own site that does everything. That has tons of advantages, but it also has weaknesses. Remembering passwords for every single WordPress site is a pain. Integrating with technologies that are not built in PHP is a problem. The microservices philosophy—a design pattern where each part of a system is handled by a stand alone application to maximize scalability and improve development speed—is very hard to implement.

I assume that realizing how the distributed nature of WordPress is both a strength and weakness was what lead Automattic to develop Jetpack. Jetpack is, in many ways, the original hybrid plugin/SaaS product. For example, Jetpack has a lot of features that make perfect sense as a plugin, while leveraging Automattic’s servers for elastic search, related content, and social sharing that make better sense as cloud services.

Both in terms of designing our hybrid business model and building the app itself, I’ve been able to rethink WordPress as the monolithic entity that does everything. We recently added pretty advanced error logging to Caldera Forms Pro to help us improve the quality of support we offer.

At first, I had the same app that handles emails receive and store the logs. But, I got concerned that we would now be dealing with two streams of requests and how this would affect scaling. So I quickly moved the log endpoint to a separate microservice built using the Lumen micro-framework. That separated the two applications into two servers and since the logging app only does one thing, it can be way more performant. I can also iterate faster on this new feature knowing it’s decoupled from the main app.

We now have our WordPress site handling eCommerce, the logging microapp and the main app for everything but logging and eCommerce. As we grow the stack I would expect more microservices to be added to separate out features from the main app to improve scalability and reuse.

Is Your Future Hybrid?

This hybrid approach—a plugin with a SaaS service—isn’t for everyone. The developer demands are different, and add initial complexity that I think is worth it in the long run. Also, whether it makes sense from a consumer perspective is something we will know for our business until we’ve had more time. But I’m confident that because we’re solving real user problems and focusing on delivering value it will work for us.

This hybrid approach also has a lot of application beyond commercial plugins. It’s becoming more standard to solve front-end UI problems in WordPress with modern JavaScript frameworks like React and VueJS connecting to WordPress via the REST API. That’s a great first step towards decoupling the various concerns in the stack. Embracing a more granular instead of monolithic approach to the stack and looking at other technologies can lead to finding a different tool than WordPress or even PHP for some problems. We can still love WordPress but instead of hacking on top of its technical debt finding a better solution for certain requirements in our work.

I’d say the future of web development is modular, but that future is here. While WordPress isn’t as flexibly modular as it needs to be, it’s still a part of the stack for a ton of good reasons: ubiquity, low-cost, varied and mature eCommerce and marketing automation solutions, flexible post type API, great user management, extensibility, CLI, REST API and an amazing community. Also, it’s great for managing content like documentation, products and blog posts.