Things I wish I knew before making a paid extension (2019)

These are great points. I'd like to add some more to them:

On minified source code, Extensions/Add-Ons are allowed to be deployed with minified source code as long as you provide the unminified versions to Google/Mozilla during review time.

On chrome vs. browser namespaces, a quick 'let chrome = browser;' can help you keep the diffs small between versions. I have yet to find a complete solution to fixing 'forked code' between Google/Mozilla Extensions/Add-Ons.

Also, storage mechanisms between browsers using the same extension code can be completely different. Beware if you're using caches, navigator.storage, and storage.local.

Finally, extensions don't consider themselves secure, depending on the browser. moz-extension:// is not considered secure for cache access, whereas chrome-extension:// is.

There lots of little 'gotchas' like these when developing browser extensions. :)

YC W19 Sapling here. We have a freemium browser extension that acts as a grammar checker. Couple thoughts below:

1. Source code. You are allowed to minify source code. Chrome actually recommends minifying source to improve performance. If you require certain permissions you'll have to submit un-minified source for security review.

2. Cloud/subscription based models are the way to go if piracy is an issue, but it doesn't make sense for all products. Licensing hasn't been an issue for Sapling fortunately because the "brains" of our app are in the cloud. I know hacker news is very privacy conscious but our language models are too large to run on a user's end machine right now. Spier Pro seems like a useful web-scraping helper. People who can pirate a chrome extension probably can probably run xpath scripts or a free xpath testing extension themselves so if I were Amy I wouldn't worry _too_ much about piracy.

3. Forked Code. There should be no reason to do it. Firefox and Edge have done a lot of work to support most of the chrome apis. You can handle minor edge cases build time with a variable toggle. Keep the same manifest, even. Browsers are good about ignoring keywords in the manifest they don't recognize. My recommendation is to pretend they are the same platform until you find bugs/issues and hard code around them. Theres a handful but it's very manageable.

[0] https://blog.chromium.org/2018/10/trustworthy-chrome-extensi...

[1] https://stackoverflow.com/questions/37649620/does-chrome-mar...

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Browser vs chrome point is moot. Both namespaces exists in Firefox and there’s a polyfill to bring the browser namespace into chrome if you want to use promises over function callbacks. https://github.com/mozilla/webextension-polyfill

For those curious, Gumroad does offer support for generating license keys which they state "are primarily used for creators selling software."[0] From my own experience implementing this and having used other extensions that also relied on this system, I think it works well for bringing monetization to browser addons/extensions.

EDIT: just wanted to add that you don't need to distribute your extension through Gumroad (though you can). You just make it so that anything behind a paywall requires adding the license key which is generated by Gumroad upon purchase and later verified via their licenses API.

[0]: https://help.gumroad.com/article/76-license-keys

> Lots of people are interested in using Gumroad for their extension, and here are my two cents: Gumroad is designed to work best for digital goods such as ebooks, photoshop brushes, and software that can be downloaded and owned. However, I'd not recommend it for selling browser extensions because of: 1. It doesn't make sense to download extensions and manually install them. (The first version of Spider Pro worked that way, and lots of customers find it confusing). 2. There's no easy way to distribute post-installation updates.

> However, I'd not recommend it for selling browser extensions because of: 1. It doesn't make sense to download extensions and manually install them. (The first version of Spider Pro worked that way, and lots of customers find it confusing). 2. There's no easy way to distribute post-installation updates.

What's wrong with putting your extension on e.g. the Chrome and/or Firefox web store where purchasing via your own site gives a login that unlocks paid features within your extension? That gets around 1 and 2, plus you gain organic traffic from being in the stores.

This is what I do for https://www.checkbot.io/, which is on the Chrome Web Store but I use Paddle for payments. This also means purchases aren't tied to the Chrome Web Store.

I went with Paddle over Gumroad as Gumroad seemed less flexible for team based subscriptions. Is anyone doing something like the above with Gumroad? How did it work out?

Also, I haven't used Chrome Web Store payments but I would steer well clear of integrating it. They've been disabling payment functional for various reasons the last few months as if it's not business critical to people: see https://www.theregister.co.uk/2020/01/27/google_disables_web... and more recently https://groups.google.com/a/chromium.org/forum/#!topic/chrom.... I wouldn't be surprised if they cancelled Chrome store payments soon.