Launching today
PlugThis
Like Lovable, but for Chrome extensions
447 followers
Like Lovable, but for Chrome extensions
447 followers
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 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.
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.
me thinks version history is valuable but can developers compare changes visually A side by side view would help greatly.
PlugThis
Love this, Hana, and you're reading it right.
Under the hood PlugThis already computes a per-file diff between any saved version and your current build: which files were added, modified, or removed, plus the old and new content side by side and a quick +/-/~ summary of the changes. So the compare data is already there.
Turning that into a proper visual side-by-side view is exactly the next step, and honestly comments like this are what push it up the list. Would you want it as a full two-pane code view, or more of an inline "what changed" highlight? Curious how you'd actually use it day to day.
PlugThis
@hana_salazars Love this, Hana, because it already works exactly how you described.
PlugThis has a version diff view built in: pick any earlier version and it opens a real side-by-side compare (old on the left, new on the right, line by line) powered by the same diff engine as a proper code editor. There's a file list next to it showing what was added, modified, or removed, so you can jump straight to the files that changed instead of hunting.
So it's not just snapshots you eyeball, it's a genuine visual diff. Curious what you'd want on top of it. Inline comments on a diff? Diffing two arbitrary versions against each other rather than against current? Would love to hear how you'd push it further.
The versions history caught my attention. i've learned the hard way how valuable it is to roll back when an experiment doesn't work.
PlugThis
@elidodial67la Totally with you, Elido. That "undo the experiment that broke everything" moment is exactly why it's there.
Every time you change the extension, PlugThis snapshots the full file set before applying the new version, with a summary of what changed and a timestamp. So when something breaks, you can restore an earlier working version in one click instead of trying to reverse-engineer what you had. And restoring is safe too: it saves your current state first, so jumping back never costs you the work you're on.
Curious what you've been building where rollback saved you. Sounds like there's a war story there 😄
always wanted to experiement with Chorme extension but the setup process kept pushing me toward others projects. this makes the whole process feel much more approcahable.
PlugThis
@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.
Firefox or Edge support planned, or Chrome-only for now?
PlugThis
@zoe_sullivan Fair question, Zoe.
Right now it's Chrome-first, and the store side is built specifically around the Chrome Web Store (permission justifications, listing assets, review prep all target Google's flow).
That said, everything it generates is standard Manifest V3, so the output already runs on Edge with little to no change since Edge is Chromium under the hood. Firefox is the bigger lift because its manifest quirks, APIs, and signing differ enough that "mostly works" isn't good enough, and I would rather do it properly than half-ship it.
So: Chrome and Edge realistically today, Firefox as a deliberate next step rather than a checkbox. Out of curiosity, is Firefox the one you actually need, or was Edge enough for your case? That genuinely helps me prioritize.