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.
PlugThis
Hey PH 👋 Udaya here, founder of PlugThis. 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 🙌
@nefer_ai 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! 🔥
PlugThis
@md_khayruzzaman 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.
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.
PlugThis
@elhart05 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.
+1 to @thenameisarian on the browser-plumbing wall — that manifest/service-worker gap is exactly where the web-app builders stall. @nefer_ai your distribution answer already covers the Web Store side, so I'll ask the two things next to it:
Extensions can't be previewed in an iframe the way a web app can — you load them unpacked and click through real pages. How does PlugThis close the build→see-it-actually-working loop while you're iterating?
And on review: does the generator scope host/API permissions down to just what the feature needs, or is trimming an over-broad manifest still on the human before submitting? Least-privilege is usually what makes or breaks that first review 👌
PlugThis
@akbar_b Both are the right questions, so here's the honest answer with the edges included.
On the build to see-it-working loop: an extension can't live in an iframe like a web app, so we don't fake that. What PlugThis does is render a live preview of your extension's real UI surfaces, popup, side panel, new tab, and options page, right in the browser as it generates, with the chrome APIs mocked so things like opening the options page actually behave. So while you iterate you're clicking a real rendering of the interface, not reading code and picturing it. For the parts a preview genuinely can't reproduce, content scripts firing on real third-party pages and the service worker's live behavior, we make the last mile trivial instead: you get a ready-to-load unpacked build, so "load unpacked and click through real pages" is one drop into chrome://extensions rather than a setup chore. I would rather be upfront that the true runtime still runs in Chrome than pretend a sandbox reproduces service-worker behavior it doesn't.
On least-privilege: scoping happens at generation, so the generator only pulls in host and API permissions when the feature actually needs them, rather than the usual "ask for everything to be safe" manifest. On top of that, PlugThis scans the actual code and detects permissions the manifest declares but nothing ever calls. Instead of writing a justification for a dead permission, which is exactly what gets extensions rejected, it flags it as "no code usage found, consider removing." It's deliberately conservative, so anything it can't attribute with confidence it leaves alone rather than risk telling you to drop something you need. Add the pre-flight checklist and privacy analyzer on top, and the manifest that reaches submission is scoped to what the feature actually uses.
Congrats on the launch, Udaya! 🚀 You really hit the nail on the head—manifest files and background scripts are exactly where general web builders like Bolt or Lovable tend to trip up.
Since extensions rely heavily on background service workers that spin down when idle, how does PlugThis handle state persistence natively? Does the generated code lean heavily on `chrome.storage.local` , or does it automatically set up a sync structure if a user connects a Supabase backend?
PlugThis
@franz_briones Thank you Franz, and you're pointing right at the thing that quietly breaks most generated extensions.
On native state: yes, the generated code treats chrome.storage.local as the source of truth on purpose, precisely because the MV3 service worker sleeps. The generator is explicitly instructed to never hold state only in a JS variable or React state, since that's gone the moment the popup unloads or the worker spins down. So anything that needs to survive gets written to chrome.storage.local and rehydrated, rather than assuming the background stays alive.
On Supabase: if you enable it, it sets up a real structure, not just a key value dump. It wires auth plus CRUD against the Supabase REST API with direct fetch, and importantly it bridges the two layers: the session is persisted in chrome.storage.local so a signed-in user stays signed in across popup close, worker sleep, and browser restart, and expired access tokens get refreshed automatically via the refresh token grant instead of kicking the user back to a login screen. So chrome.storage.local is the local durability layer and Supabase is the remote persistence layer, and it connects them so state survives the worker lifecycle.
Worth being clear on scope: you get durable local state plus a real Supabase backend that survives the worker lifecycle, which covers the vast majority of extensions people actually ship. True offline-first sync, with conflict resolution and a write queue, is a heavier layer we can go deeper on if that's where you're headed. Curious what you're building, because that would tell me fast whether the current setup is enough or whether that deeper sync layer is the thing worth pushing on.
This hits different for anyone doing VC or market research day to day. Half of my job is skimming through founder profiles, pitch decks, and competitor sites, and there's always some tiny repetitive capture step (pull a founder's LinkedIn into a tracker, flag a company against a thesis, snapshot pricing pages) that's too small to justify a real dev cycle but too annoying to do by hand fifty times a week. Being able to just describe that in plain English and have it live as an actual extension I use daily is exactly the kind of 'nowhere to build this' gap you're describing.
Curious whether you're seeing people build extensions for research/data-gathering workflows like that versus more consumer-facing use cases.
PlugThis
Hi @andre_ajemian one of the main issues we wanted to tackle was daily repetitive workflows. You just described the uses cases, for which I have personally built an extension.
It takes in my Product profile, I define a ICP then it scores every person I see on X after doing a web search on them telling me if they are a good fit for my product.
People are building extensions across the board, the data workflows are there but the long tail is so huge. Ideas and problems, I dint even knew existed are getting solved.
Please do try to build for your exact itch, If you need any support, please reach to us via in app chat.
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.
PlugThis
@thenameisarian 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.
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?
PlugThis
@crystalmei 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.