← Back to articles

Things I wish I knew before making a chrome extension

Browser Extensions are great tools to make if your skillset lies in the frontend world. I've recently made a popular one called Spider Pro and you can read more about the launch story here.

Now that I've made both free and paid extensions, I have mixed feelings about them. Yes, one-click installs are great, but the ecosystem of distributing a paid extension is quite unfriendly for developers. I'm still happy that Spider Pro turned out as I wanted, but I probably will not create another paid browser extension again.

Source code, anyone?

Due to security reasons, you are not allowed to minify or obfuscate the source code, which makes it harder to prevent people from hacking the payment service for your extension. The only thing you could do is to make a good product with excellent customer service and spend less energy on those who want to hack anyway.

The Firefox Webstore's developer tip also indicates this concern. "Do not spend too much time securing your licensing system against hackers, because users who are inclined to use a hacked license are unlikely to pay for one. Your time is better spent developing new extension features that attract more paying users.", they said.

Forked Code

The extension API is different per browser, e.g., Firefox uses browser where Chrome uses chrome." Although it's relatively easy to port one extension into another browser, the source code is forked. Also, it's mistake-prone during the final deployment because every browser's Webstore bundles code differently.

You could work around this by writing a gulpfile that compiles into two targets, then programmatically deploy to both Webstores if you have private keys setup correctly.

Brew your payment and license service

Chrome Web Store Payment does support a trial/freemium model, but Firefox doesn't - it doesn't even have a payment mechanism and is unlikely to provide one in the future.

I didn't like the idea of splitting revenue streams for a single product, so I opted to build a custom license/payment service. Generating license keys and hooking them up to an email service didn't sound fun to me, so I dreaded to get that part working. If you're like me, this could be a deal-breaker.

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.


If you are thinking of making an extension product, I'd recommend making the extension free but leave the core functionality in your monetized service. The extension then acts as a gateway to gather essential data for your service. It's easier to put a paywall in front of your service than the extension.

As silly as it sounds, most popular extension products already work this way. Spider Pro doesn't because I was reluctant to develop a web app component as it'd defy my original goal. However, if you are still in the middle of development, I hope this article could help you avoid the mistakes I've made.