A guide to hiring a Chrome extension developer
A Chrome extension is a small program that adds features to the Chrome browser. It can add a button next to the address bar, change how a web page looks, save notes from a page, fill in forms or connect a site you use to another tool. Extensions are built with the same languages as websites, which are HTML, CSS and JavaScript, often with TypeScript on top. The browser adds its own rules and tools, and that is where an experienced extension developer earns their fee. This guide covers what the role involves, how to judge a candidate you meet on video and how to set up the first weeks.
What a Chrome extension developer actually does
The job starts with a plain question: what should the extension do, and on which pages? From there the developer plans the parts, writes the code, tests it in the browser and gets it through the Chrome Web Store, the place where Chrome users install extensions. After launch they handle updates, bug reports and changes in the browser itself. A good developer also tells you early when an idea will not fit the rules, so you do not pay for something that the store will reject.
The parts of an extension
Every extension has a manifest file. It is the list that tells Chrome the name, the version, which files to load and which permissions the extension asks for. Around it sit a few kinds of code. A background service worker reacts to events, such as a click on the toolbar button or a message from another part. Content scripts run inside the pages you choose and can read or change them. A popup is the small window that opens from the toolbar button, and an options page holds settings. A developer who can explain how these parts talk to each other is usually one who has built a real extension.
Manifest V3 in plain words
Manifest V3 is the current format that Chrome asks extensions to use. It replaced the older Manifest V2. The biggest change for developers is that the old always-on background page was replaced by a service worker that starts when needed and stops when idle. That means state cannot simply sit in memory, and long tasks must be planned. Rules for loading remote code are also stricter. If your extension is old, moving it to Manifest V3 is a common first job, and the developer should be able to describe what has to change before they start.
Permissions and user privacy
Each permission an extension asks for is shown to the user when they install it. Asking for less is better for trust and for review. A careful developer requests only what the feature needs, explains each permission in plain words on the store page and thinks about what data the extension touches. Google publishes developer program policies for the Chrome Web Store, and they cover topics such as how user data is handled and what must be disclosed. Read them with your developer before you design the feature, not after the build.
The Chrome Web Store review
Before an extension is listed, it goes through a review. Reviews can ask for changes, such as a clearer description, fewer permissions or a privacy policy. Plan for a back and forth in the first release. The developer should prepare the listing text, the icons, the screenshots and a short note on why each permission is needed. Keep the store account in your company name, so the extension stays with your business whoever builds it.
Ports to Firefox and Edge
Edge is built on the same base as Chrome, and most extensions move across with small changes. Firefox uses a similar API, with some differences, so it takes a little more care. If you want more than one browser, say so at the start. Then the developer can keep shared code in one place and keep browser specific parts small. Each store has its own review, listing and rules.
Where extension work fits
Many extensions grow out of an existing product, such as a tool that works on a customer’s web pages or a button that sends a page to your app. Others are products by themselves, such as a note taker, a price tracker, a tool for people who work in a single web app or a small helper for a team. An extension developer is close to a front-end developer, since both work in the browser. Strong JavaScript and TypeScript skills carry over. What sets the extension specialist apart is the knowledge of the extension system, the permissions and the store.
When a Chrome extension developer makes sense
- You want a tool that works on top of other websites, not only on your own site.
- Your users spend their day in the browser and a toolbar button would save them clicks.
- An existing extension needs to move to Manifest V3 or has a list of open bugs.
- You want the same extension in Chrome, Edge and Firefox.
- A store review asked for changes and nobody on your team knows the rules.
If you only need a feature on your own website, a front-end developer or a web developer can usually do it without an extension. A developer who tells you so is saving you money.
Reading an extension developer’s background
Ask for extensions they built that are listed in the store. Open the listing, read how it is described and look at what permissions it asks for. Install it and try it on a few different pages. Ask what was hard, what the store asked them to change and what they would build differently now. Be careful with a background that shows only demos. A listed extension that real people use tells you far more.
Interview questions to try
- How do the background service worker, content scripts and popup pass messages to each other?
- What did you need to change when moving an extension to Manifest V3?
- How do you decide which permissions an extension really needs?
- What would you do if the store rejected a build for a policy reason?
- How would you test an extension that changes the pages of other sites?
Strong answers use real cases and trade-offs. Be careful with anyone who can name the parts but cannot say what goes wrong when the service worker stops in the middle of a task.
Run a small paid exercise
Set the same short job for each finalist. A good example is an extension with a toolbar popup that reads the title of the current page, saves it to the browser’s storage and shows the saved list. Ask for the code in a Git branch, a note on how to load it in Chrome and a list of the permissions used with reasons. Compare the code, the number of permissions, the way they handle errors and the questions they ask. Pay for their time.
Testing and updates
Extensions run on pages you do not control, and those pages change. Ask your developer how they will test on a set of real sites, how they will spot a break and how fast a fix can reach users. Updates go through the store, so allow time for review before a fix goes out. Keep a changelog, bump the version for every release and decide who watches the store reviews and support email.
Keep the accounts and code in your name
Register the store developer account, the repository and any cloud services to your company. Give the developer a personal login for each. Write down that the code made for you belongs to you. This protects the extension if a developer moves on, and it means you can always publish a fix.
Mistakes that slow an extension project
- Asking for broad permissions that the feature does not need.
- Leaving the privacy policy and the store listing until the last day.
- Building on Manifest V2 ideas that no longer fit.
- Keeping the store account in a developer’s personal name.
- Testing on one page and never on the messy sites your users really visit.
Want a wider view first? Read about our front-end developers for the browser side of a product, or see our JavaScript developers and TypeScript developers for the languages an extension is built in.