Tell us about the extension you need
Extcorp offers browser-extension development services. A useful first message explains the user problem, the main action the extension should support, and the current state of the product.
A short description is enough to start. If you do not yet know the technical requirements, say which details still need to be worked out.
Five details to include
Goal
What should the extension help a user do?
What exists
Is this an idea, a specification, a codebase or a released product?
Where it should run
List the browsers and distribution context you need considered.
Also mention:
- The permissions, data flow and integrations involved.
- The intended release context and any date that matters.
Browser coverage and the work to be included are confirmed when the project scope is agreed.
If you are deciding between acquiring a product and commissioning work, compare buying or building a browser extension. Use the comparison to choose which requirements to investigate first.
For a worked example, use the browser extension project brief and copyable template. The template is optional; a short question is enough for a first conversation.
If something already exists
Describe the current behavior, the change you want and any known constraints. If you need repairs, migration, a project handover or maintenance, include that work in the request so its scope can be reviewed separately.
For example, a change request could describe a setting that resets when the panel is closed and reopened. It should keep the saved value. Add the browser name and version, extension version, steps to reproduce, and a screenshot or short recording if useful.
For this example, the acceptance check is to save a different value, close and reopen the panel, and confirm that the same value is still selected.
If the extension must work in more than one browser, list each target. Browser coverage is agreed for the individual project.
Define what must work in each browser
For each target, name the browser, version range to consider and intended distribution route. Then describe the user action that must work. A request to support Chrome, Edge and Firefox needs a review of the APIs and behavior used by the actual product. MDN describes the areas that differ; Microsoft’s porting guide calls for checking used APIs and testing in Edge.
| Requirement | What to specify | Acceptance question |
|---|---|---|
| Feature and background behavior | Required action, relevant API and what must happen when the interface is closed | Does the agreed behavior work in each named browser and version? |
| Permissions and data | Required access, stored information and any change for existing users | Are the allowed and refused-permission paths understandable and testable? |
| External dependencies | Backend, third-party API or native application, with a responsible owner | What happens when the required service or access is unavailable? |
| Installation and updates | Fresh-install behavior, previous package and data that must survive an update | Can both paths be reproduced with the exact package and browser versions recorded? |
For an existing product, identify who may share the source and which build instructions reproduce the current package. Include the manifest, known failures and an owner for external dependencies. Mention Manifest V3 migration or store resubmission when relevant so the required materials, decisions and responsibilities can be reviewed.
Separate technical acceptance from release
Record technical completion, store submission, the store’s decision and availability to users as separate states. A successful local test establishes the behavior checked in that environment. It does not establish a store decision or availability in every intended region.
An illustrative acceptance record could say that a reading-list feature preserves saved entries after restart, while the update from the previous release remains unchecked. The open update check stays visible until it is performed. If the code passes but a store requests clarification, keep the technical result and the store request in separate fields.
Name who will review the checks and who may make the release decision. Packaging, submission assistance and later maintenance are included only when agreed for the project.
If a Chrome review takes longer
Start with the item’s dashboard status and publisher email. Chrome’s review guidance lists permissions, significant code changes, difficult code and submission volume among possible delay factors. It directs developers to support when an item has been pending for more than three weeks. That is an escalation point, not an approval deadline.
Keep the submitted version and date beside the actual dashboard label. For a rejection, read the reason on the item’s Status tab before deciding what to change. With deferred publishing, an approved submission still needs the publisher’s release action.
An update under review does not itself replace the published version. An illustrative record might read “version 1.0 published; version 1.1 pending”. Check the live item separately before reporting what users can currently install.
What is decided for the individual project
The requested browsers, work, responsibilities, acceptance criteria, release involvement, timing and commercial terms are considered separately for each project. Only the details agreed for that project should be treated as included.
Development and user acquisition are different requests
Use this page when you want to discuss the extension product itself. If the extension already exists and the goal is to attract users, see browser-extension install campaigns.
Discuss your extension project
Send the product goal, current state, browser requirements, data and integrations, and release context. Extcorp will review the development request individually.