Leveraging a marketplace and existing user bases to hit a 5-figure MRR in two years

Adi Leviim found a problem and validated the solution by analyzing forums and reviews. Then, he and his cofounder quit their jobs.

Less than two years later, AI Toolbox has a 5-figure MRR and over 35,000 users.

Here's Adi on how he did it. 👇

Scratching his own itch

I'm Adi Leviim, a full-stack developer with 7+ years of building products. I cofounded Infi Developments with Mohammad El-Esawi. Together, we have about 12 years of shipping SaaS, and we split the work cleanly: I lead product development, frontend architecture, and AI integrations, while Mohammad handles backend architecture, algorithms, and LLM systems. Two people, no committee. This allows us to ship a fix the same day a user reports it.

In mid-2024, we both used ChatGPT daily for coding, research, writing, and brainstorming. After a few months, we'd each had hundreds of conversations, with no way to find anything within them. No folders. No search within your own messages. No way to export or bulk-manage. We both scrolled sidebars, hunting for a chat we knew was there.

So, we built what we wanted: AI Toolbox, a browser extension that adds nested folders, full-text search across every message, bookmarks, a prompt library, and bulk export. It started as ChatGPT-only, but now it works with Gemini, Claude, and Grok.

I'm proudest of the feature nobody asked for: search that spans all four platforms at once. It runs on an index that lives on your own device and never touches our servers. No AI company will ever ship this feature, because building it means indexing their competitors. That's our company's entire thesis in one line.

We launched on the Chrome Web Store in September 2024. Less than two years later, we have 35,000+ active users across 150+ countries, a 4.5/5 rating, a Featured badge from Google, and a 5-figure MRR.

Validating and quitting his job

Two developers being irritated by something is not a market, so we looked for other people's complaints before building anything. Specifically, we went where people complain unprompted: Reddit and OpenAI's official community forum. That's a completely different signal from asking people what they want. Nobody writes a forum post about a mild inconvenience.

We found the same handful of frustrations repeating in other people's words: I can't find my old chats, there are no folders, I can't search what I actually wrote, I can't get my data out. Those complaints became our first feature list almost verbatim. We weren't guessing what to build; we were transcribing.

That made the decision easy, and it wasn't a small one. Mohammad and I were full-time colleagues at the same startup. We met there, and that's why we already knew we could build together. Once we had this idea, we didn't try to squeeze it into nights and weekends. We quit our jobs and went all in on AI Toolbox.

Spending $32 and two weeks on v1.0

The initial build cost us $32 and took two weeks. That isn't a joke or a rounded figure: $27 for a virtual machine to run the backend, and $5 for the Chrome Web Store developer fee. That was the entire capital cost of the company. No agency, no contractors, no investment, no ad spend. Just the two of us and our own time.

The first version did exactly one thing: it searched your chat history. That's all. No folders, no export, none of what the product is today. We went through those forum complaints, picked the sharpest one, and built only that. Two weeks after launch, we shipped bulk actions, allowing you to select a pile of chats and delete or archive them, as people kept asking for this next. We now have over 35 features, and almost every one after the first arrived similarly: a customer requested it. The two features people lean on most today — bulk export and the "//" prompt shortcut — weren't in that first build at all.

Architecture decisions

The extension uses TypeScript with no UI framework (no React, Vue, or others). This is a deliberate choice, not laziness: a content script is a guest in someone else's DOM. Every kilobyte we ship adds to the user's page load, and pulling a framework's runtime into a page we don't own is a great way to fight with the host app and lose. We use plain TypeScript and direct DOM work, bundled with webpack, esbuild-loader for speed, and Terser to keep it small. UI that must be bulletproof against the host page renders into shadow DOM, ensuring their styles and ours cannot conflict.

Chrome's Manifest V3 shaped our architecture more than any framework decision. Two constraints stand out. First, the service worker can be killed at any moment, so nothing can live in memory and expect to persist. Everything is stateless or database-backed, and every operation must be safely repeatable. Second, and this one bites people: an MV3 content script cannot load JS chunks at runtime. Code splitting silently fails. It's not a build error or a catchable exception; it's simply a feature that doesn't work in production. So we ship one eager bundle and treat bundle size as a real budget rather than something the bundler solves for us.

