Launching today
Got an idea for a Chrome extension? Describe it in plain English and PlugThis builds it. Real code, a real backend, ready for the Chrome Web Store. Refine it just by chatting. Connect Supabase for login and a database. Every change is saved as a version, so nothing is ever lost. When you're ready, we generate the icons, screenshots, and listing copy the store asks for. Everyone else builds web apps. We build Chrome extensions. That is the one thing we do.
I like that you picked a narrow but painful category. Chrome extensions look small from the outside, but manifests, content scripts, service workers, permissions, store rules, icons, screenshots, and listing copy make them very different from a normal web app. as a builder, I can immediately think of a few annoying browser workflows that would be perfect as tiny personal extensions.
Curious how PlugThis handles permissions and Chrome Web Store review risk. if someone asks for an extension that reads pages, injects UI, or works across many websites, does it guide them toward safer/minimal permissions automatically?
PlugThis
@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.
Congrats on the great launch! QQ - what about permissions requested at runtime through chrome.permissions.request or optional_permissions? Those probably almost never show up in a static call graph, so does the analyser read them as dead and nudge you to drop something you only ask for on demand?
PlugThis
@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.
"Complex extensions from plain English" is bold. Where's the actual ceiling here?
PlugThis
Hi @hannah_parker5 one of our favourite questions to ask ourselves.
What works really well today: scraping pages into CSVs, AI stuff on page content like summaries and reply drafting, Gmail tools, highlighters and note savers with cloud sync, tab utilities. You can also wire up Supabase for login and a database and build real full stack extensions.
I am fairly certain, you ll be able to rebuild almost 90% of extensions found on the Chrome webstore in few prompts.
The actual ceiling: recording calls, monitoring pages in the background for days, and complex integrations with other apps.
The best and fastest way to find the ceiling is to throw your boldest idea at it. You get 5 free builds, no card. If it breaks, come back and tell me, I genuinely want to know.
PlugThis
@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.
I like the focused approach but how do you handle Chrome permission requests Maybe adding permission explanations could improve user trust.
PlugThis
@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.
I enjoy the idea of creating Chrome extensions without extra setup but how do you test compatibility across different Chrome versions Providing built in testing tools before publishing could help developers catch problems earlier with confidence.
PlugThis
@stacey_connolly2 Really glad this resonates, Stacey, and you're pointing at the right gap.
Two honest layers here. Manifest V3 is a versioned, fairly stable contract, so most compatibility comes down to which APIs you use versus the minimum Chrome version your manifest declares, rather than surprises between recent Chrome builds. PlugThis generates against current stable MV3, so you're not landing on deprecated patterns to begin with.
On the "catch problems before publishing" side, there is already a pre-publish pass built in: it compiles and bundles the code (so it won't ship if it doesn't build), runs a structural manifest validation, a lint pass that auto-fixes common issues, and a Chrome Web Store pre-flight checklist that flags pass, warn, and fail items before you submit.
Where you're right that we're not there yet: we don't spin the extension up across multiple Chrome versions and run it. That kind of "load it in Chrome N and Chrome N-2 and watch it behave" testing is exactly the kind of built-in confidence tool worth adding, and it's the honest next step rather than something I'll pretend already exists.
Would you want that as automated smoke tests on publish, or more of a manual "preview in a sandbox" you can click through? Curious which would actually earn your trust before hitting submit.
How does the versioning work when you want to roll back, do you get a full diff or just snapshots you have to rebuild from?
PlugThis
@orukfaruk63783 full snapshots for reliability, diffs layered on top for clarity, and zero rebuild step either way.