The Challenges I Faced in Monetizing Easy Digital Downloads

Easy Digital Downloads is an e-commerce plugin for selling digital products through WordPress.

It is a free plugin hosted on WordPress.org, yet it is also fully monetized and brings in a substantial yearly revenue.

This article is going to look into some of the challenges my team and I have faced in building a sustainable business off of a plugin that is not only open source, but also given away at no cost.

Our Revenue Model

Before getting into some of the challenges we have faced – and are continuing to face – let’s briefly walk through what our revenue model is.

There are two revenue streams for the plugin:

1. Selling add-on plugins that provide additional features
2. Selling priority support access for faster, VIP support

The majority of the business’ revenue comes from add-on (extension) plugin sells. The revenue generated by priority support subscriptions counts towards the revenue as well, but the funds generated are sent directly back into the plugin by paying support technicians.

Encouraging Users to Upgrade While Still Providing a Well Balanced, Fully-Featured Plugin

One of the primary challenges we faced with commercializing via the premium extension model was finding the balance between a full-featured core plugin that users could use as is, and building the right features as paid upgrades that were important enough for users to purchase them.

If the core plugin was made too powerful, the majority of users would have no reason to ugrade, rendering the business model useless. Put too many features into paid upgrades and users will feel that the core plugin is intentionally crippled, creating a less than loyal user base.

From the business’ perspective, there is absolutely nothing wrong with highly-requested features being made available as a paid upgrade, but users will often feel cheated, resulting in negative reviews that hurts the adoption rate by future users. Yep there is also absolutely nothing wrong with not wanting to give too much away for free – after all, any code at all that is given away for free is already enormously generous.

Let’s look at a real example of a feature that we chose to make a paid upgrade but many users feel should be included for free.

Manual Purchases is a $15 extension that adds the ability to manually create purchase records. Anyone that has run an e-commerce store will probably agree that having the ability to manually create purchase records is very important and a task many need to perform on a daily basis.

On numerous occasions, we have had users complain about Manual Purchases being a paid upgrade, since they feel it is an integral feature of the plugin, thus removing it from the base plugin is “crippling” it.

I completely agree that making such a feature a paid upgrade is annoying, but I also happen to know that the necessity of the feature encourages many, many users to purchase the Manual Purchases extension. That means that the Manual Purchases extension has considerable value to the business, and it is our goal to create a sustainable business.

When it comes to integral features, discovering the balance between what should and should not be a paid upgrade is difficult when using a paid add-on model.

Charging for Support

When I first launched Easy Digital Downloads (when it was just me), I tried to offer two kinds of support:

1. Very basic questions about the plugin (pre-sales). This was free.
2. Paid support for everything else.

The idea was to not offer any technical support to anyone that was not a paid customer. If a user needed support, they could sign up for paid support, or they could purchase an extension, which included an automatic 30 days of support access.

On paper, it seemed like a very reasonable approach. Users already received a completely functional ecommerce solution for free, so asking users to pay a fee in order to get technical support shouldn’t be a problem.

It turned out that this model didn’t work at all for several reasons:

1. How do you handle users that encounter problems due to bugs in the plugin? As this happened several times while this model was in place, users felt very disinclined to pay for support in order to get help with a bug in the code.
2. What if the user’s issue only takes a few seconds to answer? Should they still need to pay for support? Right or wrong, many users were turned away because of this. When users feel slighted by support, they are more inclined to leave negative reviews, which only hurt the reputation of the plugin and the business.
3. All extension purchases came with 30 days of priority support, regardless of the price of the extension. This meant that an $80 extension gave the same level of support as a $6 extension. It also meant that users could purchase a $6 extension and get the same support access as they would get with a monthly support subscription. This was primarily a failure in my implementation of the support model, but it was still very clear that it would not work in the long run.

Getting Too Big, Too Fast

Experiencing rapid growth can be exceptionally challenging. When a user base is small enough, the infrastructure you have in place to manage those users’ support requests, feature requests, and transactions is not difficult to manage, even if your infrastructure is poor. Once your user / customer base rapidly expands, the various infrastructures you have in place become vitally important.

The majority of our revenue stream is through extension sales, and most of our extensions are built by someone other than myself. This is important because I was the only person early on that reviewed extension submissions. I was the guy from start to finish. I reviewed the extension code, tested the extension, reported bugs, setup the product pages, created the product images, set the pricing, setup the extension’s support forum, clicked publish and setup the newsletters and blog posts. I did it all. While this was easy to manage early on, once we got to the point of having 5-10 active extension developers submitting code for review each week, it became exceptionally difficult.

Early on, my method for keeping track of which extensions were getting built, which needed updated, and which were ready to go was my email inbox and it was impossible to manage.

As happened with managing extensions, the number of support requests we received each week grew exponentially as our user base got larger and larger. Initially, we didn’t actually have a way of tracking which support tickets were resolved, who was assigned to them, how many were currently open, which ones were waiting on staff replies or any of the other statistics or records that are vitally important to adequately managing customer support requests. Due to this, we lost track of a large number of tickets, some of which turned into 1 star reviews because the support was less than stellar.

Conclusion

Through all of the challenges, I believe we have come out on top. Here are some quick stats that help us see that it’s all been worth it:

• 94% of our users (that submitted a survey) would definitely recommend Easy Digital Downloads to a friend or family member
• 92% of users that rated Easy Digital Downloads on WordPress.org gave it a 5 star rating
• Easy Digital Downloads is approaching $500,000 in annual revenue
• More than $120,679.30 has been paid out to 3rd party extension developers

Are we done? Definitely not. Have we faced our most difficult challenges? Probably not, and that’s okay.