The backend is deliberately boring, and I mean that as a compliment. We use Node and Express in TypeScript, MongoDB, and Redis for rate limiting, all running on a single Ubuntu droplet behind Nginx with PM2 keeping the process alive. That's the whole thing. No Kubernetes, no microservices, no managed anything. The database lives on the same box, which sounds quaint until you realize it means the database is not exposed to the internet at all. We encrypt everything we store at rest. What we store is only the organizing layer: folder names, tags, saved prompts. The one piece of real machinery is PDF export, which runs through headless Chrome on the server — the conversation is rendered in the moment, and nothing is retained afterward. Getting typography and full Unicode right client-side is a losing battle when your users write in Hebrew, Arabic, Japanese, and Chinese.

The decision I'd most strongly defend from those early weeks was to run search on a local index. Every conversation is cached in IndexedDB in your own browser, and search runs there, not on our servers. We chose it for privacy, as we were uncomfortable holding other people's conversation history, and it proved to be the best product decision. Search is instant, a bulk export of fifty chats costs zero extra API calls, and two years later, it's the only reason we could build cross-platform search at all.

Building for a moving target

The real challenge was never the features; it was the underlying platform we built on. ChatGPT has no public API for your own conversations. No documented "list my chats" endpoint, no sanctioned way to read your own history, nothing a tool like ours is invited to plug into. So the entire product runs on the same undocumented endpoints the web app uses, within an extension injected into a page we don't own and can't predict. OpenAI ships UI changes whenever they like and owes us nothing.

Here's a real example. Gemini redesigned their sidebar. We had a selector that hid Gemini's own search results while we displayed ours. After the redesign, that selector matched a different element: the sidebar's own recent-chats list. So our CSS hid the user's entire chat history. The data was completely safe; it was just invisible, a distinction nobody cares about when they open the app and their chats are gone. To be clear, this was our fault, not Google's. We'd reached for a global selector on a page we don't own. Their redesign didn't break us so much as find the fragility we'd already shipped.

That constraint shaped every decision since: Assume the ground moves, build multiple fallbacks for every anchor into their UI, and never let one selector change take the product down.

Stealing from game design

We steal from games. Not the aesthetics, the mechanics. Games have spent decades solving a problem productivity tools are terrible at: making someone want to come back tomorrow. Streaks, progress, small milestones, the feeling of a thing being yours because you've built it up. A folder tree is exactly that if you frame it right.

Most productivity software treats habit as the user's responsibility, and games treat it as the designer's. We take that seriously, and work along those lines isn't public yet.

Shifting the business model gradually

For the first three months, the extension was completely free. Not freemium, not a trial. Free. We had one feature and no reputation, and we couldn't get feedback without users. That period gave us the two things we needed: daily users and a community to tell us what to build next. Almost everything we shipped in year one came from that period.

Then, we launched freemium: a free tier with limits and Premium as monthly or lifetime plans, running on Lemon Squeezy. The free tier isn't a crippled demo. It's genuinely useful on its own, which matters because most paying users started as free users who hit a wall doing real work, rather than being sold to.

When we went cross-platform, two things changed. We moved billing to Polar and added plans that only make sense once you're on four sites: All Access, which covers ChatGPT, Claude, Gemini, and Grok, and a seat-based tier for teams. That's where expansion lives. A user who buys for ChatGPT and then starts using Claude has an obvious next step; it's the same product they already trust. Every new platform we add makes All Access worth more without changing our build costs, since features are shared modules and each platform is a thin adapter.

We were also badly underpriced at the start, and I'd defend that. Early on, we had a handful of features, so we priced it like a product with a handful of features. As the product grew, we raised prices because the product you buy today is not what we sold in 2024.

People don't believe our expenses. Our infrastructure bill is a $40 VM. It was $27 at launch, and we upgraded it to something stronger; that upgrade represents our entire infrastructure spend history. The only other running costs are Polar's cut of each sale and about $5 a month of OpenAI API usage for the one feature that needs it: we summarize a conversation for context injection at the moment you ask for it, and we don't store it. We deliberately run it on the cheapest nano-tier model. Two people, one droplet, and $45 a month, at 5-figure MRR. We never raised money, so we never had to grow into a burn rate. This means we can make decisions on a ten-year horizon instead of a runway.

Support as a growth channel

We've never had a growth strategy, as such. No ads, no growth hacking, no funnel. I'd love to claim otherwise, but that would be a lie.

