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.

(Our friends at Freemius have a resource that goes into this plugin pricing question in more depth.)

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.