I'm working on an extension myself so this was a great read!
Did you consider making it a free extension (with enough features to be usable) with in-app payments to unlock more features? You would think that would keep your downloads up and give more people a chance to try it out.
Also, why did you go with a subscription and not a one-off payment? Did you get any user feedback on if this discouraged a purchase?
I did look at in-app payments, but because of how the extension is made to be used (click the button, it starts reloading when required) I couldn't figure out a decent way to ask users to upgrade without being annoying.
I went for subscription because I wanted a low price point (It's a simple extension, anything more then $5 seemed like I'd be asking to much), with the potential of having a passive income. I'd love to experiment with how one-off/monthly changes the amount of sales but for now I'm happy asking people to pay yearly.
It's still under wraps but I'd be happy to compare experiences when I launch.
I did look at in-app payments, but because of how the extension is made to be used (click the button, it starts reloading when required) I couldn't figure out a decent way to ask users to upgrade without being annoying.
Hmm, maybe by default when you click the button make it show the config pop-up you have already with an added upgrade banner. You could add an option to not show the config pop-up on click as well.
I have no figures to back this up but unless you're a well known brand I think not having a completely free version to try will turn away a lot of potential sales. You say in your post you had a noticeable drop in the web store charts after making it a paid app.
I went for subscription because I wanted a low price point (It's a simple extension, anything more then $5 seemed like I'd be asking to much), with the potential of having a passive income. I'd love to experiment with how one-off/monthly changes the amount of sales but for now I'm happy asking people to pay yearly.
I'd avoid equating code complexity with how much you charge. Charge by how much value your extension brings to customers. If it's saving a freelancer X number of hours per month then that's worth something more than the number of lines of code it took to write. Live reload is a big productivity boost.
By the way, did you look into experimenting with price changes? Since I last looked, you can easily change the in-app purchase price but you can't with subscriptions. I think the only option for the latter is to create new subscription IDs for each price.
Regarding the subscription: this would be a huge turn off for me. I guess I disagree with the price model, so I'd only get into a recurring cost for something I deemed essential, whereas I'd be much more likely to pay a (similarly?) small sum as a once off. This isn't criticism, just opening the possibility that sales might be a lot higher as a once off, and if you end up rewriting/adding a tonne of features you could always release V2. I'd be curious how many years an average paying user would actually end up using/paying for with a tool like this.
Obviously this is purely anecdotal, and this extension isn't applicable to me personally anyway.
I'd 100% push people towards offering an extension for free to build up a good amount of reviews & user base, then switching to any paid model (One off, Monthly Subscription or Annual Subscription). If people are happy to pay for something that was free, it's a good indictor that you've built something decent.
I went for Annual Subscription because I felt it offered a fair price point ( < $5 a year per a user ) and it created an incentive for me to keep maintaining the extension. I'd recommend playing around and seeing what works best for your extension.
Do you see any practical risk with someone offering a copied version of the extension
They're are already a bunch of extensions doing something similar for free. I like to think people have used my extension because I'm never more then an email away if they have any questions. Also as it's paid, I have no incentive to sell it to a 3rd party who might start injecting ads into webpages or something.
FWIW, as a developer if I'm willing to break out my credit card to pay $5/year for a tool, I am every bit as willing to pay $20. I would wager you'd get far more than just a 1/4 of your users if you jumped up that price.
I agree that if someone has to get out their credit card, they're likely willing to pay more than $5/yr.
The key question here is what percent of the potential purchasers already have a Chrome wallet (or whatever it's called now) and just have to click "buy".
Impulse purchases by these users would be more likely to drop off with a price increase.
On the flip side, the little things do add up. Consider as an example, the cost of a $70 per month cable subscription, versus 5 streaming subscriptions at $15 per month. The developer might not see this, but the accountant should.
I had one user message me complaining his all of clients websites would lag when he used the extension (It checks for changes to files by crudely polling them every 200ms or so). Turned out the guy was building sites via an FTP editor in a production with all his clients on one server, with a lot of CSS/JS files being included in each page.
After a few emails back and forth, I switched him to WAMP for local development.
Hot damn, that's taking "move fast and break things" to a whole new level. Still, good on you for taking the time to suggest a better way to do things.
Thanks for writing this up! Chrome Extensions have been my go-to playground for many years but, though I looked into it, I never went through with making one a paying one.
A couple of questions:
Were the existing free users grandfathered in? It seems like it from the weekly users.
Can you have two pricing models for the same extension? Like pay for a lifetime license for $x or $y/year.
If you've played around with extensions, you should definitely consider making a paid one. The APIs you need to verify payment are pretty interesting.
Were the existing free users grandfathered in? It seems like it from the weekly users.
All user who had the extension installed when I made the switch were able to keep it for free. This was a little tricky for users who had installed, then uninstalled it. For those ones I just told them to email me for the developer version.
Can you have two pricing models for the same extension?
You can't easily, but I did consider putting a lifetime version in the store as a separate extension.
Comments
I wrote the extension and this blog post, so I'm happy to answer any follow up questions you might have :)
I'm working on an extension myself so this was a great read!
Did you consider making it a free extension (with enough features to be usable) with in-app payments to unlock more features? You would think that would keep your downloads up and give more people a chance to try it out.
Also, why did you go with a subscription and not a one-off payment? Did you get any user feedback on if this discouraged a purchase?
Awesome! What is your extension?
I did look at in-app payments, but because of how the extension is made to be used (click the button, it starts reloading when required) I couldn't figure out a decent way to ask users to upgrade without being annoying.
I went for subscription because I wanted a low price point (It's a simple extension, anything more then $5 seemed like I'd be asking to much), with the potential of having a passive income. I'd love to experiment with how one-off/monthly changes the amount of sales but for now I'm happy asking people to pay yearly.
It's still under wraps but I'd be happy to compare experiences when I launch.
Hmm, maybe by default when you click the button make it show the config pop-up you have already with an added upgrade banner. You could add an option to not show the config pop-up on click as well.
I have no figures to back this up but unless you're a well known brand I think not having a completely free version to try will turn away a lot of potential sales. You say in your post you had a noticeable drop in the web store charts after making it a paid app.
I'd avoid equating code complexity with how much you charge. Charge by how much value your extension brings to customers. If it's saving a freelancer X number of hours per month then that's worth something more than the number of lines of code it took to write. Live reload is a big productivity boost.
By the way, did you look into experimenting with price changes? Since I last looked, you can easily change the in-app purchase price but you can't with subscriptions. I think the only option for the latter is to create new subscription IDs for each price.
Regarding the subscription: this would be a huge turn off for me. I guess I disagree with the price model, so I'd only get into a recurring cost for something I deemed essential, whereas I'd be much more likely to pay a (similarly?) small sum as a once off. This isn't criticism, just opening the possibility that sales might be a lot higher as a once off, and if you end up rewriting/adding a tonne of features you could always release V2. I'd be curious how many years an average paying user would actually end up using/paying for with a tool like this.
Obviously this is purely anecdotal, and this extension isn't applicable to me personally anyway.
Thanks for writing the post. It gives a good picture for someone who wants to venture in extension development.
Would you suggest to first make an extension available for free (in order to get a nice install-base) and then offer as an Annual Subscription?
Do you see any practical risk with someone offering a copied version of the extension (with different name) at a slightly lower cost?
I'd 100% push people towards offering an extension for free to build up a good amount of reviews & user base, then switching to any paid model (One off, Monthly Subscription or Annual Subscription). If people are happy to pay for something that was free, it's a good indictor that you've built something decent. I went for Annual Subscription because I felt it offered a fair price point ( < $5 a year per a user ) and it created an incentive for me to keep maintaining the extension. I'd recommend playing around and seeing what works best for your extension.
They're are already a bunch of extensions doing something similar for free. I like to think people have used my extension because I'm never more then an email away if they have any questions. Also as it's paid, I have no incentive to sell it to a 3rd party who might start injecting ads into webpages or something.
I find deliberate bait and switch distasteful. It will eventually breed an atmosphere of suspicion tainting the whole system.
(Nothing against an honest "Free for now, will see next year" right upfront)
FWIW, as a developer if I'm willing to break out my credit card to pay $5/year for a tool, I am every bit as willing to pay $20. I would wager you'd get far more than just a 1/4 of your users if you jumped up that price.
That's interesting to hear. I'm thinking about experimenting with different prices next month, I'll make sure to do another write up :)
I agree that if someone has to get out their credit card, they're likely willing to pay more than $5/yr.
The key question here is what percent of the potential purchasers already have a Chrome wallet (or whatever it's called now) and just have to click "buy".
Impulse purchases by these users would be more likely to drop off with a price increase.
On the flip side, the little things do add up. Consider as an example, the cost of a $70 per month cable subscription, versus 5 streaming subscriptions at $15 per month. The developer might not see this, but the accountant should.
Care to share some batshit crazy development environments?
I had one user message me complaining his all of clients websites would lag when he used the extension (It checks for changes to files by crudely polling them every 200ms or so). Turned out the guy was building sites via an FTP editor in a production with all his clients on one server, with a lot of CSS/JS files being included in each page.
After a few emails back and forth, I switched him to WAMP for local development.
Hot damn, that's taking "move fast and break things" to a whole new level. Still, good on you for taking the time to suggest a better way to do things.
Thanks for writing this up! Chrome Extensions have been my go-to playground for many years but, though I looked into it, I never went through with making one a paying one.
A couple of questions:
Were the existing free users grandfathered in? It seems like it from the weekly users.
Can you have two pricing models for the same extension? Like pay for a lifetime license for $x or $y/year.
Congratulations!
If you've played around with extensions, you should definitely consider making a paid one. The APIs you need to verify payment are pretty interesting.
All user who had the extension installed when I made the switch were able to keep it for free. This was a little tricky for users who had installed, then uninstalled it. For those ones I just told them to email me for the developer version.
You can't easily, but I did consider putting a lifetime version in the store as a separate extension.
Does limited functionality work instead of free trial?
i.e here are 2 out of 5 features. Upgrade to PRO to get the other 3.
The 2 features providing basic functionality.
I realize this is difficult in your situation since it is more a 1 feature extension but I'd be curious if that strategy works.
Thanks
Thanks, good writeup!