Struggles Developing a Commercial WordPress Plugin

Development Challenges Image

Building software to sell is a tricky business. It isn’t always as simple as writing code and getting people to buy it. WordPress commercial plugins come with their own set of considerations, issues and complications.

Here at Delicious Brains we’ve gone down the route of having a free “lite” plugin on WordPress.org along with a “pro” plugin: a commercial version that beefs up the functionality and comes with email support. It’s a model that has worked well for WP Migrate DB Pro and is the same path we’re taking for the upcoming commercial edition of the Amazon S3 and CloudFront (AS3CF Pro) plugin.

However, throw the potential for addon functionality, pricing, branding and code issues into the mix and things get complicated rather quickly. I thought it would be helpful for others (and cathartic for us!) to step through some of the challenges we have faced recently and how to mitigate them in the future.

Pragmatic Pricing

It has been said and written about many times before: pricing is hard. There is a lot to think about with pricing: choosing the right pricing model for your plugin, deciding on price points, and working out license tiers and limitations.

It is generally accepted these days that commercial plugins are sold with an annual license giving the customer 1 year of access to support and software updates. It’s also common that the license tiers are limited by the number of sites the license can be activated on. But sometimes you need to consider your plugin’s functionality in deciding potential license limitations, as a site install limit isn’t necessarily a fit for every plugin.

We have been discussing internally how to price AS3CF Pro for a while now, and Brad actually briefly mentioned one of the possibilities at the end of his “Sneak Peek” post back in February. That tiny mention sparked some great discussion in the comments with, interestingly, some negativity around the idea of using the total number of items in the Media Library as a limit. To me this reaction showed just how generally accepted and widespread the site install license limit model has become.

Whatever you decide on pricing for your plugin, it is important to be flexible with pricing. Just because you set X at Day 1, doesn’t mean you can’t tweak and change things. You need to try things, test out ideas and optimize prices where needed.

Expect the Unexpected

One of the things I love about software development is the simplicity around the development process. Got a bug reported? Log it, reproduce it, and fix it. New feature requested? Discuss it, outline it, and build it. However, sometimes things don’t always work out like that, and what seems like a straightforward enhancement can actually open a can of worms or quickly spiral into a complex set of changes.

We encountered this very scenario when working on the planned “CSS & JS” addon for AS3CF Pro. Simply put, the addon will offload CSS and JS files to S3 that are enqueued on a site and then serve them from S3 or CloudFront (or another CDN). Like with images, it would be great for high traffic sites to utilize S3 and CloudFront to reduce server bandwidth and speed up delivery.

Using WordPress’ enqueuing system hooks, it was pretty easy to detect a CSS or JS file, upload it to S3, and swap out the local URL for the S3 one. The majority of the feature was built out pretty quickly. It had gone all the way through a code review and functional review before Brad picked up on an issue with the original specification that quickly took us back to the drawing board:

Scenario: Your theme has a style.css file that is enqueued as normal. Great, we can grab that file, upload it to S3 and make sure we serve the S3 URL. However, the style.css file @imports other CSS files and references font files and images using relative paths. As we only copied style.css to S3, the browser won’t find any of these other files on S3 and will present 404 errors for them.

This meant we had to completely revisit our approach for uploading files to S3 to make sure we cover all files that could be used. This set us back a fair bit in our development timeline and has had a negative impact on our release date, which leads nicely to the next challenge.

Manage Expectations

Since we started work on AS3CF Pro, we have been transparent and open about its development. We introduced a sidebar in the free version informing users of the upcoming pro version and allowing them to sign up to be notified when it’s released. We also started blogging about its development and doing walkthroughs of its addons. Of course this is great marketing but as soon as you present users and potential customers with the “what”, they start asking the “when”.

In the past with my own plugins I have fallen into the trap of being a “Yes Man”, always giving customers quick and sometimes impossible timescales for a feature release date. This has more often than not lead to stress and corner cutting to meet the deadline. The times when the deadline has not been met resulted in disappointed customers and damage to my reputation.

This whole problem goes away if you don’t set public dates for releases. As Brad mentions on the Apply Filters podcast, these deadlines are arbitrary anyway and so why create them? Of course security patches and hotfixes are generally pushed out as fast as humanly possible, but for feature releases and new plugin releases, the public timescales need to be flexible. No timescales and a protracted development time can, not surprisingly, lead to frustration from users, which we’ve encountered. However, I believe that frustration from a missed deadline would be worse, and as long as there is frequent communication throughout the development process, users won’t be disappointed.

Plan for the Future

When building a commercial plugin it is worth considering the potential scope of your plugin. You may have a free plugin and a great deal of functionality to add. However, if all the functionality doesn’t necessarily need to work together, then the Addon model might be a good fit, and indeed is successful for some.

With the “Lite & Pro” model, you have to consider how much code and functionality is going to go into the pro version. There are two main aspects to think about here, and it’s a balancing act:

  1. You don’t want to restrict too much functionality from the free plugin and reduce its usefulness. The more happy users you have of the free plugin, the more paying customers you’ll convert to the pro version.
  2. You also don’t want to bloat the pro version with too much unconnected functionality that won’t be needed by the majority of customers. For example, we have developed both WooCommerce and Easy Digital Downloads addons for AS3CF Pro, which will only be used by a specific subset of customers. If that is the case then you could think about creating addons to the pro plugin and tying this into your pricing model. For example, we offer a couple of addons for WP Migrate DB Pro and these are only available to Developer license holders and above.

The Name’s Bond. James Bond

Naming is one thing, branding is another. Some plugins work their functionality into the name, or create a whole new brand for the plugin. If you build on an existing free plugin, generally the “Pro” suffix will suffice. However, in this case the name of our free plugin uses Amazon’s trademarks which could be a problem. If we just called it “Amazon S3 & CloudFront Pro” we could get in trouble with Amazon for using their trademark. Moreover, we wouldn’t be able have our own trademark to protect against someone else calling their product the same thing.

