Deciding what get’s released as a paid add-on and what get’s rolled right into the free core plugin may be one of the most challenging things in your add-on business’s success. There are a number of different views on this topic but the two most common are as follows.
The 80/20 Principle
People who promote this principle generally say that if 80 percent of the user base would use a feature than it should be a part of the core plugin. On one level this makes complete sense. If you want your core plugin to have a wider adoption it stands to reason you would put in all the features that a majority of users would need.
This concept is also pretty straightforward. Keep your core free plugin light and lean. Anything beyond that should be a paid add-on. This always backfires in my opinion but I understand it’s allure.
When it comes right down to it there is no easy formula for this. There is a lot of gut instinct involved and a lot of chance taking. What goes into your free core plugin and what should be sold as an add-on is a challenging part of the business. So far I’ve been pretty successful at it.
How I decide what should be an add-on and what should go in my core plugin
Let me share some of the questions I ask when trying to make that decision. These are not hard fast rules. These are things that I consider and sometimes I still have to go with my gut and against conventional wisdom.
To provide some context I will share two features from my plugin Ninja Forms. Let me explain what they are so you can follow along better.
One feature is the Emails & Actions system that was released for free in version 2.8 of Ninja Forms. This feature allows you to create an unlimited numbers of email notifications and other processing actions when a form is submitted. It’s extremely powerful and flexible. Soon all of our add-ons that do anything with processing will be moved to this system.
The other feature is our newest add-on launched just today called Webhooks. This is a really cool add-on that actually leverages the Emails & Actions system. It allows you to send your form submission to any external API as a POST or GET query. You can map any field to any key name you like and send that data as JSON as needed. It’s very cool.
Now let’s look at the types of things I’m thinking about when making the add-on/core decision. With each one I’ll discuss these two features as an example.
How many requests do we get for it?
This is almost always the first step before we consider building something. There are occasions where we have an idea that we think people will love and they just don’t know how much they want it yet, but in most instances users have already requested enough features that we have plenty to work on if we want.
Emails & Actions: We got almost no requests for this. Most other plugins like ours only allowed for a couple emails to be sent. That was the standard and most were content with that.
Webhooks: We got quite a few requests for this. At least enough to want to solve the problem for our users.
Will it sell?
I know this seems like an obvious question but how well something will sell is still a key component of whether we will spend our time on it. Just because a feature is requested doesn’t mean people will pay for it. It really depends on the individual feature and even the implementation of it.
Emails & Actions: I think we could have sold it and over time as users could see examples of how awesome the system really is, those sales could have increased. The issue was still that most were content with their simple admin and user emails they already had available.
Webhooks: I think this will sell. The people who want this feature really want this feature. It also opens the door for creating really custom integrations with almost any service. It’s not going to be a best seller or anything but it will sell.
How heavy will the support be?
Some things have almost zero footprint from a support perspective. Other seemingly simple ideas can have huge support implications. This is something that you can only begin to predict after you have been supporting a product for a while. After almost 4 years I’ve become pretty good at it.
Emails & Actions: Emails are a heavy support issue for any form plugin. The way we were doing emails before was far more complicated. This feature promised to decrease our support load.
Webhooks: Yes, this will be fairly heavy on support I believe. The reason is that you are dealing with external services. All we do is send the data as the user has specified. This will not stop them from reaching out to us when they can’t figure out how that data needs to be mapped. The add-on is meant for more competent assemblers and developers, but some end users are still going to want it and have some troubles.
Will other add-ons be able to leverage this feature?
A terrible practice is requiring a paid add-on in order to use another paid add-on. Some feel like the add-on model nickel and dimes people as it is. If your customer needs to purchase something to get something else they purchased to work properly I might agree with them. Not to mention that having a feature that can be fully extended even further by other add-ons is a huge win and possible increased revenue opportunity.
Emails & Actions: This feature can heavily be extended by other add-ons. Text Message Notifications and Slack already use it and almost all our add-ons are getting ready to be ported over. Conditional Logic integrates with it so all of the emails and actions can be fired conditionally which is very nice. Not only can these add-ons extend the feature, but by handling all these actions within the system means that users and developers alike can create some pretty awesome workflows.
Webhooks: I don’t think there is much to extend here. I may find I’m wrong but the other add-ons that can integrate with this feature are minimal. Other add-ons will be able to work with it seamlessly but extending or leveraging the feature further is unlikely.
Do our competitors have it?
From a customer’s perspective, the deciding factor as to whether they use you or the other product could be as simple as a single feature. That doesn’t mean you drop everything to build it, but it is a factor.
If the competitor charges for it, placing it in your free core plugin could be a huge win providing the reason they charge for it isn’t because it’s a huge support drain. Charging for it but doing it differently or better than the competition is also a very viable option.
If they don’t have it at all then you have a huge opportunity to release something brand new to the world. You have to weigh the cost though. When something doesn’t exist it’s harder to get people to see why they need it.
Emails & Actions: Yes and no. Obviously, all form plugins have some sort of system for sending emails. I’m confident that none have a system quite as robust or as easy to extend as Ninja Forms at this time.
Webhooks: Not that I’m aware of. Most of the top form plugins have hooks and filters that would allow you to custom code such POST and GET requests, but I’m not aware of any that have a simple to use UI to accomplish this.
Making the Decision
Emails & Actions
People weren’t breaking down our door for this feature, but that’s because they didn’t know any better. Over time we probably could have built a solid following and revenue around this as an add-on. It would not have made up for the amazing bragging rights we get for having it as a part of the core free plugin. On top of that we are able to increase the value of other add-on because this feature is in core. Think Conditional Logic, Text Message Notifications, and Slack. Even better, it opened the door for other add-ons that might not have been created without it like the one we’ve been discussing, Webhooks.
This feature promised to lower support for the free plugin, raise the perceived value of the free plugin and add-ons, and provide opportunity to create other revenue generating add-ons. Putting it in the free plugin was the right choice.
We received a relatively decent amount of requests for this feature. It’s not going to make us a fortune, but those who need it will pay for it and it definitely solves an expressed need of our users. We see this has being a possibly heavy support burden although we have some plans to deal with that. While most users may never need this feature, simply the fact that it exists along with the dozens of other add-ons makes Ninja Forms a solid option for all a users future needs.
Applying it to Your Business
Your mileage may vary. There are so many factors that have to be considered and sometimes it just comes down to your gut. In the end it boils down to some of these thoughts.
- If you want to have the best core plugin available sometimes you place revenue generating features into your core plugin.
- If you want to have the best add-ons available you have to place features that those add-ons can extend in your core plugin.
- If you want to make money you sometimes have to sell add-ons that people think should be a part of the core plugin.
- If you want to make money you sometimes have to sell add-ons that only a few people will ever need. This raises the perceived value of your entire product line.
- If you want to be successful you don’t have to get it right every time. It’s better that you get it right more often than you get it wrong.
- The longer you stick it out the more likely you will get it right. Experience pays dividends.
What would you add to the deciding factor of what should and shouldn’t be an add-on?