Over the course of 10 months Paid Member Subscriptions grew from 0 to $4000+ in monthly revenue, from a minimum viable product (MVP) to a fully fledged membership plugin that can compete with the already existing options. All while working 4 days/week.

This article goes behind the scenes of building and launching a new WordPress plugin. Keep in mind that this is just our path, by far a recipe.

It’s purpose is to highlight the ups and downs faced along the way, challenges and decisions we had to take, initial assumptions (some of which turned out to be completely wrong) and perhaps be of use to some of you dealing with WordPress plugins on a daily basis.

A little bit of background

Our WordPress product journey started in 2011. We had been doing consulting work for a couple of years, while also blogging over at Cozmoslabs about various WordPress development topics.

It all began with a blog post. After noticing the limitations of trying to extend the default user registration in the front-end while also adding custom user profile fields, my colleague Cristian decided to write a detailed tutorial on the subject. It got a lot of feedback from our readers and was for a few years in a row, our most popular blog post.

A couple of months later, the tutorial turned into a plugin, and this is how Profile Builder, our front-end user registration and profile plugin was born.

Build something that people ask for, repeatedly

Now, the reason I’m telling you this is that Profile Builder is closely related to the birth of Paid Member Subscriptions, our latest WordPress membership plugin.

In the process of improving Profile Builder over the years, one of the most requested features was to add support for paid profiles.

For more than a year we stalled and refused to push payments into it since it detracted from the core plugin, which was a user registration and profile plugin. Profile Builder’s focus and ease of use was its forte, and we weren’t going to give it away by just throwing in features without a long term perspective.

Looking back, while not adding payments support in Profile Buider’s core was a good move, stalling and not building what our users constantly demanded wasn’t.
So, we decided to not ignore the obvious anymore and find a way to add paid user profiles.

We ended up facing one of the most important development decisions to date:

Should we build a Payments add-on for Profile Builder, or should we go for a new standalone membership plugin altogether, making it 100% compatible with Profile Builder?

Even though the first one was easier and faster, we went for the second one. Here’s why:

In addition to payments, Profile Builder users were constantly asking for content restriction support as well as the ability to create user roles and subscription plans, all of which should be part of a membership plugin

With a standalone membership plugin you can reach more users and go beyond Profile Builder user base.

Because the two are 100% compatible, you can simply use them together when more complex functionality is required.

This way we can keep both plugins laser focused and constantly improve them by adding only features related to the main purpose of each plugin.

As you noticed by now, we’re not big fans of all in one solutions. They end up sacrificing user experience.

Paid Member Subscriptions was born

The first commit was made in 7th of May, 2015. We launched Paid Member Subscription on 4th of November 2015 , completely free on wordpress.org, almost 6 months later.

While developing Paid Member Subscriptions, we didn’t try to implement every single feature a WordPress membership plugin might need.

Instead we focused on making it a joy to setup and use, requiring the minimum amount of steps to get your membership site up and going.
Research showed that the majority of people need an easy way to restrict content, allow their users to sign up for subscription plans and get paid.

We made all of this functionality available from the start in the free version of Paid Member Subscriptions.

Going OOP, all the way

Development wise, we went for an object oriented approach when writing the actual plugin code. If you’re planning on writing a new plugin or maybe consider refactoring an existing one, I strongly advise using OOP.

By using Object Oriented Programming you can organize your code in a way that makes it stronger and easier to understand.

This means other people can easily modify and extend your plugin, like coding a new custom payment gateway they need.
It increases code reuse and makes sure changes to different components are isolated (you’ll know exactly where to look to fix, change or expand something).

Writing code this way is altogether easier to maintain and more extensible.

Which pricing model should you choose?

This is the question that everyone looking to build a sustainable WordPress product will need to ask sooner or later. The revenue that your product will generate (be it a premium plugin or theme) will go towards supporting and developing it further. Both users and yourself will benefit on the long term from picking the right pricing model.

