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

Hey PH 👋 Udaya here, founder of . We're a team of four in Bangalore.

Till last year we were building AI products for large enterprises. Then the AI builder wave hit, and tools like Lovable, Bolt, and v0 genuinely inspired us. I built web apps, dashboards, and visualisations with them, and they performed incredibly well.

But when I tried building Chrome extensions with them, it just didn't work. Extensions have a completely different architecture (manifests, content scripts, service workers) and these tools weren't designed for that.


I've been building extensions since 2015 in my first startup, so I know this pain personally. Extensions are the most personal software there is 🧩

We spend 7 hours a day in a browser, and everyone of us has some 15 minute repetitive task they wish would disappear. But there was nowhere to go to build a simple extension for ourself.

We searched the market for something like this. Couldn't find it, so we built it.


PlugThis builds Chrome extensions from a plain English prompt. Real Manifest V3 code that you own, and you can wire up a Supabase backend to make it full stack.

One from my own browser: an extension that reads a Twitter profile as I scroll, researches the person, and scores how close they are to my ICP. Took a few prompts ⚡

For launch week, the Builder plan is at the Starter price, 3 days only 🎁


We are here through the day. Try it out, and tell us what you liked and what you wish it did.

And if you build an extension for yourself today, please share it in the comments. That's honestly the whole point of this product 🙌

 Congrats on the launch 🚀

As someone who has built Chrome extensions, I know they're a very different beast from web apps. The architecture alone can be a hurdle, so I love that you're making this accessible through plain English prompts.

I'm curious, after watching people build with PlugThis, what's the most creative or unexpected extension someone has created that made you think, "We didn't see that coming"?

Excited to see what the community builds with this! 🔥

 My current favourite is Touch Grass It was created by one of our users, its a very well thought and crafted game parading as a extension. Which rewards behaviour like drinking water performing stretches and so on.

Honestly was super impressed and everyone at our office, loves it.

Congrats on the launch! I’m building a doc-signing SaaS and I’m curious about the auth/session layer specifically — if I wanted an extension that keeps a user securely logged into my own backend (not just static UI), how does PlugThis handle things like token storage, session refresh, and avoiding exposing credentials in the extension’s local storage? Is that something the plain-English prompt can reason about correctly, or does that part still need a human security review before shipping?

 Great question, and the right thing to scrutinize for a doc-signing product.

What it handles well: it keeps the session in .local (not a JS variable), so users stay logged in across popup close, worker sleep, and restart. It wires token refresh so expired tokens renew instead of forcing re-login. And sensitive values like tokens are encrypted at rest and decrypted only at point of use, not left in plaintext.

Where I'd keep a human in the loop: the exact trust contract with your backend, short-lived vs long-lived tokens, scoping, rotation, CSRF. Those are system-specific and a generic prompt shouldn't assume them.

So: session persistence, refresh, and no-plaintext-at-rest work out of the box. For an auth layer that signs documents, treat the generated version as a strong first draft and do a security review before shipping. Happy to go deeper on the token pattern if useful.

No code Chrome extensions is a genuinely new surface area.. browsers have been weirdly closed off to non developers for years. I have an onboarding question, when someone builds their first extension and it doesn't quite do what they wanted, is the fix loop "go back to the chat and describe what's wrong" or something more visual? Just a thought, curious how you're handling something like a first-try-failed experience because that moment probably determines whether someone keeps going or gives up.
This looks like a useful way to turn simple ideas into Chrome extensions without dealing with all the technical steps. Congrats & team. What type of extensions are users creating the most with PlugThis so far?

 Thank you, the types of extension being created are wide spread from scrapers to AI powered extensions that do customer research.

But my favourite so far was an interactive digital wellness BFF someone had created that acts as your buddy reminding you to do exercise, drink water every 20 minutes.

One other thing I have observed is people re-creating extensions that already exist and adding features they want on top of them.

interesting pov! Will give it a try. Congrats for the launch!

With PlugThis sitting under Chrome Extensions, AI Workflow Automation, and AI Agents, how much of the extension-building process are you trying to cover? Is the goal prompt-to-working extension, or more like generating the boilerplate and helping refine pieces such as popup UI, background scripts, and permissions?

 Great question! Prompt to working extension is the goal and not providing a boiler plate.

You describe what you want, PlugThis generates manifest, popup, content scripts, background scripts, permissions. It also verifies the build compiles before showing it to you, and auto-fixes if something breaks.

Then you refine by chatting. "Add a keyboard shortcut", "make the popup dark" etc.

You can connect your Supabase and it wires up auth and a database. For AI features you plug in your own OpenAI or Gemini key.

When you're ready to ship, it generates the icons, screenshots and listing copy the Web Store asks for. And the code is yours to download anytime, so nothing is locked in.

Will it handle every exotic extension idea perfectly? Honestly, no. But for the stuff most people actually want to build, you go from a sentence to something installed in your browser in a couple of minutes.

We have managed to build fairly complex extensions, simply by chatting and describing what we want in plain english.


If you have an browser itch, please try out the platform. I am fairly certain PlugThis will be able to solve it.

I've had a few Chorme extension ideas setting in my notes because getting from an idea to working extensions always felt like too much work. i really like that you're focused on one problem instead of trying to build everything for everyone.

 Thank you for appreciating exactly what we are doing. We just want to be the simplest way to build chrome extensions.

Please try out your ideas on Plugthis.ai Super excited to see your ideas to comes to life.

