Lessons Learned Maintaining An Already Successful WordPress Plugin

As most readers of this will know WordPress is an extremely powerful Content Management System that as of the time of this publication powers ~29% of all sites on the internet. To say that it’s a Best of Class product is a huge understatement.

In December 2016 I got an email from a friend and colleague letting me know that the previous owner of Seriously Simple Podcasting, Hugh Lashbrooke, was interested in selling the plugin and add-on modules as he was focusing solely on his work with Automattic.

As I was already heavily involved in the podcasting world through my work on PodcastMotor, our podcast editing and production services business, I thought this could really be a neat way to both get involved directly in the WordPress space, and in podcasting technologies.

Needless to say that my review of the product that Hugh built was impressive. The code read very well, was thoroughly documented, and it was obvious that his support practices were top notch based on the nearly 100 Five-Star reviews in WordPress.org.

All of the success that Seriously Simple Podcasting had up to this point was both a great asset, but also truthfully a bit daunting.

I had some questions for myself about how I would manage the support of such a popular plugin (nearly 20,000 installs and growing every day), how we would add core features and premium functionality into the plugin to monetize it, and what taking over someone else’s work would really be like.

For anyone who’s been in the same position I’m sure you can relate, but for those of you entering this space for the first time, I wanted to outline a few of the things that we’ve learned along the way managing, and growing, an already successful WordPress plugin, and maybe a few things we’d do differently next time.

Maintaining Excellent Support

Overall this was be the biggest challenge we faced in the first few months. With so many active users and with a relatively complex product (we interface not only with WordPress but also the criteria of iTunes, Stitcher, and Google Play, all of which are changing constantly), we face a decently high service volume via the WordPress.org support forums.

As a non-technical owner of the plugin I was able to manage a fair bit of the support inquiries, but I have to be honest that relative to the previous owner I was falling quite short in providing the in-depth responses that some of our customers were looking for.

We were blessed to have extensive documentation of all of the ‘major’ things that customers could run into, but when it came to edge cases and modifications to the plugin I just wasn’t able to provide concrete solutions in a way that Hugh was able to previously.

At this time our developer was already hard at work on our integrated hosting platform, Seriously Simple Hosting, but I had not asked him to help out too much in the WordPress.org support forums.

This was a mistake.

And our users in the WordPress community let us know about it, unfortunately in the form of bad reviews. This was really crushing to me.

I can pretty confidently say that at this point we’ve resolved this issue, with both of our developers being actively involved in the support forums for more complex issues, and we’ve had nothing but 5-star reviews for the past few months.

Now with 130 5-star reviews I’m confident that both our solution, and the support we provide around that solution, are top notch.

The WordPress repository continues to be our main source of traffic and growth, for the free plugin and even now for Seriously Simple Hosting, and I should have known better than to take for granted the relationship that we’d built with our customers and the WordPress community. That’s a mistake I won’t repeat again.

Developing Additional Features for the Free Plugin

After getting a better understanding of the support dynamics of the free plugin, our focus turned to adding some additional features to it.

As is the case with any development project we pulled from our own experience as users of the product, and the feedback that we were receiving from our customers. For us this meant that there were some simple, yet powerful, features that we could add that would do a lot for our customers usage.

The first of this was a “Leave a Review” button below the media player that would take website visitors directly to the podcast page in iTunes.

This may seem like a small thing, but in the world of podcast SEO the ratings and reviews of a podcast are by far the easiest thing you can affect to increase your rankings in your podcast’s iTunes category. So we viewed this as a feature that was both unobtrusive to existing users, but added a lot of value at the same time.

Next on the list was to add some functionality to the shortcode library that we have within the plugin. Things like being able to limit the # of episodes featured in our

were added to the core plugin so that users had more control of what, and how, podcast media was displayed on their site.

From there we have set off to completely redesign the media player. Much more on this to come in future posts, but suffice it to say that we’re giving the media player both a new look, and some really neat features that we would consider essential in any website’s podcast player.

Of course there is a balance to be reached with this, as the podcast player is already a front-end element on almost every one of our customers’ sites. So changes we make here could have a big impact on how their sites look, and how website visitors interact with the podcast on their site.

This one example embodies the balance we must strike when evaluating existing code and planning for new features.

Building a Roadmap for Premium Features

Once we got an understanding of how to properly support our existing users and continue building the features they wanted for the core plugin it was time to start road mapping a premium feature set.

From the outset I knew, from being involved with podcasters every day in PodcastMotor as well as being a podcaster myself, that there were a few things that all podcasters ‘needed’.

• Media Hosting
• Statistics
• A way to grow their audience

The first two were obvious first places to look to focus our development efforts for Seriously Simple Podcasting.

At the time of this writing I would say there’s a half dozen solid competitors in the podcast hosting space, and only one that works tightly with WordPress.

