Flat 30% off for Singapore 🇸🇬
Book a 30-min call →
14 days · $1,999 · fixed

Ship It Live · extension sprint

Your Chrome extension, built and on the Web Store in 14 days.

A real extension in real browsers — Manifest V3, submitted properly, and yours entirely. Two weeks, one fixed number.

Enter to send
4.93★ / 32 reviews 75+ shipped Kickoff in 24h

Quick answer

A Chrome extension can be designed, built and submitted to the Chrome Web Store in 14 days for a fixed $1,999. That covers Manifest V3, the popup and any in-page interface, storage and sync, an options page, and the store listing. Google's review typically adds a few days on top.

The plan

Day one to day 14, written down.

You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.

The scheduleDay 1 → day 14
01Scope lockDays 1–2
02DesignDays 3–6
03BuildDays 7–11
04Test across sitesDays 12–13
05SubmitDay 14
  1. 1

    Days 1–2

    Scope lock

    What the extension does, which pages it touches, and the minimum permissions that allows. Permissions decide both review outcome and install rate, so they get decided first.

  2. 2

    Days 3–6

    Design

    The popup and any injected interface. Extensions are used in seconds inside someone else's page, so restraint matters more here than in any other build.

  3. 3

    Days 7–11

    Build

    Manifest V3, background service worker, content scripts, storage and auth. You get an unpacked build to load locally early, so you are testing in your real browser during the build.

  4. 4

    Days 12–13

    Test across sites

    Behaviour across the pages it targets, plus updates, uninstall and the permission prompt flow. Extensions break on other people's markup, which is where this time goes.

  5. 5

    Day 14

    Submit

    Store listing finished, privacy disclosures completed accurately, and the build submitted. I handle review questions if Google comes back with any.

What $1,999 gets you

Everything needed to launch — nothing padding the invoice.

Manifest V3 build — the current standard, not a V2 port that will break
Popup interface, and content scripts where the job needs the page itself
Options and settings page, with synced storage across the user's devices
Authentication against your existing product, if it has one
Permissions kept to the minimum, because over-asking fails review and scares users
Chrome Web Store listing: copy, screenshots, icon, privacy disclosures
Submission handled end to end, including responses to review questions
Source code, design files and 30 days of support at handover

Who books this

Built for

SaaS products whose users keep asking for a browser companion

Teams whose workflow needs something that lives on top of another site

Founders testing an idea where the browser is the natural surface

Real situations

Five ways this shows up, and what actually fixes it.

Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.

Situation 1

Users keep asking for a browser companion to the product

A SaaS product's users repeatedly request something that works alongside another site they use daily, but building a browser extension feels like an unfamiliar, separate skill set.

A Manifest V3 extension ships in 14 days, authenticated against the existing product, with minimum permissions kept deliberately narrow.

Situation 2

A workflow that only makes sense sitting on top of another site

A team's process depends on data or actions from a website they don't control, and the natural place to add value is directly inside that page, not in a separate app.

Content scripts inject the interface directly into the target page, tested across the real pages it needs to touch, not just a demo site.

Situation 3

Over-permissioned extensions that scare users and fail review

A previous extension attempt requested broad permissions 'just in case,' which both worried installers and drew extra scrutiny from the Chrome Web Store review process.

Permissions are scoped to the minimum the extension actually needs, decided before design — because over-asking hurts both install rate and review outcome.

Situation 4

An old Manifest V2 extension that suddenly stopped working

An existing extension built years ago on the now-deprecated Manifest V2 standard broke when Chrome stopped supporting it, with no clear migration path in-house.

Migrating to Manifest V3 — now required — is a common version of this sprint, bringing the extension back onto the current standard.

Situation 5

Testing an idea where the browser is the natural surface

A founder has a product idea that fundamentally lives in how people already browse the web, but has no working prototype to validate it with real users.

A focused extension doing one job ships in two weeks for a fixed $1,999 — enough to validate the idea before investing further.

The honest part

When 14 days is the wrong answer.

A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.

Anything that scrapes a site actively defending against it. Technically a cat-and-mouse game, commercially a maintenance bill, and often against that site's terms.

Enterprise policy deployment and managed-browser distribution, which is an IT programme rather than a build.

Cross-browser parity across Chrome, Firefox and Safari in one sprint. Chrome and Edge share a codebase; Safari genuinely does not.

Scope$1,999 · 14 days

Inside the 14 days

  • Manifest V3 build — the current standard, not a V2 port that will break
  • Popup interface, and content scripts where the job needs the page itself
  • Options and settings page, with synced storage across the user's devices
  • Authentication against your existing product, if it has one
  • Permissions kept to the minimum, because over-asking fails review and scares users
  • Chrome Web Store listing: copy, screenshots, icon, privacy disclosures
  • Submission handled end to end, including responses to review questions
  • Source code, design files and 30 days of support at handover

Quoted as one number before day one. A week running long is mine to absorb.

Outside the line

  • Anything that scrapes a site actively defending against it. Technically a cat-and-mouse game, commercially a maintenance bill, and often against that site's terms.
  • Enterprise policy deployment and managed-browser distribution, which is an IT programme rather than a build.
  • Cross-browser parity across Chrome, Firefox and Safari in one sprint. Chrome and Edge share a codebase; Safari genuinely does not.

Real work, sized and priced separately. You hear it before you book, not at handover.

Questions

Before you book

Yes, for a focused extension doing one job. The two weeks cover design, build, testing and submission. What extends it is targeting many different sites, each of which changes its markup on its own schedule.

14 days from now, this could be live.

A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.