PlugThis - Create your own Chrome Extensions by chatting with AI

@andrasczeizel Thanks Andras, this is exactly the part most people underestimate.

Yeah, permissions are handled deliberately. When you describe an extension, PlugThis only grants what the feature actually needs. <all_urls> content scripts only get added if the extension truly injects into pages, and things like tabs, storage, sidePanel are added on demand, not by default. So a "read this one page" tool doesn't quietly end up with broad host access.

On review risk: there's a built-in step that runs over the generated code like a Web Store reviewer would. It flags sensitive permissions (cookies, identity, history, scripting, etc.), tells you when a privacy policy is required, and auto-drafts the host-permission and remote-code justifications for the CWS submission form. The goal is that when you hit "submit," you're not guessing what Google wants.

Would genuinely love to hear which annoying browser workflows you had in mind. Those tiny personal extensions are the sweet spot.

@thenameisarian You nailed the framing. Once codegen is solved, building is the easy half and the Web Store is the second wall. That's the part we spent the most on, because "here's your zip, good luck" is where most tools stop.

Concretely, PlugThis treats distribution as a first-class step:

- It generates the listing from your actual code: long description, the 25 to 132 char short description, and the single-purpose statement Google now requires.

- It auto-drafts the compliance surface that usually triggers rejections: per-permission and host justifications, remote-code justification, and privacy disclosures mapped to Chrome's data categories.

- It packages the zip and writes the metadata into the manifest at publish time.

- Then it connects to your Chrome Web Store account over OAuth (refresh token encrypted at rest) and uploads and publishes directly. It remembers your Store item ID, so after the first listing, updates are basically one-click.

The honest boundary: we can remove the mechanical friction and the "did I fill the disclosures right" guesswork, but we can't make Google approve you. Review, trust, and the one-time developer registration are still theirs. What we kill is the part where the code works but you stall for a week because the listing and disclosures are a maze.

Curious if that matches where you have seen bolt and lovable users get stuck, at the store submission rather than the build.

@akbar_b Both are the right questions, so here's the honest answer with the edges included.

On the build to see-it-working loop: an extension can't live in an iframe like a web app, so we don't fake that. What PlugThis does is render a live preview of your extension's real UI surfaces, popup, side panel, new tab, and options page, right in the browser as it generates, with the chrome APIs mocked so things like opening the options page actually behave. So while you iterate you're clicking a real rendering of the interface, not reading code and picturing it. For the parts a preview genuinely can't reproduce, content scripts firing on real third-party pages and the service worker's live behavior, we make the last mile trivial instead: you get a ready-to-load unpacked build, so "load unpacked and click through real pages" is one drop into chrome://extensions rather than a setup chore. I would rather be upfront that the true runtime still runs in Chrome than pretend a sandbox reproduces service-worker behavior it doesn't.

On least-privilege: scoping happens at generation, so the generator only pulls in host and API permissions when the feature actually needs them, rather than the usual "ask for everything to be safe" manifest. On top of that, PlugThis scans the actual code and detects permissions the manifest declares but nothing ever calls. Instead of writing a justification for a dead permission, which is exactly what gets extensions rejected, it flags it as "no code usage found, consider removing." It's deliberately conservative, so anything it can't attribute with confidence it leaves alone rather than risk telling you to drop something you need. Add the pre-flight checklist and privacy analyzer on top, and the manifest that reaches submission is scoped to what the feature actually uses.

@anthonywrinqsb That setup wall is exactly the thing that killed the idea for so many people. Manifests, service workers, build config, store rules, all before you write a single fun line of your actual idea. We wanted the barrier to be "what do you want it to do," not "spend a weekend configuring tooling first."

You should finally build that extension you kept putting off. If you do, tell me what it is, I'd genuinely love to see the first thing you ship with it.

@levi_mitchell1 

@levi_mitchell1 The manifest isn't hardcoded into some template you download and own forever. Generation, validation, and sanitizing all happen on our side against the current Chrome rules. So when Google changes a manifest requirement, we update that logic in one place and every new extension people generate follows the new rule immediately.
You don't have to track the spec, learn what changed, or patch boilerplate yourself.

Being honest about the edge: an extension you already published stays as it was shipped, so if a change affects it, you would regenerate and re-publish.
But the "keep up with Chrome's moving target" burden sits with us, not you, which is exactly the part that usually makes people abandon extensions.

What made you ask? Have you been bitten by a manifest change breaking something before?

@maxim100000 You bring up a really good point, our current focus is building the best chrome extension builder in the world. Helping our users move from idea to working extension, as soon as possible.

On the marketing front, we do assist with asset creation and deployment of updates to the chrome store.
We also help getting the extension ready for a chrome store listing.

On the distribution front, we havent made any plans yet, if you have any ideas please share.

@artstavenka1 Great question, and it's exactly the trap a naive static pass falls into, so we handle it two ways.

First, scope: only the required permissions array is ever evaluated for removal. optional_permissions are out of scope by design, precisely because they're requested on demand and would never show up in a static call graph. So nothing you ask for on demand can be read as dead or nudged for removal.

Second, runtime acquisition: if the code actually manages permissions at runtime, chrome.permissions.request, contains, add, or remove, the analyzer picks that up and treats any permission named inside those calls as live, even if there's no direct chrome. call for it. So a permission you declare as required but only activate through chrome.permissions.request won't be flagged either.

And the whole thing is deliberately biased toward silence. A false "this is used" is harmless, a false "drop this" could break your extension, so anything it can't attribute with confidence it leaves alone rather than nudge you. The nudge only fires when a permission has no static usage and no runtime request naming it.

So the short answer: no, it won't tell you to drop something you only ask for on demand. That's the exact case it's built to not get wrong. Really good catch to probe it though.

@neosrix Thanks Srix. Yes, it does.

Once your extension is built, you connect your Chrome Web Store account once, and PlugThis uploads and publishes directly from inside the app. It also generates the listing description, permission justifications, and privacy disclosures the store asks for, so you are not filling that out by hand. After the first publish it remembers your Store item ID, so pushing an update later is basically one click.

The only parts that stay on Google's side are the one-time developer account registration and the review itself, since approval is always their call. Everything up to hitting submit, we handle for you.

@tan_z_tan 
Love that you asked it that directly, so here's the honest version.

For focused, well-scoped extensions, the kind that do one job well, it's genuinely ship-ready. It generates real Manifest V3 with TypeScript and React, actually compiles and bundles, passes a structural validation and lint pass, and goes through a Chrome Web Store pre-flight before you publish. So it's not throwaway scaffolding you have to rewrite. It builds, it runs, and you can push it to the store from inside the tool.

For bigger or more ambitious ideas, it's better thought of as a strong first draft that gets you 80 to 90 percent there fast, then you refine the last bit either by chatting with it or hand-editing the code directly, and both stay in sync. The value is that you skip the part everyone hates, the manifest, service worker, build config, permissions, and store setup, and land straight on "now I'm tuning behavior" instead of "now I'm configuring tooling."

So: ship-ready for the simple stuff, a serious head start for the complex stuff, and never a blank page. Would genuinely love for you to try it and tell me where the output holds up and where it doesn't. That feedback is exactly what sharpens it.

@neerajkanoi Thank you, glad you found it to be useful. If there is any feature you wan to see in the app, please let us know.