Sprint 2: Tryextended.com: Lovable for Chrome Extensions
June 1st - June 14th- I built a dev tool that helps you build, debug, and share Chrome Extensions instantly because every modern agent is basically a Chrome Extension in disguise.
Sign up to waitlist & watch demo on tryextended.com
Coming off of Sprint 1 & helping nonprofits use computer use agents to monitor websites for up-to-date referral info, I wanted to build for a new industry I was familiar with that had a ton of problems: chrome extension developers.
I’d built over 7 extensions, and last year had built one with a built in computer use agent for people with limited mobility to use their voice to control their computers - starting with gmail. I had the insight that every single web agent nowadays is literally what we would’ve called a Chrome Extension acting on a webpage two years ago. Companies offering agentic browsers essentially are cherrypicking use cases where a specific workflow is done on a specific website that’d be better off solved by a one-off chrome extension & betting that their agents can build the same accuracy of tools on demand that already exist in extensions. Building first for Chrome Extensions as a wedge is a play into winning the full browser agent workflow space.
Going in, then, I had the following hypothesis, vision, insight, and pre-mortem:
Hypotheses:
Developers struggle with building extensions nowadays & would pay $10/month to save on time & stress. A solution would be an overlay IDE that lets them easily send console logs, DOM elements, has a system prompt of how extensions worked, and hot reloaded, plugged into an agentic IDE due to the following current issues:
Icons aren’t generated automatically since extension documentation wasn’t reflected well in LLM training data (testing 15+ competitive tools found that every single no-code builder sucked at building chrome extensions- see appendix).
It’s hard to give a coding agent like Cursor DOM context - copy pasting leads to extremely long messages Cursor declines due to length
Pulling up console to debug then copying it over is annoying
Forced refreshing pages & extensions on chrome://extensions to test
Vision: Every chrome extension developer uses Extended to build, debug, and share chrome extensions.
Insight: Every single web agent nowadays is literally what we would’ve called a Chrome Extension acting on a webpage two years ago. As new people try building browser agent interactions for themselves, for work, or school, they’ll inevitably bump up into the same chrome extension issues. Companies offering agentic browsers essentially are cherrypicking use cases that’d be better off solved by a one-off chrome extension. Google meanwhile is betting on a 1P centralized Mariner agent to rule them all. Once agents went from text output, to action output, to using tools, the next inevitable step no one is discussing is they’ll make their own tools in the moment (see Perplexity’s play). Since big tech wouldn’t launch a full agentic browser until accuracy was high enough, though, 3p developers could play a role in building those tools meanwhile. Additionally, 99% of agentic browser interactions big tech would likely advertise would be essentially useless since the latency would offset the value of the alternative of doing it yourself.
Premortem: I’d read about Plasmo who’d tried it before & failed, had an estimated graph showing only ~6% of chrome extensions ever made money, and any reddit post about monetization (“I made 5$ on my extension”) received 100+ likes which pointed to it being largely unprofitable. My vision was to start with extension developers then pivot quickly to workflows of agents due to the overlap, but the the likeliest reason I’d fail is I wouldn’t be able to get extension devs to pay due to:
There not being enough devs building chrome extensions that made money.
If they did make money they would be so used to the issues & technical enough to speed through them by routine.
Learnings: In week 1, I spoke with experts who were building extensions & someone who was early at the web store. It seemed obvious that Google was neglecting extensions and not making the connection between agents & extensions. I made a map, how might we post it notes on Figma, and chose: HMW reload faster, explain error messages, and make building an extension with natural language easier. I also set up Sprint 3 separately. I spoke with agent founders & pretended I was only building for chrome extensions rather than a clear follow-on wedge into browser agents which had a much higher TAM - they confirmed my suspicion of it being overlooked since none of them recognized the connection, all saying “chrome extensions is a tiny market.”
It became clear quickly, that it would need to be open source, have a bit of setup, and be a full package:
Open source: As I built an overlay in the browser that gobbled console logs, errors, selected dom elements, and had a text box to send messages to an async agent in the cloud to code the extension, I realized if I wanted a quick MVP which integrated with Cursor & VSCode- with the assumption that developers wouldn’t change from their IDE to an in-browser one since they were so used to using their current one so it needed to be in flow- and therefore it needed to be open source since without an API to the editors’ agents, I relied on app-scripts. Since that meant users had to toggle permissions, it was a no-go unless devs were clear it was safe due to open source.
Setup: To do hot reloading I thought for a while until I came up with an idea to create a custom system prompt appended to every message sent that would guarantee the agent finished by editing a changelog.txt file, and set up a local server that watched that file & told the overlay to refresh the page/extension when done.
Full package: Since we were building a new extension but that extension needed to listen to the server to hot reload, I realized we would need 2 extensions: the IDE overlay, and a boilerplate with just hot reloading. Once the extension was finished being made, I added a button for a special prompt to send the coding agent to remove the boilerplate that started at the beginning so it’d be a full extension.
As a result, ta-da, we had literally every requirement done. While the setup was intuitive (download requirements.txt, start the server, import the IDE & boilerplate extensions then add accessibility permissions and you’re good to go), I disliked how it wasn’t just an immediate working prototype, since the original vision was a cloud-based async agent overlay without all these moving parts. To test this, I partly built a full IDE in-browser with a running Chrome instance hot-reloaded with extensions, and surprisingly found even devs preferred this version, with one saying they’d ditch Claude Code if this worked.
However, after more interviews - it became super clear that most “workflow builders” aren’t tools: they’re homework.
Users don’t know what workflows they want automated - the quintessential AI “solution in search of a problem,” wherein the creator asks users to come up with the solution the tool they’re offering solves. Especially if the solution is an IDE or SDK that requires learning, it’s a high bar to match every single positive of an alternative, or offer something way better in one domain that outshines the rest.
I knew that if I offered an IDE for chrome extensions, people would pay for it (I’d gotten feedback)- especially to build internal tools, in vertical industries, though it would be hard to have a high retention rate as users realized how hard it is to monetize- which felt like the underbelly of these vibe coding tools: offering salt-water to thirsty people - the dream that other vibe coding tools give that “if you only learned my tool you’d be able to quit your job and be rich,” with <1% of creators actually making any money while ads abound of building your dreams & quick dopamine hits. For Sprint 3, I wanted to focus on a piece that was a huge neglected piece in this entire story, and might’ve opened up the entire ecosystem. In fact, sprint 3’s carried me over into Sprint 6 (where I’m at now), since I got validation after validation for the next rounds of hypotheses (which I was skeptical about since it seemed too good to be true). Sprint 3’s retro will be filled with pending nights in Emeryville outside SF, joining capture the flag events, building airtight infra, while Sprint 5 revisits an old idea. See you there!