For those very good reasons, we’ve decided to rename the free plugin “WP Offload S3” when we launch the pro version. After much discussion with the team, we thought that the shorter the better, as something like “WP Offload for Amazon S3 and CloudFront” would be just too many syllables!

Have you faced these challenges with your own plugins? Let us know if you have any tips for the future.

About the Author

Iain Poulson

Iain is a WordPress and PHP developer from England. He builds free and premium plugins, as well as occasionally blogging about WordPress. Moonlights as a PhpStorm evangelist.

  • This article describes some of the things I’ve been thinking about lately. I’ve had plans for years to make a pro version of one of my free plugins and recently realized that the best option for me was to start with a new plugin based on the old one. I’m planning on using the free/add-on model but still wonder if this is the best approach.
    I’m going to try not to set public release dates, but as you said, people want to know “when”.

  • paulhalfpenny

    Why not choose something more generic like WP CDN Offload for the plugin name? This would allow you to expand the product at a later date to use other CDNs such as Akamai (Rackspace) or MaxCDN.

    I can see the initial value of using S3 in the name, given the searches that must happen for WordPress/S3 integration, but in the long-term, you might want to open it up for additional usage?

    • I think there is room for further products with the name, but we will see 🙂

  • donkeyjong

    Grammarnazi here: “It’s also common that the license tiers are limited by the number of sites it can the license can be activated on”. A great read for me as I am in the startingblocks of creating premium plugins.. I too like the “lite” approach or freemium. I’d love to see a more technical post about tips and what to avoid when it comes to licensing, pushing out updates through WP, modularity of a “lite” and “pro” plugin etc.

  • José Vega

    Good post. However, what I don´t understand is why you don´t launch the pro version already? I mean, it seems like you want to have a good number of add-ons ready for the main pro version launch.

    But this actually slows down your business.

    For example, I recently needed to move thousands of images to amazon and I found out about the pro version. I was desperate to use your pro version because I didnt find good alternatives. The only pro features I needed was to move existing media items.

    I would be now a happy customer, instead I´m reading your delaying the launch for developing add-ons, don´t get me wrong, they sound very interesting but we could start using the main plugin right now.

    • Thanks José, rest assured we are working hard to get it out the door!

  • Thank you for this post—I enjoyed reading it. I am in the process of sunsetting my one and only commercial plugin—one that I created five years ago. The largest lesson I learned as a commercial plugin developer (apart from learning that I’m not a great businessman) is that being able to support your plugin in a managed way is absolutely critical to the health of the plugin and the business. We spent the vast major of our dev time fielding support requests—not because the plugin was hard to use, but because the process that the plugin existed to facilitate (autoposting to social media) was difficult to configure and inherently unstable (move fast and break things—thanks Facebook). I’ve written about the experience and what I want to try to do next in my own blog: http://aaroncollegeman.sites.fatpandadev.com/the-story-of-sharepress-and-the-future-of-social-media/

  • Grant Palin

    Definitely food for thought as I am contemplating the commercialization possibilities of a plugin I’ve been working on for a while. Spending a lot of brain cycles on the licensing model.

    • Hope it goes well Grant, let me know what you decide.

  • Thanks for the post.

    In my project, I created a free plugin, then I kept getting feature requests, I took notes and started to develop these features in a form of a Pro paid plugin. Since then, I developed on top of that another two pro plugins and some add-ons (around 10 add-ons), which does different tasks.

    Things got too complicated in almost no time! I was selling all three pro plugins in one package. The whole deal was confusing to many potential customers, they couldn’t decide which plugin to use.

    I end up separating the most advanced plugin and its add-ons, I moved them to their own new website and domain name, so I toke them off the package and got a new home for it.

    Even though, I was publishing several blog posts, sending out emails to all members….etc, it didn’t seem to inform everyone! I am still in the middle of the road though, it’s like solving a puzzle lol, but the good thing is I already know it’s not that easy to make such move!

    I am not sure which model works best, it depends on several metrics, however I am more into the free+premium and add-ons model, not forgetting that pricing and licensing may need some tweaking in the road.

    Good luck!

    • Thanks Hesham, good luck with the plugins and tweaking.

  • Great post. I’m looking at the possibility of doing a premium version of my first plugin, but that’s still quite a way down the road. I just submitted it for approval yesterday after a somewhat lengthy development process. I had the added complexity of not being a programmer, so I hired somebody to build it.

    The issues of features in the free vs. pro versions and pricing seem to be a bit of a black art. I’ve decided to put the plugin up for free on the WordPress directory, try to generate interest, and if it gains any traction, release a premium version a little later.

    It was very tempting to hold out on all but the most basic features for the free version, but I decided against that and still have more features I plan on adding in a point release. There are a few features I’m definitely only going to offer in the premium version, but am hoping that user feedback will give me some other ideas as to what will make it worth paying for.

    • Thanks Ned, you’re right it is a black art! I personally think having the free plugin on wp.org is a great start, simply for marketing. Good luck with the plugin!

  • Iain – This is a timely post for me. We are in the midst of launching a premium plugin, called SkyStats – A Better WordPress Dashboard. One of the things I found in this process is that WordPress developers lack the understanding on how to properly optimize their WordPress Repository listing. Coming from an SEO background, the optimization strategy for the WordPress Repository is a bit basic (think SEO tactics in 1996). There isn’t too much information on the web regarding optimization tactics, so this has been a bit of trial and error that has paid off so far.

    • Interesting, I hadn’t thought much about optimizing the wp.org listing – blog post? 🙂