From 0 to $4000+/month with a new WordPress plugin

Lessons learned from launching Paid Member Subscriptions, our free membership plugin

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.

We launched with 5 paid add-ons: Discount Codes, Multiple Subscriptions per User, Navigation Menu Filtering, Recurring Payments for PayPal Standard and Global Content Restriction.

Which one do you think was the bestseller?

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.

In the last 30 days Paid Member Subscriptions brought in 4546$.

Switching from a paid add-ons model to a paid versioning one, increased our monthly revenue by 30%.

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)
• Releasing more add-ons, both free and paid. Things like Reports, Invoicing, bbPress integration, etc. We’re constantly gathering user requests and building our development timetable accordingly.
• Publishing more case studies, how to’s, basically trying to help and reach more membership site owners.
• Communicating better and more often with our existing users (giving them the ability to suggest new features, offering tips on how to use the product, collecting feedback etc.)
• Setting up yearly renewals

What we’ve learned so far

It’s been a long post, so thank you for making it so far. Here’s a breakdown of things that launching Paid Member Subscriptions taught us:

1. Write things with the purpose of helping people, in the end you’ll hit a pretty sensitive pain point that people will ask you to fix
2. Build something people ask for, repeatedly
3. Don’t try to solve everything with your product, focus on one thing and do it well
4. Consider using OOP when developing a new plugin
5. Get the pricing right in order to built a sustainable product, don’t be afraid to experiment and see what works for you
6. Building related plugins allows you to cross promote them and give new ones a head start
7. Help people that use your product, whether they’re paying you or not. You’ll end up with an improved product, plus it builds good product karma

One last thing. This is sort of the first time we’re writing a post like this, that highlights some of the insides of our business.

If you’ve enjoyed it, felt like you learned something from it and want more of it in the close future, just let us know in the comments section below. We will happily oblige.