This past year I have launched a WordPress SaaS product and as I have been adding features and adding to it I keep finding myself asking the same question. Should I build each feature as a separate plugin or group them together in larger plugins?

Based on feedback I received from a few people on Twitter earlier this year, I am under the impression that as long as everything is coded properly there is no performance benefit necessarily from either option. Functionality being the same as well, I am looking at this question purely from an organizational, ease of development, and project management perspective.

I determined early on that I didn’t want the entire product in a single plugin because it is hard to organize tasks and track the development of each feature. Right now, I have features grouped by common functionality.  For example, I have one plugin that has all of my dashboard related features in it, such as modifying roles and capabilities, tweaking the editor, modifying image uploads, etc. As I start looking to integrate third-party plugins, such as Jetpack and Gravity Forms, into my product, I plan to make one plugin to house all code needed to integrate all third-party plugins.

Taking my current structure and breaking it down one step further, I could build each as a separate plugin. For example have individual plugins for roles and capabilities, the editor, the media library, Jetpack integration, Gravity Forms integration, etc. My gut tells me that this level of granularity would be overkill,  but I keep asking myself the question.

With this post,  I am hoping to gather feedback, recommendations and opinions from others in the WordPress development world on how they have, or would, approach this and why. While the product I am working on right now is fairly small, I expect it to grow to be quite large over the coming years and am trying to set myself up for the future and make long-term development and maintenance more efficient.

If you have a few minutes and wouldn’t mind leaving me your thoughts in the comments, I would greatly appreciate it. Thank you in advance!

5 thoughts on “Planning a Large WordPress SaaS Product”

  1. Hey Josh,

    Based on your post your product is a SaaS product so I’m guessing your codebase won’t be distributed to other developers. If that’s the case I’d be inclined to bundle all the compatibility plugins (for Jetpack, Gravity Forms, etc) inside a ‘compatibility’ plugin with subfolders per plugin then use autoload the classes in PHP as they are required.

    I think your existing approach with your current plugins sounds ideal. I’d only get more granular if your plugin codebase will be distributed to other developers. If I’m buying a plugin I want the codebase to be as lean as possible for when I’m digging into it looking for hooks or classes to extend for my needs.

    That’s my two cents for you 😀

  2. Hey Josh. Sounds like a cool project and I love the question. Without going super deep, I’ll keep my input straightforward and simply advocate for modularity. In all of our custom projects, we’ve consistently found it to be strategically beneficial to make our functionality as modular as possible. By this I mean, typically more separate plugins are better. I’ll give some examples why we’ve adopted this approach.

    – It is extremely helpful for troubleshooting purposes to be able to, with a couple clicks, temporarily turn off certain functionality. Whenever something on a site isn’t working right, finding the source of the problem is easier if you can simply start deactivating plugins until the problem goes away.
    – There have been many instances in which we’ve developed functionality that we want to reuse on other projects. This could be because we turned a site into a multisite and now want to activate some of the features on other sites across the network or simply deploying the functionality on a completely different site. If the functionality is straightforward and already its own plugin, this is cake.
    – Occasionally, something we’ve developed for a project becomes a candidate for public distribution, be it on the w.org plugin repository, github.com or as a commercial product. In these cases, we’re always grateful we’ve kept everything in its own plugin as opposed to bundling everything together.
    – Now and then a new employee, contractor, partner or friend enters the scenario to collaborate on something specific. When this happens, it is simpler to selectively grant access to github repositories based on what someone’s contributing when features are separated logically.

    In the end, this is how we tackle things but every project is different and our scenarios are not the same as yours. Ultimately, I recommend you set yourself up with a protocol that makes sense to you and doesn’t get in your way or set you up for future headaches. The good news is, there isn’t a “right” way. Do what works for you. Best of luck on this project!

  3. I’m currently in the middle of a large build of a corporate Intranet, built on top of a single WordPress instance. We have written several plugins, as well as a custom theme which has several enhancements.

    The plugins are built around a set of features that have some commonality. For example, we are using Markdown rather than HTML within the post editor. We needed a plugin that could handle the conversion of Markdown, plus we needed to add some additional elements (GovSpeak) that enhances vanilla Markdown.

    We also created a plugin that added a Markdown preview pane, offering a live preview of the compile Markdown. Over time it was agreed that it made sense to couple these two plugins together. The plugin was written with reuse in mind, although this was a secondary requirement.

    If a feature is deemed site specific, it generally lives within our theme, but as the theme grows larger this may not always be the case.

  4. Hey Josh,

    To piggy-back on what Kyle said above, I’d err on the side of modularity. Being able to disable specific features when bug-testing is huge.

    It may seem like a pain to deal with multiple plugins, especially when they cover a wide swath of functionality, but in the end, I think it will serve you better.

Leave a reply

Your email address will not be published. Required fields are marked *