Converting your plugin to Software as a Service could prove to be fanSaaStic for your product-making journey đ Seriously, though â SaaS offers developers an opportunity to service bigger markets and potentially grow their products into empires. Assuming youâre ready to take up the mantle of SaaS emperor đ how does one transition from a WordPress plugin to SaaS?
Youâve weighed up the considerations discussed in WordPress Plugins vs. SaaS: Whatâs the Difference & Which to Choose and Signs Your Product Has The Potential To Become a SaaS.
Your SaaSpirations seem plausible and youâre keen to get the $aa$ party started, but what are the practical things you need to do? Freemius CEO and founder Vova Feldman has been building SaaS startups since 2009 and knows the more extensive considerations + practical steps to transform a plugin to SaaS. In this article, he shares some handy pointers to help you facilitate the process.
SIDE NOTE: Iâm not sure if youâre aware, but Freemius is, in fact, a SaaS. We cater to plugin, theme, and static software WordPress developers, but our offering also extends to SaaSpreneurs. Youâre welcome to get in touch with us if you need some technical support while making the move from plugin to SaaS but in the meantime, weâve put together the fundamental pieces of the puzzle to help you get going.
Should You Start With a Plugin or SaaS?
Suppose your idea for a software product has not yet crystallized. In other words: If you have a SaaS-worthy concept, is it better to test it as a plugin first? Vova answers below:
As mentioned above, you (technically) donât even need a website to distribute a plugin. With SaaS, itâs the complete opposite because a website is essential for delivering the software â thereâs no way around it. To elaborate on the video: Whereas plugins donât require dashboards for configuring settings on your end, SaaSes do. WordPress core already provides the infrastructure and APIs for creating those settings pages but with a SaaS, youâll need to build a dashboard with product settings yourself.
Starting with a WordPress plugin is an effective way to validate if thereâs demand for your product or service, too. â Before you invest all the technical resources required for SaaS, you can just push out something, see how it goes, and iterate the product based on feedback,â Vova explains. â It helps you figure out if thereâs a product-market fit before you take a massive leap of faith with little to no feedback to go on. Once youâve established that, you can go ahead and transition or expand into a SaaS. â
Of course, this doesnât imply that WordPress or similar ecosystems should merely be treated as sandboxes for potential SaaS candidates, but:
If you want to do something fast, itâs logical to opt for the easiest way. And if you know from the beginning that your product idea ticks all the right boxes for SaaS, build your plugin with that in mind. The way you code it will make for a more concrete and seamless structure if and when itâs time to transition to SaaS.
Back to the main premise: youâve got a WordPress plugin, itâs performing well, and youâre confident it could shine as a SaaSâŚ
Converting Your WordPress Plugin to SaaS
Determine the Architecture and Design of Your Service
â I think this is the most fundamental, technical thing youâll need to figure out to transition from a WordPress plugin to a SaaS,â Vova says.
In a previous SaaS article, we discussed how distributed software â like WordPress plugins â works. In a nutshell, the software is sold as a product to users, who must download, install, and run it on their hosted server. Itâs also the userâs responsibility to download and install updates and improvements to the plugin. This is the opposite of SaaS, which is served âready to goâ and doesnât have to be downloaded, thanks to being cloud-based. This seamlessness also means that SaaS automatically feeds through changes to the entire user base.
â With WordPress plugins, every node â in other words, every website your plugin is running on â takes care of the resource requirements. If you suddenly have, for argumentâs sake, a million users to serve after youâve transitioned to SaaS, the consumption is much higher than before. â
Separating User Interface from Business Logic
Following modern web development practices, your high-level architecture should have a clear separation between your SaaSâs UI and its BL, which can be achieved by using a RESTful or GraphQL API. This front-end/back-end decoupling provides the all-important flexibility to work with different technologies and change them as you go.
For example: You build your SaaS dashboard using ReactJS. If the go-to framework is no longer ReactJS three years from now and you decide to switch, youâll be able to do so easily without the need to make any changes to the âbrainsâ of your SaaS.
Server-less is More!
If youâre not experienced with servers and cloud computing, a great solution for the API implementation is going Serverless. It allows you to skip a lot of hassle and focus on building your SaaSâs âbrainsâ without thinking of the overhead, which simplifies everything.
If youâre unfamiliar with Serverless, hereâs the definition from IBM:
âServerless is a cloud computing application development and execution model that enables developers to build and run application code without provisioning or managing servers or backend infrastructure.â
â Amazon has a Serverless solution called Lambda. Cloudflare offers Workers. Google has its App Engine. And there are many more solutions out there that offer similar capabilities,â Vova says.
Optimize Your Architecture for Cost â You Have To!
While serverless is great, financial ramifications may arise â especially when it comes to scaling.
When your SaaS is still fresh and only has a few users, Serverlessâs services will be much more affordable as they charge according to the number of requests (and you wonât have many). But when your resource consumption starts growing, a single, well-configured AWS EC2 with Nginx can run millions of requests per day at a very affordable price (which will be way cheaper than Serverless).
With plugins, you simply donât have to consider resource consumption costs as you rely on the WordPress serverâs resources to execute your plugin. But â as youâll realize in time â when it comes to SaaS, incorporating financial optimization is a meaningful part of technical design. If the cost to support a SaaS customer is higher than what theyâre willing to pay, youâre going to have a problem. No matter how amazing your SaaS is, the numbers have to check out. If they donât, youâre doomed to fail.
Scale with Cloud Computing
Unless your margin with Serverless is healthy to begin with, youâll probably consider making a few transitions at some point when you start scaling. This will include things like setting up your own cloud servers, managing database and storage, load balancers, caching layers, and a whole bunch of other âfunâ đ technicalities.
Whether you start with cloud computing from the get-go or get there when youâre ready to scaleâŚ
Recommended: Stick to Horizontal Scaling
If your servers run like APIs, they conform to a concept known as horizontal scaling. Vova explains:
To add to the above video: Suppose youâre on a single load balancer and you notice the consumption of your servers is getting exhausted/slowing down. Do I even need to say this is bad for business? đ
â Horizontal scaling is the recommended route for APIs. With vertical scaling, youâre just increasing the same server resources. The problem with vertical scaling is that at some point, and due to hardware costs that are not linear, every jump to higher resources gets more expensive â especially when the numbers are high. For example, itâs cheaper to run 192 servers with 16 GiB RAM than a single server with 3072 GiB RAM. So unless your SaaS does need a resource-intensive machine to run some special algorithms or big data mining, keep your API servers stateless and as light as possible so you can scale cost-effectively.â
Pricing Your SaaS
With WordPress plugins, the primary decision in setting your pricing is typically based on estimated support costs, market prices, and ongoing development. With SaaS, as mentioned before, you have to incorporate resource consumption as part of the equation.
For example, if you build a SaaS that offers some AI functionality that leverages ChatGPT, every request to ChatGPT comes with a cost. You can either add a margin on top of that or be transparent about your pricing â excluding the cost of ChatGPT requests â thereby delegating those costs directly to your SaaS customers.
The math is relatively easy when thereâs a clear price tag on your resources per user or requests (which is another benefit of serverless per request pricing), but when you start to manage servers, the math gets tricky. A single server can serve variable users and requests, but you still need to pay for the server whether itâs in use or not.
This is one of the reasons most SaaS products offer a monthly plan. As the SaaS owner, you have monthly server bills to cover, so itâs easier to get your customers aligned on the billing cycle.
Should You Stick to PHP?
â In terms of coding languages, you have a lot of freedom with SaaS. On one hand, freedom is good because it doesnât impose any limitations on what you can do. On the other, you need to use that freedom responsibly and avoid making costly mistakes. Obviously, with plugins, you have no choice but to use PHP.â
As to whether you should stick to PHP: thereâs no clear-cut answer, and it depends on your needs. Itâs up to you to decide if youâre going to keep your product in PHP or move to another language. Itâs definitely not a must, and itâs possible to do this in parallel if you intend to build out the SaaS separately from your plugin. That said, moving over to a new coding language may be useful if it offers meaningful benefits. âThis is especially true for AI products, for which there are far better and more specialized languages than PHP,â Vova says.
Itâs even possible to mix two coding languages and have them in different places. If you go this route, youâll need to figure out if (and how) the different languages will communicate with one another or whether theyâll take care of different functionalities with no cross-communication.
Youâll Need a Dashboard
â Users need access to a dashboard on your website where they can manage the product,â Vova says. â Itâs a place where they can adjust personalized settings around your SaaSâs interface for themselves.â
Set Up User Registration
As Iâve mentioned before, the nice thing about WordPress is the convenience; everything has been taken care of for the developer to start distributing their plugin, including user registration.
WordPress users can usually install your plugin on their website straight away, no questions asked. With SaaS, you need to design a user registration page for them to access your product, not to mention dealing with the responsibility of managing their private information as confidential data.
This leads us to the next point.
Legal Terms and Privacy
When offering a SaaS, you are liable for PII (Personal Identifying Information), whether for free users or customers. It depends on what your service does, though you are most likely managing additional data that is stored on cloud solutions and shared with third-party services.
Gone are the days when you could just push a free version to WordPress.org and everything else was up to the user who installed the plugin on their website.
Therefore, itâs important to include terms of service, privacy and cookie policies, etc. that are aligned with the service youâre offering. Luckily, you wonât need a professional to set this up for you from the get-go: there are effective online generator tools that can help you get started đŻ Later, when you scale and legal implications become more serious, you should get a lawyer to help you iron out the fine print.
Full Disclaimer: The above is not legal advice, and neither myself nor Freemius can be held responsible for any unintended consequences that may arise from following it.
Consider Implications for Customers
When your product is SaaS, everything is stored and running on âyourâ server: data, traffic, etc. You need to manage this effectively because any blunder on your side could lead to legal implications.
SaaS cancels out many of the no-strings-attached perks of plugins for customers, too. Instead of relying on a single WordPress plugin to add functionality to their website, they are suddenly dependent on a third party. â This can be a good or bad thing â it depends. For example, by selling and managing licenses through an eCommerce SaaS like Freemius, a heavy load is taken away from the storeâs server resources. And even if the storeâs site is down, subscription renewals will be properly processed and logged.â
However, Vova admits that convincing prospective users to trust a third party is not always easy.
For users who are used to working with WordPress plugins, thereâs a leap of faith that customers need to take before trusting that an external service is more stable than their own website. The service isnât a part of their core business, and they have to trust that bringing in a third party to provide it instead of employing a dedicated team is a wiser decision. In other words, they need to believe thereâs a bigger chance things will go wrong if they manage that aspect of their business themself.
There are many customer-related implications to keep in mind when transitioning to SaaS, but the independence and privacy factors loom large. â I think if you convert your plugin to a SaaS completely, youâll probably lose some of your existing customers. They may require the customizability that plugins offer as opposed to a hosted solution. With a SaaS, you lose some level of control, youâre restricted in what you can do, and you lose some flexibility.â
By now, it should be clear that transitioning to SaaS is doable but certainly no walk in the park. Depending on your state of mind, the next section will either leave you feeling relieved or peeved đ
You Could Build Your SaaS in WordPress
Although plugins and SaaS are different beasts, itâs possible for developers to build their SaaS products on WordPress. â Doing so will save you some mechanisms, and itâs probably the more natural route for plugin developers who are already familiar with WordPress,â Vova says. â It spares the headache of building from the ground up. â
There are many downsides to this approach and while itâs generally not the recommended route, itâs doable (we wonât get into the downsides at the risk of digressing from the article).
Time to come up for air! Weâve taken a deep dive into SaaS, and Iâd like to leave you with one final â but important â consideration.
SaaS Isnât the Be-All or End-All
If the stars donât align with your SaaSperations, thereâs still plenty of room to make a success of your software journey.
Yes: SaaS is the logical route if you dream of creating something unique or have ambitions for exponential market growth. But WordPress plugins fill a special niche that SaaS canât, and the joy of building a software product and growing a business with the WordPress communityâs advice and support should never be underestimated. Figure out which software model best suits your intents and purposes, and be sure to make a kick-ass product once youâve taken your pick.
Originally published on the Freemius blog on on September 6, 2023.