Our closest thing to a launch tactic was giving it away. Those three months gained us a community that told us what to build, and nearly everything we shipped in year one resulted from that period.

After that, the Chrome Web Store did most of the work, and we took a while to understand why. The store is a search engine, and it ranks on ratings and installs. This means what grows us isn't marketing at all: it's shipping what people ask for. This makes them stay, rate it well, and helps us rank so more people find us. Google's Featured badge resulted from the same loop and now drives a significant share of our traffic. That's the whole flywheel. When someone emails us a complaint, and we fix it that week, we consider that our growth channel, not just support.

We do have one owned channel: our subreddit, r/chatgpttoolbox, now has 20k members. It's the difference between renting attention and owning it. When we ship a feature, the people who asked for it hear about it the same day, and we don't pay anyone for that privilege.

Beyond that:

• We post where power users already are, mostly Reddit and Facebook groups — and only a value-first approach works. We publish something useful that stands entirely on its own, like a prompt chain you can copy, paste, and get value from in five minutes. The product is an aside at most. Posts that lead with the product simply fail, and they deserve to.

• We built our own community instead of renting one. r/chatgpttoolbox has 20k members. This changes shipping economics: when a feature launches, those who requested it learn about it the same day, without us paying for the privilege.

• We keep our roadmap public, which achieves more than it sounds like: the person who requested a feature sticks around to watch it land, and anyone evaluating us can tell in ten seconds that we're not abandonware.

Uncommon advice

My obvious advice is to ship something small and read your support inbox. Here are a few pieces of advice I don't often hear:

• Build on someone else's platform anyway. Standard advice says not to, because one API change can kill your product. That risk is real. But platform risk is a tax, not a wall. You buy distribution you could never otherwise afford. People find us by searching a store with hundreds of millions of users, and we paid $5 to be in it. Pay the tax. Engineer as if the ground moves, assume every anchor point eventually breaks, and take the distribution.

• Co-found with someone you've already shipped with. Mohammad and I were colleagues at the same startup before this. That sounds sentimental, but it was the biggest risk we eliminated before starting. We already knew how the other one works under pressure, how he argues, how he handles being wrong. Most cofounder breakups aren't strategy disagreements; they're the discovery in month eight that you can't build with this person. We'd already run that experiment on someone else's payroll.

• Be the customer, or get uncomfortably close to one. We never imagined whether anyone wanted this, because we wanted it and felt the problem every day for months. That eliminates your most expensive mistake: building something well that nobody needed.

• Boring infrastructure is leverage, not laziness. We run on one droplet. No Kubernetes, no microservices, no framework in the extension. Forty dollars a month. Every hour you spend making your architecture impressive is an hour not spent on what people actually pay for. No one has churned because our stack was too simple.

• Charge what it's worth now, and raise it later. We were badly underpriced for a long time, and that was correct. We had a handful of features, so we charged like a product with a handful of features. Then we raised prices as the product earned it, and we're still raising them. The mistake isn't starting cheap; it's staying cheap out of fear once you've earned more.

What's next?

From here, more platforms, more features, more people helped. But one idea underlies all three.

Your AI work is scattered. You have conversations in ChatGPT, Claude, Gemini, and Grok; they don't know about each other and never will. Each of those companies races on model quality, and none has reason to build a layer that spans their competitors. That layer is our entire company. We already search across all four at once. AI Toolbox's goal is to be where your AI work lives, whichever model you use that day.

So, concretely: I want to add more LLMs. We are evaluating Copilot and Perplexity next. The economics are the nice part — every platform we add makes the whole product worth more without significantly changing our build costs, because features are shared modules and each platform is a thin adapter.

I also want to add more features, and they will come from their usual sources. I don't have a five-year feature vision, and I'm suspicious of founders who claim one. Our roadmap is public, and most of its content comes from others' ideas.

And, of course, I want more users, because 35,000 is both a lot and nothing. Most people using ChatGPT every day still have hundreds of conversations they'll never find again, and they have no idea a fix exists. That's the whole job.

You can check out the extension, the site, our roadmap, a YouTube playlist demonstrating how it works, or our subreddit.

You can also follow me on LinkedIn and X. Or my cofounder, Mohammad El-Esawi, on LinkedIn and Instagram.