In our case, we were already familiar with the freemium model, as it has been successful for us with both Profile Builder and WordPress Creation Kit. The main advantage with having a free version of your plugin is that people can use it, give you feedback on improving it and some of them may even want to upgrade.

The key to a successful fremium model is to correctly balance the value that goes into each version of the product.

The free version should offer enough functionality for most users. This is what will make people download and use it.
The less value you offer in the free version, the fewer people will download and use it, the smaller the probability that some of them will purchase something from you. You get the idea.

Pushing this too far, the value from the paid versions will decrease and users will have no need to pay for anything else. This will hurt both you and your users in the long run, as there are multiple examples of great plugins in the wp.org repository that were eventually abandoned by the developer due to lack of revenue, exactly because of an unsustainable or nonexistent pricing model.

The question remained though: how to package the paid version of the plugin?

Should we offer paid add-ons plus a bundle (like WooCommerce or Easy Digital Downloads are doing) or simply go with a Pro/Hobbyist paid versioning like we’ve done before?
Since two of our plugins already had premium versions, with Paid Member Subscriptions we decided to experiment something different, so we went for the paid add-ons model.

This means that you have a free core plugin and a couple of paid add-ons. The paid add-ons can be purchased either individually, or altogether via an add-ons bundle (which in some way can be similar to the PRO version). Basically, you allow people to pay exactly for what they need.

Building add-ons for your plugin can be considered from two different perspectives: pricing or business wise, as well as from a development perspective.

Development wise, add-ons are always the best option when adding extra functionality. If something won’t be used by the majority of your users, it should be an add-on.

This allows you to keep the core of the plugin light and focused, and isolate extra functionality into an add-on. From a coding perspective add-ons are really helpful for 3rd party integrations.
For example, all of Paid Member Subcriptions supported payment gateways (except for PayPal Standard available in the core product) are packaged in an add-on, allowing users to activate and use only the ones they need.

Even though we could have shipped an initial version of the plugin maybe 2 months earlier, we decided to polish things and also have some paid add-ons ready before launch.

Here, our initial assumptions were wrong, as we all said that the discount codes add-on will sell the most. And we were wrong. While discount codes generated sales, the bestseller by far was Recurring Payments for PayPal Standard.
It seemed that a significant amount of users needed recurring subscriptions, not just one-time payments. We were wrong, because our estimation was based on gut feeling, not actual data.

Since the launch, we gradually released more add-ons prioritizing them based on the number of requests from our users. They all sold regularly, because they were backed up by user needs. I cannot enforce this too much: if you have repeated requests for a missing functionality, you should probably add it.

Did the paid add-ons model work for us?

Launching with a couple of paid add-ons allowed us to have sales from day one. Some of our existent customers, which also helped us during the beta testing period, showed their support by buying an add-on. We cannot thank them enough.

The first month after launch bought in a little over 900$. For the next 6-7 months it grew slowly (with the specific monthly fluctuations) to around 2.3-3K/month. Development wise, we pushed a lot in making the core more powerful and added a couple of really cool (and by cool I mean requested) features.

Now, to answer the question: did the paid addons model work for us? Yes and no.

While sales were coming in, they were generally small amounts as most people were buying the single site license for add-ons (priced between 29-49$). Then there were yearly renewals, which can be a pretty tough sell and more difficult to setup for each individual add-on.

In the end we decided to move towards a two versions packaging and split the add-ons between the two based on value they bring to our users.

Therefore, approximately 2 months ago, we switched to a PRO/Hobbyist versioning model, and never looked back. We got fewer sales but in higher values, which led to a monthly revenue increase of more than 30%.
Several payment gateways (like Stripe or PayPal Pro) are now only available with the PRO version.

That’s quite something. But we feel Paid Member Subscriptions has a lot more room to grow. Speaking of which…

How do you market a new WordPress plugin?

Marketing wise, we didn’t do as much as we should have. But we did one thing right, which basically helped Paid Member Subscriptions take off in the early months.

