PlugThis - Create your own Chrome Extensions by chatting with AI

by
You wanted a Chrome extension that would save you 15 minutes a day. You searched the Chrome Web Store, and it's not there. Now you can just describe it in plain English, and PlugThis builds it for you. The code is yours. Want changes? Chat. Need login or a database? Connect Supabase. Ready to publish? We generate the icons, screenshots, and listing copy the store asks for. Everyone else builds web apps. We build Chrome extensions.

Add a comment

Replies

Best

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!

 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?

 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.

Congrats on the launch 🚀

The permission-scoping and service-worker answers here are more honest than I expected. One thing I didn't see asked: what happens when the extension someone describes needs a third-party API key. We shipped an internal extension that called an LLM endpoint and I pulled the key back out of the packed CRX in about a minute, because encrypting it at rest doesn't help when the decryption key ships in the same bundle. We ended up proxying every call through our own backend. Does PlugThis push people toward a proxy when the prompt implies a keyed API, or does it inline the key and leave that to the user?

The tool we need for everyone's ideas on how they can be more productive, since we use Chrome for work every day. Loved it 😍

First
Previous
•••
345