Launched this week
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.
Building a niche-focused SaaS myself, I love the "Lovable, but for X" positioning — going narrow lets you own the whole workflow. Curious: does PlugThis help with the Chrome Web Store review process too (manifest permissions, privacy disclosures)? That's usually the part that kills momentum for first-time extension builders.
PlugThis
Hi @kojimajunya Yes yes we do :D PlugThis tells you your extension's chrome webstore readiness, helps you generate assets and in one click push changes live to CWS.
Please do check out PlugThis and take it for a spin.
this is REALLY timely, i just built a feature spec for my app and a simple chrome extension was part of the design - I want an extension that will scrape monthly statements from accounts (banking, credit cards, etc) and send them to my app automatically....I am non-technical Lovable app builder so i was not looking forward to trying to figure this out on my own....sounds like you might just have the solution i need. Does this sound like a use case your tool can handle?
PlugThis
Hi @crystal_harrison PlugThis should be able to handle this, give it a shot on the platform if you run into challenges, please send me a email udaya@plugthis.ai I ll hop on a zoom call and troubleshoot it for you.
@nefer_ai will do that here when i get off this call!
@nefer_ai So i am super excited....It only took me about 10 minutes in total (assuming i had done it contiguously) and i built and deployed to developer mode and tested my extension of importing a bank statement to my app.....it was so fast and worked like a charm. I loved the tutorial and side bar check list of things to do....that made it so easy as i was a little confused at first, i had to do a little trouble shooting but the tool helped me through that.....very exciting....now i just need to work through the publishing part so users can use it in production mode instead of developer mode.....I thought for sure i would spend hours/days/grey hairs on this....so glad i found this tool! great job building something that it TRUELY needed!
PlugThis
@crystal_harrison You have no idea how much happy this comment makes us happy :) Thank you, for sharing this with us.
"Nowhere to go to build a simple extension for yourself" really nails it — I've got a handful of 15-minute browser itches I never build because the manifest/service-worker setup kills the momentum every time. Since the code is real MV3 that I own, does a build stay Chrome-only, or can the same prompt target Firefox/Edge too? Curious how far the "one thing we do" focus stretches across browsers.
PlugThis
@lennoxbeflying Glad that line landed, and go build those 15-minute itches, they're exactly the sweet spot.
On browsers: today a build is Chrome-first, and the store side is built specifically around the Chrome Web Store. But since everything it generates is standard Manifest V3, the same output already runs on Edge with little to no change, because Edge is Chromium underneath. So realistically it's Chrome and Edge from one build.
Firefox is the honest gap. It supports MV3 but with enough differences in APIs, manifest quirks, and signing that "mostly works" is not good enough, so I would rather do it as a proper target than half-ship it. So the "one thing we do" focus stretches cleanly across the Chromium browsers now, and Firefox is a deliberate next step rather than a checkbox we pretend to have ticked.
Is Firefox the one you'd actually need, or would Chrome and Edge cover your itches? That genuinely helps me prioritize.
What happens when Chrome changes a manifest requirement?
PlugThis
@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?
Congrats on the launch Udaya and team. 🥳
Building chrome extension is not trivial, you need to understand chrome APIs, manifest, permissions and what not. Just having a super easy way to create an extension with 3-4 prompts makes PlugThis worth it. I’ve created few extensions already and the experience was a breeze.
Wonder if the coverage for other browsers is in the roadmap
PlugThis
@cjgiridhar Hi Chetan! Thank you. Glad to have you as one our early users. Your feedback was the reason we built chrome store readiness, asset generation and one click connect to update extensions directly on chrome webstore. Take a bow 🙇 As of now we are focussed on chrome and edge browsers. May be later we might do Safari and Firefox.
Honest question: Claude Code or Codex can already build Chrome extensions better than it , with unlimited revisions and customization. What's the real differentiator here — what's the magic that those general-purpose tools can't replicate? And are you ready to survive that race? I love innovation, but if the existing giants can do the same thing better and cheaper, it's hard to justify investing time in a niche tool. I think you understand where I'm coming from, but I'm genuinely curious to hear your answer. Thanks!
PlugThis
@riponcm Fair question, and I'd rather answer it straight than dodge it.
You're right that Claude Code and Codex can write extension code, and for a developer who already lives in a terminal and wants maximum control, that's a genuinely great path. I'm not going to pretend we out-code a frontier coding agent at raw flexibility. So the differentiator isn't "we generate better code." It's that we're not really in the codegen business, we're in the "get a published extension" business.
Three things that gap covers:
First, the user. Claude Code assumes you're a developer with Node, a build setup, and the patience to wire tooling. A huge number of people with a good extension idea can't or won't do that. For them a general agent isn't a cheaper option, it's a non-starter. We meet the person who says "I don't really code" and still get them shipped.
Second, the last 10%, which is where extensions actually die. A general agent hands you code and stops. It doesn't scope your permissions and flag the ones you declared but never use, doesn't give you a live preview of your popup and side panel without loading unpacked, doesn't write your Chrome Web Store listing, permission justifications, and privacy disclosures, and doesn't publish to the store for you. That whole pipeline is the part people abandon, and it's Chrome-specific, not general coding.
Third, purpose-built means fewer wrong turns. Reviewers on this very launch mentioned general LLMs hallucinating manifest v3 configs and handing back outdated structures. Because we only do one thing, the output stays pinned to current MV3 rules, validated and sanitized, so you spend less time debugging setup and more time on your actual idea.
On surviving the race: general agents will keep getting better, and honestly that helps us, because our value was never the token generation. It's the opinionated, end-to-end workflow around a specific outcome. A frontier model is a better engine, but most people don't want an engine, they want the finished car, plus someone who knows exactly how to get it past inspection.
Different job, different user. I think that's a defensible place to stand, and I appreciate you pushing on it.
Chrome extension generation by chatting is a neat angle. The part I'd worry about as a user is permissions review — it's easy for an extension to ask for too much. Do you show a plain-English diff of requested permissions before build/export?
PlugThis
@xiaosong001 Good instinct to worry about that, it's exactly the failure mode we wanted to avoid.
Yes, before you publish you get a plain-English breakdown of every requested permission, with a reason for each one generated from your actual code, not a generic template. So instead of a raw manifest list, you see "this permission is here because the code does X," and you can edit any of it before it goes out. On top of that, any permission the manifest declares but the code never actually uses gets flagged as "no code usage found, consider removing," so over-asking gets caught rather than justified.