This nice balance of some existing competition but also not an overly saturated market told me that there was room to enter the space and hopefully disrupt some of the existing players with slightly different offerings.

So in January we broke ground on the codebase for Seriously Simple Hosting. A few months later, in May 2017, we launched our initial version, and have met with really positive response from all of our users.

Providing a hosting platform for your podcast that is tightly integrated with WordPress, the place where you manage the rest of your podcast content such as Show Notes and other audience updates, is a natural fit for most.

Since the launch of Seriously Simple Hosting we’ve continued on the path of listening to our customers, and integrating their feedback directly into our products.

The pending launch of v1.17 of Seriously Simple Podcasting is a prime example of this, and we’re really proud of the steps we’ve taken to make both the plugin and the hosting platform much more robust and user friendly.

Development considerations for a large, existing user base

Something that seems obvious but is tougher to take into practical considerations is how making changes to the codebase can actually affect the existing users of our product.

In WordPress this is even a bit more complicated due to the large number of possible combinations when it comes to hosting providers, other active plugins on a site, PHP versions, WordPress versions, just to name a few.

In release 1.16 of Seriously Simple Podcasting, the first to introduce Seriously Simple Hosting, we ran square into this with some edge cases that we weren’t able to predict having conflicts with our codebase.

Specifically this came into light with an AWS library that we were using that required PHP version 5.4 or higher, and a conflict that came up with another plugin that utilizes another version of this AWS library.

Requiring our users to upgrade their PHP version several steps just wasn’t a viable option, even though the PHP version they were using in some cases was 7 years old, WordPress supporting back to 5.2 meant that we needed to get as close to that inclusion as we could.

This meant back to the drawing board and refactoring the hosting platform to utilize an older AWS library that was compatible with older PHP versions.

Fortunately this refactoring also resolved our conflict with the other popular AWS based plugin, because now they would be using the same library.

How our development practices have changed since our first major release

In theory all of this is nice, right? But what it doesn’t tell you is how we’ve actually changed our business and development practices since we’ve started learning some of these lessons the hard way. Here’s a list of things we’ve incorporated into our development practice since our first release:

Development Workflow

• GitFlow – a very robust Git practice in which features, bugs, and new branches are heavily utilized in order to make pushing to production, and rolling back if necessary, very easy.
• Multiple virtual boxes for testing of final products – we’ve set up multiple virtual boxes on our development environments to test different versions of WordPress, PHP, and other popular plugins alongside any development changes we’re making on a new version of the plugin
• Beta testing for select customers – the last several releases we’ve had we have actually sent a live beta version of the plugin to a dozen or so clients prior to the release on WordPress.org. This means that we’re getting some great ‘real-world’ experience with the plugin in the wild before it goes live to the 20,000 users.

Business Workflow

We’ve grown from one to two developers who are working on different parts of Seriously Simple Podcasting. As we identify new aspects of the market that we can get into, and different technology offerings that would suit our customers it’s become apparent that we need to move quickly into some of these spaces. As with most things two heads is proving to be better than one and we’re finding new ways to solve problems, new technologies to use, and more robust ways to create these solutions.

We’ve started using a tool called CodeTree as well to manage GitHub issues across the 5 public and 1 private GitHub repository that we manage between Seriously Simple Podcasting, it’s 4 add-on modules, and Seriously Simple Hosting. CodeTree lets me assign tasks to each of our developers, allow us to track towards release goals as a group across the different repositories, and communicate in a more asynchronous way that doesn’t affect workflow of anyone on the team.

We also use Slack, but while it’s great for quick messages it should not be the way that any team organizes their efforts. Something asynchronous like CodeTree or another project management tool is key in letting everyone know what the larger plan is, where they fit in to it, and what the next milestone looks like.

Looking Forward

Now that we’re solidly 3 months out from the launch of Seriously Simple Hosting and 6 months into managing Seriously Simple Podcasting as a whole we’ve learned a lot. As I look forward the few areas that I know we’ll continue to focus on and improve upon are:

• Refining our approach to customer support so that customers receive quicker, more thorough support. This will likely mean adding a dedicated support specialist. (If you’re interested shoot us a message, we’d love to hear from you).
• Adding more features for our existing customers and finding ways to create new submarkets for users of the free plugin who don’t need a new podcast hosting solution.
• Creating a more streamlined development workflow. In an ideal world there shouldn’t be anything that’s last minute, urgent, or unexpected. I know this is likely never possible, but that’s the goal that we should all be working towards, and as the non-technical member of the team it’s up to me to provide the framework through which our developers can achieve this workplace environment.

Back To You

Have you been in our shoes and found yourself in a new environment managing an already successful project? What did you learn along the way? Would love to hear from you.

Leave a comment below and tell us all about it.