Premium vs. Add-ons — Which is the Best Model for Your WordPress Plugin?

Why are add-ons an excellent model?

Technical Side

  1. Modularity — When you create extensions for your plugin, it forces you to build a modular and a more abstract core plugin — which is way better for code maintenance.
  2. Easy feature maintenance — When you use this model, it’s easier to test, debug, and deploy changes to specific add-on related features. You simply have to push an update to an add-on without the need to release a new plugin version.
  3. No dual code base — You don’t have to maintain two separate code bases for your core plugin, and instead you can focus on your add-ons.
  1. Better, Positioning Marketing and SEO — Since you sell an add-on, you can market each add-on separately. You can also emphasize every feature to attract attention from users who are looking for that exact functionality. In addition, having an informative page per add-on is great for SEO because people often search for a specific functionality — making these pages a great lead generation channel.
  1. Partners Traffic — Add-ons are great for generating traffic from partners. If your add-on provides a valuable integration of a 3rd party solution with your plugin, it makes a lot of sense for the other solution to promote or feature your add-on, to show their customers that they are covered if they will use your plugin. MailChimp is a great example of a company that took it even one step further and now promote their partners through a repository of integrations.

Why are add-ons worse than a premium version?

Technical Side

  1. Harder to change core functionality — Following the previous bullet, making changes in the core plugin becomes way more complicated — you’ll have to be very careful that the change won’t affect compatibility with your add-ons (very similar to the challenges of modifying WP core).
  2. Compatibility and versions fragmentation — We all know how challenging it is to keep your users regularly updating your plugin when new versions release (excluding “Serviceware” / SaaS plugins). Now when you have add-ons, think of the version fragmentation mess you’ll get. It can be extremely difficult to maintain compatibility across all add-ons and the core plugin.
  3. Performance degradation — When you develop your plugin for add-ons, you’ll have to make it very flexible with a lot of hooks & filters ready for your add-ons to connect with. Unfortunately, each time do_action executes; it consumes system resources. Having many actions has an effect on the performance (even if slightly).
  1. Pareto Principle, also known as the 80–20 Rule — Both James and Daniel confirmed that 70%-80% of their total revenues are streamed from ~20% of the add-ons. This means that you are stuck with add-on maintenance that only has a few users (some even none). The challenge here is you’ll have to maintain the rest of the 80% of your add-ons, and provide support.
  2. Time Consuming Marketing — with add-ons, you are forced to detail about each and every add-on (otherwise no-one will buy it). While with premium plans you can focus on highlighting your killer features.
  3. More Complex Operation — as a rule of thumb, it’s way easier to focus on and sell one product rather than 100. When you have 100 add-ons, there are 100 times more things that can go wrong.
  4. Tougher Purchase Decision — having many add-ons with your plugin can be very confusing for end users. There are over 200 add-ons on WooCommerce, which one to use if I start my store? Many users do NOT know what they want or need. Therefore, selling premium with plans can help and guide your users to the most compelling package, which makes the upgrade decision easier. Plans like “Starter”, “Professional”, “Business”, “Agency”, automatically categorize your potential customers into buckets, which psychologically hint them of what they should upgrade to.

When should you monetize with add-ons?

While add-ons model is definitely way more complex on the technical side, it provides many valuable business side benefits. Thus, if you see your plugin as a platform, and it’s abstract enough to facilitate various use-cases and integrations. If your plugin can have a LOT of features and extensions — more than you can ever develop and maintain yourself — definitely go for add-ons!

Always develop “addons-like” plugins!

Our plugin, RatingWidget, started as a relatively small. The original plugin was mainly a simple wrapper to our SaaS 5-star rating product with about 1,000 lines of code. But after four years, it turned into a massive project with over 10,000 lines of code. I could never have imagined that this would happen. After all, RatingWidget is just a 5-star rating system that seemed to be pretty straightforward and a relatively simple solution. Looking back, I should have spent more time in designing the plugin by making the code more modular and scalable with more of an add-on like development process.


Interviewing James and Daniel taught me a lot about add-ons, but I think what inspired me the most is the fact that they both tried two other different monetization models before finding out that add-ons worked best for their plugins. My take away is that WordPress plugin developers should not be afraid to a/b test their plugins monetization models.

James Farmer, Founder and CEO at Incsub - Experts Corner by Freemius

James Farmer

Founder & CEO at Incsub



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store