That was to promote it inside Profile Builder, to all existing PB users. We basically created a notification inside Profile Builder’s admin interface and added a description page for creating paid user profiles by using Paid Member Subscriptions in conjunction with Profile Builder.

We sent a couple of emails to our existing customer base, which also helped a lot since they were the ones that requested this functionality. Then we published the documentation and worked on several blog posts on the subject.

From there on, due to the beauty of the wp.org plugin repository Paid Member Subscriptions got discovered by more and more people. The free version has reached 40K downloads, with 4000+ active installs.

Reviews started to add up and it seems people were really digging its simplicity and clear code base.

Be happy to answer support requests

Support is probably one of the most challenging task for every plugin developer. But it shouldn’t be. Getting support requests is good. It means people are using your plugin.

Our policy is to help each and every person that reaches out to us. That includes constantly answering all the support requests on the wp.org free version forums as well. Paying customers always get our priority support and assistance, but we’re doing our best to give a hand when anyone needs help related to our plugins.

It’s free support you’ll say, but that’s fine. You should still do it, not simply because it’s good karma, but because having users reporting problems helps you improve your product.

We had several situations when my colleagues helped someone with his project “for free”, only to have the person return and purchase multiple paid plugins from us.

With Paid Member Subscriptions we had quite a few challenging support requests regarding, you guessed it, payments.

The fact is that payment integrations will always be a sensitive matter, because (duuh) if something stops working means people who bought your plugin are losing money with their membership site. Also, they will probably be more frustrated than your average user, which is also understandable.

Be prepared to react fast and always keep an eye on future changes that payment providers plan. Some of them have good developer docs (like Stripe), others…not so good (sorry PayPal).

In the end, we learned quite a lot from dealing with these, let’s say “more sensitive” support requests.

Next steps for Paid Member Subscriptions

Needless to say, we have big plans for Paid Member Subscriptions in the following months.

Our goal is to double its revenue in the next 6 months.

For this, we’ll be working on:

Improving documentation and access to it (for example creating a step by step tutorial for adding a new payment gateway)

Subscribe to get early access

24 thoughts on “From 0 to $4000+/month with a new WordPress plugin”

Thank you for sharing your journey!
I’m working on my first WordPress plugin to submit to the official repo and to sell to clients.

Especially your experiences with pricing models helped me work on my own approach. I’m already implementing OOP and focusing on a clear code base, so it’s a nice confirmation to see you mention those topics as well.

Wow! although am a lifetime license holder of PB and don’t really use it much anymore, appreciate you sharing this journey with such level of transparency! wish you all the luck for PMs & future plugins!

Your products do solve problems, bridge gaps, and they work very well. Very happy for your success earned by hard work and good support! Also really good tutorials, thanks for your all your contributions to the WordPress Community.

Thanks, I love reading posts like this, getting to know a bit about the processes going on behind the scenes of the tools I use in my work. (Who knows, maybe I’ll do something like this myself one day.)

eally interesting post thanks, as we have launched our first paid WordPress plugins this year – Posts Table Pro and WooCommerce Password Protected Categories and are still learning! Your plugin is relatively complex to set up compared to ours, so I’d be interested to know how you minimise the time sieve on support while still pricing a good service. Surely people need so much help with things like payment gateways that the time you spend helping them out can easily eat up your profits – how do you get around this?

Hi Katie,
I highly recommend offering stellar support early as it can help your product take of by turning initial users into ambassadors for your plugin.

I wouldn’t try to minimize anything, but invest in helping people early on (listening to your users) and improving the product.

In terms of pricing, don’t overthink it. Even if you don’t get it right the first time, you can always change it.
When setting the price just think about how much time and/or money your customers will be saving by using your plugin.

Great write-up! Always interesting to learn of how WordPress products evolve from business perspective.
You managed to very clearly emphasize the advantages of going the freemium business model!
In terms of marketing I liked that admin interface notification on 1 plugin to promote the other, but while you’re at it you may want to use email to communicate & market to your many free version users from the WP repo.