Backlog
7Under consideration
Google Sheets as Backend.
Let an extension read and write a Google Sheet, without the user having to set up a database. Right now, if you want your extension to store anything, the options are a real backend like Supabase, your own API, or nothing. For a lot of what people actually build, a spreadsheet is the correct answer. It is free, they already have one open, and they can look at the data without asking anybody. What this would look like in PlugThis. Connect a Google account, pick a sheet, and the built extension can append rows, read rows and update them. Same shape as the existing Supabase support, but pointed at a sheet. Why it matters. Most first extensions do not need a database. A form that saves leads, a page clipper, a price tracker, a time log. Every one of those is a spreadsheet with a nicer front end. Telling somebody to go and set up Supabase to save five columns is the point where a non technical person gives up. It is possible today by building the Sheets API calls into the extension yourself, but that means dealing with OAuth, scopes and a client ID, which is exactly the part that stops people. Requested by an agency customer on Tier 4, 4 September 2026. They had already done it through Claude and wanted it native.
Connect my NoCodeBackend without wiring it by hand
You can already build an extension that talks to NoCodeBackend, because it is a normal API and the generator can call it. But you have to describe it every time. Paste the endpoint, explain the shape of the response, tell it where the key goes, and hope it gets the details right. That is a lot of typing for something that is the same for everybody. What an official integration would do: Add your NoCodeBackend key once in settings, the same way OpenRouter works today, instead of putting it in a prompt. Let the generator know the API shape already, so you can say "save this to my leads table" rather than describing endpoints and payloads. Pick the table you want from a list, rather than typing its name and hoping it matches. Set up the permissions properly by default, so the key that ships inside your extension can only do what it needs to and the admin key never leaves your account. That last one matters more than it sounds. An extension is client code. Anything inside it can be read by whoever installs it, so the difference between a key that is safe to ship and one that is not should be handled for you rather than left as something to remember. This has come up alongside Supabase, so it is worth treating as one question: how do you connect a backend to what you build here without wiring it by hand each time.
MCP
Three people have asked for this in the past week, each wanting something slightly different, and the differences matter. One wants to generate a large number of extensions from written specifications rather than by typing into the builder two hundred times. One wants an agent to create a project and push a planned sequence of prompts into it, then hand back the result. And one is not a developer at all. He is copying prompts and errors back and forth between ChatGPT and PlugThis by hand, and wants the two to talk to each other so an extension can be built, tested, fixed and retested without him carrying the error across each time. That last one is the most interesting, because it is not really about automation. It is about not being the messenger. WHAT THIS WOULD BE An API you can call from your own scripts, or from an agent, to do what you do in the builder today. Create a project. Send a prompt. Get the result back. See whether it built and why it failed if it did not. MCP would sit on top of that rather than beside it. It is a thin layer that lets Claude or ChatGPT use the API as a tool, so the API has to exist first either way. That simplifies the decision: build the API, and MCP comes almost free afterwards. THE ONE THING THAT WOULD MAKE IT SAFE If a build is going to run without somebody watching it, the result has to be checkable without a person. So the response should say what was actually produced. The files, the final manifest read back out of the finished package, and whether it matches what was asked for. A build that quietly produces something broader than requested should fail rather than deliver. That is worth more than the automation itself. It is the difference between generating at volume and generating at volume safely. WHAT IS NOT DECIDED Whether a sequence runs unattended, or each build comes back so you choose the next prompt. Those are different products and I do not yet know which people want. If you vote for this, say which of the three shapes above is yours. That is the part that will decide what gets built. Please leave comments.
Multiple named API keys per provider
Store more than one set of credentials for the same provider, give each one a name, and pick it by name when building. Example: "Supabase Orange", "Supabase Client B", "ChatGPT Orange". At build time you choose which set the extension should use. Today, Settings → AI & Web Search Keys already stores keys for Groq, OpenAI, Gemini, Parallel and Supabase, encrypted, at both profile and workspace level. The storage is there. What is missing is naming them and holding several sets of the same type. Also part of this: more providers in that list. Useful for anyone building for multiple clients or multiple projects from one account. Requested on the AppSumo deal page, 1 Sep 2026. Check this image from another app just for inspiration: https://i.postimg.cc/s35ghRY7/app-store.png
Different limits for different people, not one number for everyone
Generation limits already let you set a cap per person and a cap per workspace. That is useful, but it is one number applied to everybody. In practice people are not equal. The person doing the building all day needs a bigger ceiling than the colleague who opens it once a week. One client project may be four times the size of another. Right now, setting a cap low enough to protect the account also throttles the person who actually needs the room. What this would do: Set a different limit for each individual seat, rather than one number applied to all of them. Set a different limit for each individual workspace, so a large client project and a small one do not have to share the same ceiling. Keep blank meaning no limit, exactly as it works now. Nothing changes unless you set something. Show each person's and each workspace's own ceiling next to what they have actually used, so the breakdown and the caps sit together. This is an extension of the limits that already shipped, not a replacement for them.
Tell me that publishing is even a step
A customer built a working extension, used it every day, and had no idea that putting it on the Chrome Web Store was something he could do. In his words: "I am so new to this that I didn't even know it was something that needed to be done." He is not unusual. Most people stop at the download and never find out what comes next. What this would do: Say clearly, once an extension is working, that publishing is available and roughly what it involves. Explain that you can list it privately, for your own team or school, without selling anything to anybody. A lot of people assume publishing means distributing. Show the steps before you start, rather than after you have committed to it. The publishing tools already exist. People simply do not know they are there.
Tell me when the error is yours, not mine
When a build fails, it is not always clear whether the problem is in what you typed or in something on our side. So people rewrite the prompt. Then rewrite it again. And the whole time nothing they type can possibly help, because the fault was never in the prompt. That has cost real money this week. One person spent 18 of their 20 generations on an error they could never have fixed. Another spent five. Several more tried seven or eight times each. Not one of them could have solved it, and nothing on screen told them to stop. What this would do: When we know a failure is on our side, say so plainly in the message. Tell you to send it to us rather than try again. Tell you not to spend anything more on it. Never charge a generation for a failure we caused. Suggested by a customer, in his own words: "something like this error is on our side, copy and paste and send it to us, that way the user will know and won't be burning credits". He is right.
Next up
1Committed and queued
In Progress
3Actively being built
Bump the version number automatically
Increase the extension's version number automatically, instead of leaving everything at 1.0.0. Today every build comes out as 1.0.0 unless you remember to ask for something else in the prompt, or edit manifest.json by hand after downloading. Why this is not cosmetic. The Chrome Web Store rejects an upload if the version number has not increased since the last one. So anyone publishing has to remember to bump it before every single submission, and they usually find that out when the store refuses their update. What this should do. When you make a change to an existing extension, increase the last number on its own. 1.0.0 becomes 1.0.1, then 1.0.2. Show the current version somewhere obvious so you can see it moving. And let people set it themselves when they want to, so a big release can jump to 2.0.0. Chrome accepts one to four numbers separated by dots. Letters and words are not allowed, so we should stop anybody entering something Chrome will refuse. Worth pairing with the publish flow. If someone is pushing an update to the Web Store and the version has not changed since the last publish, we already know that upload will fail. We should say so before they submit rather than let the store reject it. Requested by a customer, 4 September 2026.
Prebuilt modules you switch on
Tick a box in project settings and get working login, payments or a settings page, instead of generating that plumbing from scratch every time. Every extension needs roughly the same foundations. A configuration page. Somewhere to store things. User accounts, if it has users. Payments, if it charges for anything. Today all of that gets written fresh for each build. That means it is subtly different every time, and differently broken every time. It also means the same person builds the same login screen five times across five extensions. What this should be. A short list of modules in project configuration. User registration and login. Payments. Settings and configuration page. Basic content management. Tick what you need and it is generated into the project, already wired together and already tested. The important design decision. These must point at your own backend, not ours. Tick login and it generates Supabase auth into your project using your keys. Tick payments and it wires Stripe to your account. You get plumbing that has been tested once and used by everybody, and we never hold your users or your money. You can still take the code and run it without us, which is the promise we make everywhere else and are not going to quietly break here. The alternative, where login and payments run on our servers, would ship faster and make every customer dependent on us. Not doing that. Honest scoping. This is a real project rather than a small addition. Auth and payments both need something server side, and getting that right once is exactly the reason to do it centrally. The first module matters more than the list: better to have one that people actually use than four nobody switches on. Requested by a customer, 5 September 2026, who put it well: "you know it works, it is tested, and it is secure, because it is done once for all."
A quality bar for the Marketplace
Every extension published to the public marketplace gets checked before it appears,
Done
20Recently shipped
Allow code change in editor
As of now, there is a way the code tab lets users type, but it does not have a way to save the edit back, and the changes do not persist. Changing a background color should not cost a build. From Appsumo user 3 Sep
Use Chrome's built-in AI (on-device)
Let a built extension run its AI on the user's own machine instead of calling a cloud API. Chrome ships a local model to the browser, reachable from an extension through the Prompt API (LanguageModel.create()), the Summarizer API and the Translator API. Stable for extensions since Chrome 138. Why it matters: no API key, no per-call cost, and the page content never leaves the browser. For an extension shipped to a lot of users, that removes the running cost completely. What this would look like in PlugThis: pick between a cloud provider and Chrome's built-in AI at build time. The built-in model is not available on every machine, since it depends on the user's Chrome version, their hardware and whether the model has downloaded, so the generated code should check availability and fall back to a cloud key when it is missing. Built-in first, cloud as backup. Requested on the AppSumo deal page, 1 Sep 2026.
Use my own Icon
Let me upload my own logo and have it used as the extension's toolbar icon. Today PlugThis generates an icon for every extension. If you attach your logo in the chat and ask for it to be used, it looks at the image and then makes its own version anyway, because images in the prompt are treated as something to look at rather than as a file to include. That is not obvious, and it costs a generation to find out. What this should be. An upload button, one image, and the build uses it. Chrome needs three square PNGs, 16, 48 and 128 pixels, so we should resize the uploaded image into all three rather than asking anyone to prepare them. The workaround today is to download the extension, open the icons folder, and replace icon16.png, icon48.png and icon128.png with your own, keeping the file names. That works, but it means anybody with a brand has to do it by hand after every single build. Why it matters. Anyone building for a client or for their own company needs their logo on it. Right now the first thing they do after downloading is undo something we did for them. Requested by a customer, 4 September 2026.
Tell me when Chrome breaks my extension
Right now, if Chrome changes something that affects an extension you already built, you find out when it stops working or when the Chrome Web Store rejects your update. Nobody tells you. The request: PlugThis should watch for those changes and tell you which of your extensions are affected. What it would look like: An alert when a Chrome policy or API change touches something one of your extensions actually uses. Not a general newsletter about Chrome, but "your extension X uses this API and it is being removed in Chrome N". A one-click fix from that alert, so the extension can be updated for the new requirement without you having to work out what changed. A note of which Manifest version and which APIs each of your extensions depends on, so the matching is accurate rather than guesswork. Why it matters: Manifest V3 removed the blocking webRequest API and a lot of extensions died because of it. That will happen again. People who built something a year ago and stopped thinking about it are the ones who get hurt, and they are exactly the people who cannot fix it themselves. Requested on the AppSumo deal page, 2 Sep 2026.
Add Open Router support
Like how Gemini, OpenAI, Grok, parallel support is provided. Provide open router integration. This is from a user comment on the AppSumo question on 2nd September.
AI to fix a runtime bug
Possibly give more credits to a user which they can use for debug. Because it feels unfair that the main quota used for generation is being used for debug Notes: Possibly provide the services as v0.app, free bug fixes when the program is mis-function or crashed. Customer from AppSumo 3 Sep
Per-user and per-workspace generation limits
Today the generation allowance is one shared pool for the whole account. Everyone in every workspace draws from the same number, first come first served. That breaks down for teams. A distributed team was the case that surfaced it: people in an earlier time zone can use most of the month's generations before their colleagues have started work. The same applies to an agency where one client project quietly consumes the budget meant for three. What is needed: Set a cap per user, so each seat has its own ceiling and nobody can drain the account. Set a cap per workspace, so each client or project has its own budget. See who used what. A simple breakdown of generations by person and by workspace for the current period. You cannot manage a limit you cannot see, and today there is no way to find out where the month went. Sensible defaults would be no cap unless the owner sets one, so nothing changes for solo users, and a warning to the owner when a seat or workspace is close to its limit. Requested on the AppSumo deal page, 2 Sep 2026.
Memory leak guard for sidebar extensions
A sidebar extension left open on a heavy page can slowly eat memory until the tab crashes. Reported on a Facebook page, where the sidebar had been open for a while. The generator should handle this by default rather than leaving each person to find it. That means cleaning up properly when the panel closes or the tab navigates: disconnecting observers, clearing intervals and timeouts, removing event listeners, and releasing anything held in memory between renders. Right now it can be fixed by asking for it after the fact, which works, but you only know to ask once your tab has already crashed. Applies to every side panel build, not just one site. Reported by a customer on 1 Sep 2026.
Plain-English change history
Version history that tells you what changed in words, not just which files moved.
Extensions that pass review first time
Manifests now ask for the narrowest permissions they need instead of broad host access, and hardcoded credential mistakes are caught and rebuilt before you ever see them.