me thinks version history is valuable but can developers compare changes visually A side by side view would help greatly.

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.

 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 focus on one narrow thing is what stands out here, since Lovable and Bolt genuinely do fall apart once you hit manifest files and content scripts. Curious how it handles permission scoping, since that's usually where generated extensions either ask for way more access than they need or break silently when Chrome tightens something. Also, since the code is yours to download, does switching between chat refinement and hand editing the code directly cause any drift, or does it stay in sync both ways.

 Two good questions, both hit the parts that usually rot.

On permission scoping: it's need-based at generation time, so broad host access and content scripts only get added when the feature actually injects into pages, not by default. And because generation and validation run server-side against current Chrome rules, when Google tightens something we update it in one place and every new build follows. So it leans toward minimal rather than the usual "request everything to be safe," and it doesn't silently rot when Chrome shifts.

On the sync question, this is the part I'm actually happy about. There's no separate "chat copy" and "your copy" that drift apart. Both modes read and write the same single source of truth.

- When you hand-edit the code directly and save, that's stored as a normal tracked version.

- When you go back to chat refinement, the AI pulls the current saved files, including your hand edits, not some stale earlier snapshot. So it refines on top of your manual changes instead of clobbering them.

We actually hit that drift bug early and fixed it deliberately: enhancement now prefers the database as the source of truth, specifically so a stale client-side copy after an undo or restore can't make the model edit and then overwrite the wrong version. So it stays in sync both ways, and every switch between chat and hand editing is its own version you can roll back to.

Basically you can bounce between "talk to it" and "just fix the line myself" freely, and it holds together. Curious if that back and forth is how you'd actually want to work.

That's a genuinely satisfying answer, most tools just say "yeah it's synced" without explaining the mechanism. The database as source of truth over a client side snapshot makes sense, that's exactly the kind of bug that only shows up after someone hits undo mid session and then keeps working.

To answer your question, yeah that back and forth is exactly how I'd want to work. Chat for the boilerplate and the annoying manifest stuff, then drop into the code directly for the one line that's easier to just fix by hand than describe in a prompt. If that stays reliable under real use I'd actually trust it for something beyond a weekend project.

 This is exactly the workflow we optimized for, so it means a lot that it matches how you'd actually want to build. Chat for the boilerplate and manifest pain, drop into the code for the one line that's faster to just fix by hand, and not have either mode clobber the other.

And you nailed the bar that matters: "if it stays reliable under real use." That's the right way to judge it, not the demo, the tenth edit after an undo.

That reliability is precisely what we keep hardening, so if you ever push it past a weekend project and something drifts, send it straight to me. That feedback is what makes it trustworthy for the bigger stuff.

Guys, you are amazing. I will try this later because I am building my own (tho manually because I set the goal for myself to learn coding and programming). But this one tool is brilliant! :)

By the way, how comprehensive is this solution?

Because let's say that I am a total beginner and my prompt would be: "Create a plugin that alerts you that you spent too much time on a certain website." – does it know how to create a sufficient structure?

Because real devs are more descriptive and probably would be able to create well-described and specific tasks, like create padding 3px 12 px...

@busmark_w_nika  You are our dream user. The prompt "Create a plugin that alerts you that you spent too much time on a certain website." would exactly build you the extension.

Please try out plugthis.ai you provide simple instruction and the AI will build it.

No need provide padding and other details.

We cant wait to see what you are going to build :D
Please see the video below. I have shown how to build the time gaurd extension, will take 2 minutes.

 I tried to develop it, but somehow it doesn't load after uploading it :D

 Sorry about that, Whenever you find a bug please take a screenshot and paste back into the editor and tell it what you saw and ask it to fix. It will get it sorted.

Solid product. I've used this to create a few of my Chrome extensions to make my day to day work easier.

Although people with AI dev tools can create their own, I think everyone (even non-devs) needs to make their own chrome extensions to make their workflows easier, that's where this just works.

 Thank you for your kind words! Very happy to have you as a user from the earliest days of plugthis.

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?

 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.

💎 Pixel perfection

the manifest/content-script/service-worker mismatch is exactly why lovable and bolt hit a wall on extensions. the abstraction they picked works for pages not for browser plumbing.

real q: how does plugthis handle the distribution side? chrome web store trust is the second wall after the code works. asking because building the extension is now the easier half of shipping one.

 You nailed the framing. Once codegen is solved, building is the easy half and the Web Store is the second wall. That's the part we spent the most on, because "here's your zip, good luck" is where most tools stop.

Concretely, PlugThis treats distribution as a first-class step:

- It generates the listing from your actual code: long description, the 25 to 132 char short description, and the single-purpose statement Google now requires.

- It auto-drafts the compliance surface that usually triggers rejections: per-permission and host justifications, remote-code justification, and privacy disclosures mapped to Chrome's data categories.

- It packages the zip and writes the metadata into the manifest at publish time.

- Then it connects to your Chrome Web Store account over OAuth (refresh token encrypted at rest) and uploads and publishes directly. It remembers your Store item ID, so after the first listing, updates are basically one-click.

The honest boundary: we can remove the mechanical friction and the "did I fill the disclosures right" guesswork, but we can't make Google approve you. Review, trust, and the one-time developer registration are still theirs. What we kill is the part where the code works but you stall for a week because the listing and disclosures are a maze.

Curious if that matches where you have seen bolt and lovable users get stuck, at the store submission rather than the build.

123
•••
Next