PlugThis - Create your own Chrome Extensions by chatting with AI

@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.

@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.

@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.

@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.

@mshen316 This is the exact person we built it for, Michael 😄 A year in the notes app is long enough, today's the day.

And good news, the Twitter ICP scoring idea is right in the sweet spot: read the profile or timeline, score it against your criteria, show the result inline. You describe it in plain English and it figures out the structure, the permissions, and the scaffolding for you, so not really coding is not the blocker it used to be. You can refine it just by telling it what you want changed.

One tip: start with the simplest version of the idea, get that working and seeing it live, then add the fancy scoring logic. Momentum is everything, and this time you won't lose it to setup.

Go build it, and please come back and tell me how it went. Genuinely rooting for you on this one.

@jason_scott8 Appreciate that, Jason

Permissions are kept minimal by default. PlugThis only requests what the described feature actually needs, so nothing broad gets pulled in silently.

And you're spot on about explanations building trust. That's already baked in: before submission, it auto-drafts a plain-language justification for each permission (why it's needed, what it touches) for the Chrome Web Store form, plus flags when a privacy policy is required. So the reasoning is spelled out instead of users just seeing a scary permission prompt with no context.

Would love to hear if you'd want those explanations surfaced to end users too, not just the store form. That's a really interesting direction.