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.
Leave a Comment
5-figure MRR!? Interesting!
I host AIX – Beyond the Prompt, an AI-focused podcast, and I'm starting to feature some early-stage AI founders to help give their products more visibility.
We could have a conversation about what you're building and the story behind it. There's no fee or sponsorship involved!!
If you're interested check the AIX podcast on YouTube or Spotify and/or get in touch.
Interesting approach—leveraging an existing marketplace and user base can be a powerful way to accelerate growth. Reaching five-figure MRR in two years is a great result.
Thanks. One correction worth making, since the distinction matters to anyone copying the playbook: it is not MRR. Most of the revenue is one-time lifetime purchases, so I track trailing 30-day revenue instead. Flattering to be read as recurring, but it would be the wrong number to plan against.
The marketplace part does cut both ways. The distribution is real, but you inherit someone else's interface. A sidebar redesign you had no warning about can break a core feature overnight, so a lot of the engineering goes into surviving other people's releases rather than shipping your own.
It's been stated over and over, but one of the highlights of this process is the recycling of human feedback into the product as an enhancement engine. Most user wishlist/complaint items get lost in the ether because they can feel negative. Looking at them subjectively as improvement suggestions combined with measuring commonality provides real velocity in delivering substantive improvement.
Reframing complaints as suggestions is half of it. The other half, for us, was accepting that frequency is not the only signal worth acting on. Several of our biggest fixes this year came from exactly one person who happened to describe the failure precisely. They never look common until you ship the fix and the quieter reports surface behind it
Really liked the point about turning existing user feedback into a growth channel. It’s easy to focus only on getting new users, but improving the experience for people who already use the product can have a much bigger long-term impact. I’ve seen this with apps like Freecine too—user feedback and ratings can make a noticeable difference in how people discover and trust a product.
Agreed, and the two are less separate than they look. Every fix we ship for someone who already uses the product eventually shows up in a review or a recommendation, which is where the new users come from. The cheapest acquisition we have is a person who wrote in annoyed and got a real answer instead of a template
Love the idea of treating support as a growth channel. Turning user feedback into better ratings, rankings, and organic installs is such a smart flywheel.
Thanks. What surprised us is how often the ticket is the only signal - someone reported their folders had vanished, and it turned out to hit everyone in that state with no metric moving anywhere. The unglamorous half is going back to tell them it shipped
Really strong story — especially validating from unprompted forum complaints instead of surveys.
The “transcribe the sharpest pain → ship only that in two weeks” approach is so clear. And the Chrome Web Store flywheel (support → ratings → ranking → installs) is a great reminder that distribution can be a marketplace, not ads.
Curious: when you moved from free → freemium, what was the free-tier “wall” that converted people most often?
The one that converted best wasn't a feature cap, it was the search result limit. Free gets 5 results. A folder cap hits you while you're setting things up, when it's easy to shrug and move on. The search cap hits while you're actively hunting for something you know you wrote, and the product is telling you it found more but won't show you
Great insights on using existing marketplaces and user communities to build sustainable growth instead of relying on expensive marketing...
Thanks. The part that surprised me most was that marketplace ranking compounds and ads don't. A support reply that turns into a rating keeps working months later. A paid install stops the day you stop paying
Two weeks from problem to launch is wild discipline — most of us spend months polishing before shipping. Curious how you identified which marketplaces actually had the right user overlap vs. ones that just looked promising on paper?
The test I use is whether the marketplace's own search bar already contains the problem. If people are typing "chatgpt folders" into a store search, the intent exists and I just have to be the result. Directories where you're one listing in a grid look promising, but nobody arrives at a directory with a problem in mind. Search volume inside the marketplace beats audience size of the marketplace every time
Copying reward structures from games has been crucial for my app. I feel like no matter what industry you're in this is the way to go. Im in the busi9ness of flight booking. People return to my app because they see how many miles they flew, the plane models they "collected" etc. Not a normal practice for otherwise "professional" flight booking softwares.
Collected plane models is a great one. I think it works because the metric reflects something the user is already quietly proud of. We do streaks and badges, and the ones people screenshot are the ones that say something about them, not about us. Nobody brags about opening an app 30 days in a row, but they will absolutely tell you they've flown 400,000 miles
Great breakdown — especially the “scratch your own itch” + fast validation loop. Curious: in the first 30 days, which channel brought the highest-quality users?
Chrome Web Store search, by a distance. Not the biggest volume, but the highest intent: someone typing "export chatgpt conversations" has the problem right now and installs to solve it that minute. Reddit sent bigger spikes with much worse retention. The rule I took from it is that channels where people arrive with a problem beat channels where you interrupt them with a solution
Great read, Adi! Validating through unprompted complaints on Reddit and OpenAI forums is such a smart move – transcribing user pain points instead of guessing. The choice to keep the stack dead simple (one droplet, vanilla TS) to protect margins is super refreshing
Thanks! The transcribing part matters more than people think - our best landing pages are literally rephrased complaints. And yes, boring infrastructure is a feature: every dollar the stack doesn't eat is margin that survives a slow month
thank you so much.
Thank you for reading!
Impressive execution Adi ! especially the local cross-platform search. That’s a sharp wedge. How did marketplace distribution (Chrome Web Store) compare to content/community for growth, and what moved you from free users to 5-figure MRR first: freemium limits, teams, or a specific pro feature?
Thanks! On distribution: the Chrome Web Store is our compounding channel - store search brings a steady stream of high-intent installs daily, while content/community gives spikes that decay in days. But community is what feeds the store's ranking, so they're not really separable. On revenue: freemium limits on daily-use features did the heavy lifting - people hit the folder and search caps in normal use - and export is the single biggest buy trigger, because it shows up exactly when someone needs their data out and needs it now
Very insightful! Thank you for sharing! I sent you a linkedin request to stay on the loop of what you build next!
Thank you - accepted! More to share soon
great article!
I was just scrolling through Indie Hackers and i spotted Mohammad's cartoon character and i immediately recognized him. I know him from the Arab AI Club with Hasan and i used to participate in their meetings and had a one-to-one conversation with Mohammad one time, and i follow his updates on LinkedIn. what a coincidence.
I am a Computer Science recent graduate from Technion, struggling to find a job in the current market... still practicing for technical interviews. but on the side im trying to build something and sell it, not sure what and how and where to start. this is my second time here on Indie Hackers, reading what others have built, and i always ask myself, how do these people come up with those ideas? i can't find anything repetitive in my daily life that doesn't already have a solution... and my biggest fear is to be an average person like almost everyone i know working 9-5
more about myself: gymrat, very ambitious, sharp, adapting to the AI revolution, self-learning AI tools to become an AI engineer, i use tools like Claude Code, n8n, ElevenLabs, I built an AI voice agent receptionist, never shipped, never shared. just expirementing and not sure how to proceed.
i would love to connect with you Adi
"I am a Computer Science recent graduate from Technion, struggling to find a job in the current market... still practicing for technical interviews. but on the side im trying to build something and sell it, not sure what and how and where to start."
When I hear this I hear the solution at the very same time.
What if you create something, some place, for computer science focused individuals struggling to find a job in the current market and want to build something.
We may not realize what are super power is when it maybe obvious to someone else.
Small world! On the idea question - you're looking in the wrong place, and I say that kindly because everyone starts there. Don't scan your own life for problems; go read other people's complaints in their own words (Reddit, forums, reviews of existing tools). Our product exists because strangers were complaining, not because we were annoyed. And you've already built more than most people who post here - an AI voice receptionist that works is a sellable thing today: pick one local business type, offer it to ten of them, and you'll learn more in two weeks than from a year of practicing interviews. Shipped and imperfect beats experimental and private every time
The "the ground moves" part is the one I'd want a whole separate post on.
Undocumented endpoints and DOM selectors is your entire business risk in one sentence, and the Gemini sidebar story is exactly how it goes wrong — silently, on someone else's deploy schedule.
Do you find out from monitoring or from support emails? Curious whether you run something that hits each platform on a schedule and screams when a selector stops matching, or if the first signal is still a user telling you.
Honest answer: the first signal used to be support emails, and it stung enough that we changed the architecture instead of just adding monitoring. Every UI attachment point now has multiple fallback anchors and where possible we render into panels we own, so a selector rename degrades one feature quietly instead of killing the extension visibly. With 40,000 daily users, the detection gap on anything user-visible is measured in hours - the real work is making sure what breaks, breaks small. A scheduled canary that loads each platform and screams is on our list; a separate post on this would be fun to write
That trade is the interesting part, though. Your 40,000 users were the monitoring — the detection gap is hours precisely because a visibly dead extension generates support email. Degrading one feature quietly is strictly better for the user, but it also opts them out of reporting. Nobody writes in about a button that just isn't there anymore.
Which makes the canary less of a backlog item and more the thing that has to replace the signal you gave up. Might be worth building it to check attachment correctness rather than presence — fallback anchors save you when a selector matches nothing, but not when it matches the wrong container and you quietly render into someone else's div.
Please do write that post. "The fix removed our detection" isn't specific to browser extensions and I haven't seen anyone write it up well.
No pushback on the first part - that's the uncomfortable framing of it: we traded a loud, free detection system for quiet degradation, and now the alarm has to be rebuilt on purpose instead of being emergent. "The users were the monitoring" is going in the post, credited.
The correctness point is real, and we've been bitten by exactly that shape. On Gemini, the first version of one control anchored to a container that existed but was the wrong one - the selector matched, something rendered, everything looked green, and the feature was effectively dead because it never landed where users look. The fix that stuck wasn't a better selector, it was asserting identity instead of presence: we only attach where the platform's own buttons carry the ids we expect (Gemini exposes message/conversation ids in metadata on its native action buttons), and if the anchor can't prove it's a model-response action row, we don't render at all. Refusing to attach beats attaching wrong, because "missing" is at least a state a canary can test for.
So agreed - the canary has to assert invariants ("our control sits in a row that also contains the native copy button"), not non-null selectors. Presence checks would just re-create the same blind spot one level up
Great journey! I really like the focus on solving a real pain point instead of chasing trends. Starting with a simple MVP, listening to user feedback, and growing sustainably without outside funding is inspiring. Wishing you continued success with AI Toolbox and future platform integrations!
Thank you! Sustainable was the only option we could afford, which turned out to be the best product decision we never consciously made
this is a very good fomatand good scene
Thanks, glad it landed!
So incredible.
Thank you!
"We consider that our growth channel, not just support" is exactly the loop I've been living too — every feature that's actually moved the needle for EzWrite came out of someone complaining or asking directly, not from a roadmap I dreamed up. Cheaper than marketing and it compounds the same way.
Exactly - and the compounding is the underrated part. A feature built from a complaint ships with its first advocate already attached: they asked for it, they feel ownership, they tell people. A roadmap feature has to go find its audience
That's a sharp way to put it. Our saved custom tones feature came straight from a Product Hunt comment, and that same person was the first to tell someone else about it — didn't have to convince them from zero, they'd already lived the problem.
Perfect example - and notice the asymmetry: that one Product Hunt comment cost you nothing and produced both a feature and its first evangelist. The support-as-growth loop in one anecdote
So incredible Journey.
Thank you, appreciate you reading!
Great decision
Thanks!
an incredible story.
Thank you!
very nuch so
Great reminder that distribution often matters more than the product itself. Leveraging existing marketplaces and user bases is a smart shortcut to finding traction faster.
Agreed - though we'd soften it slightly: distribution decides whether a good product gets found, but it can't save a product people don't return to. We needed both, in that order
This is an incredible story !
Thank you, that means a lot! Happy to answer anything if you're building something similar.
Building on top of an existing ecosystem can save an enormous amount of distribution work. The downside is that the platform can change the rules at any time. I’d be interested in how they balanced growth with reducing that dependency
Using an existing marketplace is such an underrated distribution strategy. Instead of spending the first year trying to create demand from zero, you’re building where users are already searching for solutions. Of course the tradeoff is becoming dependent on someone else’s ecosystem. I’d love to know how they handled that risk as revenue grew
Well, I think you just found your target customer 😂 I spend an embarrassing amount of time trying to find old AI conversations, and being able to search across different platforms in one place sounds genuinely useful. I’m definitely checking this out. Congrats on what you’ve built!
Validating on Reddit and OpenAI forums before quitting your job is the right kind of boring research.. 35k users is proof it paid off. I’m building Recoup (free read-only Stripe failed-payment audit). For a recurring product like AI Toolbox, I’d be curious whether failed payments ever register as real leakage or stay invisible in the dashboard.
Great read, very insightful and great execution
This was a great read because it highlights how successful products often start by solving a frustrating problem the founders experience themselves. I especially liked the approach of validating demand through Reddit and community forums instead of asking hypothetical questions. The decision to keep search local for privacy and speed, build with a simple architecture, and let customer requests shape the roadmap shows a lot of discipline. The point that really stood out was that no major AI company is likely to build cross-platform search because it goes against their incentives—that's a genuine strategic advantage, not just another feature. One question: as AI platforms continue to evolve, how do you decide whether to keep expanding to more providers or deepen the experience on the platforms you already support?
amazing
THE ONLY LEGITIMATE BITCOIN RECOVERY EXPERT // HIRE WIZARD GEO COORDINATES RECOVERY HACKER
I had the most terrible moments of my life, a few weeks back when I lost all my savings to a self acclaimed bitcoin investment platform which promised me a massive return on my investment. I was so confused about these scammers, I had to do what everyone in my situation would do, I did some research and came across a lot of Testimonials about WIZARD GEO COORDINATES RECOVERY HACKER. I got to reach out to the expert. It took them 48 hours to help me recover my funds. Bitcoin recovery is very much real. I am a living testimony. Hope this helps as many people who have lost their hard earned money to scammers out of trust, you can reach them through the contact below for help to recover your scammed funds.
WhatsApp +1 ( 318 ) 203-3657
Telegram: @Geocoordinateshacker
The "two developers being irritated by something is not a market" line hit hard. I built something recently based purely on my own annoyance, skipped checking if anyone else was actually complaining about it in their own words first. Going back to search Reddit for the exact pain point now before I sink more time into it. Also really appreciate the honesty on being "badly underpriced" early and defending that — feels like most advice says price high from day one, but this makes a real case for the opposite.
This is exactly the takeaway I hoped someone would have. One tip for that Reddit search: look for complaints written by people who tried to solve it themselves (scripts, spreadsheets, workarounds) - effort is a much stronger signal than upvotes. And on pricing: price low enough to get strangers to pay fast, then raise it once they do. The first 100 sales are information, not revenue
Search was the hook that brought people in, but the one we didn't expect was export. We built it as a checkbox feature and it turned into the thing people upgrade for - it turns out "let me back up years of my work" is a deeper need than we guessed.
“That’s an impressive milestone. Leveraging an existing marketplace and user base can be a smart way to accelerate growth, especially when you focus on solving a real problem and building recurring revenue.”
Thank you! Solving a real problem where users already are did most of the heavy lifting for us
thats dope
Appreciate it!
The distinction between loud pain and recurring pain was the part I’ll keep coming back to.
I’m building a small sleep-planning tool, and it is tempting to treat every “I can’t sleep” search or complaint as a feature opportunity. Your bulk-delete example is a useful filter: volume alone is not a business case. I’m now looking for signals of a repeated manual ritual, such as people repeatedly rebuilding routines or tracking the same habit without sticking to it.
When you were still early, what was the first behavior that told you a request was recurring enough to deserve a paid feature rather than just a useful free improvement?
The signal for us was when people asked to raise a limit on something free rather than asking for something new. A feature request is curiosity; "I hit the cap on folders again, can I have more" is a habit already formed. We drew the paid line exactly there - more of what they already used daily, never gating the first taste. Sounds like for your sleep tool, the equivalent might be someone rebuilding the same routine for the third time.
Really enjoyed reading this case study. The part about validating the idea through Reddit and forum complaints instead of asking people what they wanted really stood out to me. It's a good reminder that recurring user frustrations often reveal better opportunities than surveys. Also, keeping the infrastructure simple while focusing on shipping features users actually request seems like a smart approach. Thanks for sharing such a detailed breakdown of the journey.
Thank you! The forums-over-surveys point was the biggest unlock for us - people describe problems accurately when they're complaining and inaccurately when they're being asked
I have so many ideas and problems to address. But my problem is I don't know coding or anything about it. AI is here to help, but only if I knew at least a little about coding; I could leverage AI to build the full‑blown thing I want to make. Unfortunately, I am still handicapped in that regard. So yeah, I wish I had a co‑founder or somebody who's as invested as I am and can solve problems along with me.
Basically, the point of this comment is just getting my frustration out. I really want to build my stuff as well, but I just couldn’t. Although we have all the tools and everything in place, I feel so frustrated when I come across success stories like this. It motivates me, yes, but I also feel a little bit lost. I don’t know anything about architecture. I don’t know anything. In fact, about the architecture, I very lately understood, okay, you know what? Software engineers build something called architecture, which I didn’t know earlier. So I just wish I had a background. I could have built so many things, is what I’m trying to say.
I am on the same boat.
I know the feeling. The good thing is you don't need to master everything before you start. AI and no-code tools can help you build an MVP, and you'll naturally learn the technical concepts as you go. Finding a co-founder is great if it happens, but I wouldn't wait for one before validating an idea.
The line worth framing is "we never raised money, so we never had to grow into a burn rate." I write angel checks for a living, and founders running on $45 a month of infrastructure at 5-figure MRR negotiate from a completely different position than founders whose stack costs more than their churn. The bulk-delete lesson in the comments (loud pain that only hurts once) is also one of the best validation filters I have seen written down anywhere.
That means a lot coming from someone who sees the other side of the table. The negotiating position point is real: we've never had a conversation where we needed the other party to say yes. That freedom cost us some speed early on, but we'd make the same trade again
Really interesting point about recurring pain versus one-time frustration. A complaint can be loud without representing a sustainable business opportunity, while repeated workarounds and ongoing spending are much stronger signals. The part about building only the first painful feature, then letting actual usage shape the roadmap, was the strongest takeaway for me.
Thank you - that's exactly the filter. Loud-but-once pain makes great Reddit threads and terrible businesses. Repeated workarounds are people already paying, just in time instead of money
Really inspiring story—proves that solving a real problem and using existing platforms can lead to big results. The journey from a simple idea to 5-figure MRR is truly motivating
Thank you! The platforms did the hard part - we just stood where the users already were
Great insights on using existing marketplaces and user communities to build sustainable growth instead of relying on expensive marketing. Thanks for sharing such a practical and inspiring startup journey!
Thank you! Practical was the goal - most of what worked for us is boring and repeatable, which is the best kind of advice
Leveraging existing marketplaces is such a smart move—it cuts out 80% of the cold-start friction. Reaching $10k+ MRR in two years using this leverage is a masterclass in distribution!
For those of us building in highly specific offline/hardware-adjacent niches (like my family’s apps for aquarium keepers and plant tissue culture), traditional app marketplaces don't always give that instant bump. We have to "borrow" existing user bases through niche creators and specialized communities instead.
Posts like this are a great reminder that distribution is all about finding where your users ALREADY hang out, rather than trying to build an audience from scratch. Congrats on the milestone! 🚀
Thank you! And honestly, you've already found the right adaptation for your niche - "borrowing" audiences through niche creators and specialized communities is the same principle, just with a different marketplace. A subreddit for aquarium keepers is a marketplace in every way that matters: concentrated intent, existing trust, and searchable history of people describing their problems in their own words.
If anything, I'd guess your niches have an advantage we don't: hobbyists with expensive setups are used to paying for things that protect their investment. The distribution surface is smaller, but the intent is deeper. Would love to hear how the tissue culture app finds its people - that's about as specific as a niche gets.
This is a great example of what actually works:
Start with a real problem (scratch your own itch)
Validate using real user behavior (forums/reviews)
Ship fast and iterate
A lot of founders skip the validation step and jump straight into building.
The interesting part here is not just the idea, but how quickly they moved from insight → execution → revenue.
Also shows that you don’t need a perfect v1 — just something good enough to test if people care.
Curious how they validated willingness to pay early on — that’s usually the hardest signal to get right.
Good question, because you're right that willingness to pay is the signal everyone fudges. We had an unfair shortcut: our competitors were already charging. People were paying monthly for tools with the exact complaints we read in reviews - slow, bloated, unreliable. That's the strongest validation that exists: not "would you pay?" but "you are already paying, and you're unhappy."
So the risky question for us was never "will people pay for this category" - it was "will they pay us instead." We answered that by shipping the free tier first, watching which features got requested over and over, and putting the premium line exactly where the repeated requests were. Conversion showed up within days of adding it.
If there's no paid competitor in your space, that's when it gets genuinely hard - and honestly, sometimes that absence is itself the answer.
Hello, amazing story! I am sure you'd be super happy and proud looking back at your journey and the decision you took to go all in on the idea. One thing that stood out was your point about transcribing complaints instead of inventing features. Looking back, was there any complaint that looked common on Reddit/forums but turned out to be a poor business opportunity once you started building? I'm curious where you draw the line between "loud pain" and "paying market."
Thank you, that means a lot. And yes, there's a clear example: bulk delete.
If you search Reddit for ChatGPT complaints, "let me delete all my chats" is everywhere. Constant, angry, upvoted. We built it early expecting it to convert, and it basically doesn't. The reason took us a while to see: it's a one-time pain. Someone cleans up their history once, feels relief once, and has no reason to pay a subscription for that moment. Loudness measures frustration, not frequency.
The complaints that turned into revenue look different in three ways. First, the pain is recurring: search, folders, and export get hit every working day, not once a quarter. Second, the complainer describes a workaround they're already paying for in time ("I scrolled for ten minutes looking for a chat from March", "I copy-paste important answers into Notion every night"). When someone has built a manual ritual around a problem, they'll pay to delete the ritual. Third, the complaint is tied to work. People whose chats contain client work, code, or research treat their history as an asset. Our best-converting theme by far is export and backup, because it's not a convenience, it's fear of losing work product.
So the line I'd draw for SongTrailer: ignore volume, look for repetition per person and for evidence of a manual workaround. One artist complaining three times that finished songs sit unpromoted is worth more than a hundred upvotes on "cool concept".
Comment:
This is the sharpest question we get, and the honest answer is: it already is four separate dependencies to maintain. That's not a future state, it's Tuesday. Google changed Gemini's watermarking twice this year, OpenAI reshuffles the ChatGPT sidebar regularly, and Grok is really two products wearing one name (inside X and grok.com). We pay that tax continuously.
What made it manageable is architecture, not optimism. Around 80 percent of the code is a shared core (search, folders, export, sync, prompt tools), and each platform is a thin adapter on top. When a platform changes its UI, the blast radius is the adapter, not the product. We also stopped anchoring to their DOM wherever possible: our UI lives in panels we own, with multiple fallback attachment points, so a redesign degrades gracefully instead of breaking cold.
Where I'd say coverage stops being protection: it never protected us from maintenance, it protects revenue. The four platforms fail independently. A bad week on one is a patch release; it's no longer an existential event, which it genuinely was when we were ChatGPT-only. The risk that actually keeps me up isn't UI churn, it's an access-model change, a platform deciding extensions shouldn't touch it at all. Our mitigation there is owning the customer relationship directly (our own site, our own billing, support by email with real humans) and keeping user data local, so we're not dependent on any platform's API goodwill to deliver the core value.
And you're reading the complaints-vs-requests distinction exactly right for SongTrailer. Praise is people being nice. Repetition is people being in pain.
That distinction between outage risk and existential risk is the key takeaway. Thin adapters and a shared core make platform changes manageable, but owning the customer relationship is what stops the entire business from being rented from someone else.
And “repetition is people being in pain” is the sharper validation filter. For SongTrailer, the signal is not artists saying cinematic visuals sound cool; it is repeatedly hearing, “the track is finished, but I have nothing strong to promote it with.” That is where urgency and budget actually appear.
Exactly - "rented from someone else" is the phrase I'll be borrowing now. The platforms can change our maintenance costs; only losing the customer relationship could change what the business is.
And yes, you've got the filter right for SongTrailer. One last suggestion from our experience: when you hear that exact sentence - "the track is finished, but I have nothing strong to promote it with" - don't just log it, ask that artist what they last paid to solve it (a video editor, a Fiverr gig, a template tool). If they've spent money on a bad workaround, they're your first customers, and the price they paid is your pricing research. Complaints plus a spending history is the strongest signal there is.
Good luck with SongTrailer - ship it in front of those artists early. I'll keep an eye out for your launch.
Thanks James for the great questions - this was fun to write.
One thing that didn't make it into the piece: the scariest moment wasn't the launch, it was raising prices for the first time. We were convinced churn would spike. It didn't - almost nobody who was getting value left over a few dollars. If you're underpricing out of fear, that fear is probably more expensive than the discount.
Happy to answer anything about the numbers, the stack, or building on top of platforms that owe you nothing.
The Reddit validation approach is especially interesting — instead of asking users what they want, they looked at what people were already frustrated enough to complain about.
I'm also building small tools, and this reinforced the idea that the first version should solve one painful problem extremely well, then let users shape the roadmap.
Great reminder that distribution and listening to users are often more important than building a technically impressive product.
Thanks - you got the core of it exactly. One nuance that took us a while to learn: complaints are a better signal than requests because they're costly. Nobody writes a forum post about a mild inconvenience, so a complaint is pre-validated pain. When we later added a public roadmap, we kept the same rule: feature requests get weighed by how often the same pain shows up unprompted, not by how loudly one person asks.
And yes on "one painful problem extremely well" - our v1 was literally just search. The trap we avoided (barely) was polishing v1 features nobody had complained about yet.
What are you building? Curious whether your niche has a forum culture you can mine the same way.
This case study is a masterclass in execution for indie hackers. It perfectly illustrates how to turn product fragility into a moat while keeping overhead virtually at zero.
Here is a constructive breakdown of what makes their strategy brilliant, where the hidden risks lie, and what other builders can take away from it:
The Brilliant 💡
The Unfair Moat (Cross-Platform Local Search): Building a search index that runs locally in
IndexedDBis their best product and business decision. By keeping the data on the user's device, they solved the massive trust barrier of handling sensitive AI conversations, eliminated server costs, and built a cross-platform feature (searching ChatGPT, Claude, Gemini, and Grok at once) that the tech giants will likely never build themselves.True Validation Over Sentiment: Instead of asking friends if they would buy the tool, they tracked unprompted, high-intent complaints on Reddit and OpenAI forums. Building features by "transcribing" actual user pain points eliminated guesswork and guaranteed immediate product-market fit.
Zero-Framework Discipline: Choosing plain TypeScript and a Shadow DOM instead of React or Vue shows incredible engineering maturity. Content scripts are guests on someone else's webpage; keeping the bundle size microscopic and isolated prevents style bleeding and keeps the host page fast.
The Risky ⚠️
Extreme Platform Dependency ("The Moving Ground"): Operating on undocumented endpoints and scraping the DOM means OpenAI or Google could unintentionally (or intentionally) break AI Toolbox with a single CSS class rename. The Gemini sidebar incident proves that a minor design tweak can cause a critical user-facing bug.
The Quitting Trap: While quitting their jobs immediately worked for Adi and Mohammad due to their 12 years of combined experience, this is generally dangerous advice for most indie hackers. They had a highly specific, execution-heavy idea; for most, validating via a side project before quitting is safer.
The Takeaway 🛠️
Ruthless MVP Scope: A $32 budget and a two-week timeline to ship only search—ignoring folders, export, and prompts—is how you launch. Don't build the 35-feature version until users beg for the second feature.
Boring Backends Win: A single Ubuntu droplet with Node, Express, MongoDB, and Redis running on the same box is secure, fast, and incredibly cheap to maintain. Don't over-engineer for scale until you actually have the traffic to break a basic server.
This is a better summary of our strategy than we could write ourselves. Two honest notes: on platform dependency, you're right that it's our biggest risk, and it's why we now treat resilience as a feature in itself - multiple fallback anchors for every UI attachment point, self-owned panels where possible, and fixes shipped within hours when a platform redesigns. It never stops being a tax; we've just gotten fast at paying it. And fully agreed on the quitting trap - we had 12 years of shipping behind us and still call it the riskiest thing we did. Validate first, quit second is the right order for almost everyone
The "uncommon advice" section is the part most people will skim and shouldn't. The move from "a guy with a Stripe account" to a real company with real banking is invisible from the outside but it changes how customers, partners, and payment providers treat you — you stop being a flight risk to them. Same reason your marketplace launch worked: existing trust you didn't have to build from zero.
The point about charging early to filter for intent is the one I'd underline twice. A free user tells you nothing; the first dollar tells you whether the demand is real. It's the same signal at the business level — the moment money has to move through a proper structure, you find out fast which parts of your setup were held together with tape.
Curious what forced the structure decision for you — did it come before the revenue, or did hitting 5-figure MRR make the old setup start to creak?
Revenue came first, structure followed fast - and you're right about the creak. The tipping point wasn't a milestone number, it was the moment real money moving monthly turned "a guy with a Stripe account" into a liability: payment providers, taxes, and customer trust all started asking questions the tape couldn't answer. In hindsight we'd formalize a little earlier than felt necessary; it's much cheaper to build the structure before you need it than while you need it.
Great breakdown, and the part most readers will skim past is worth stopping on: this whole business is built on top of someone else's platform. AI Toolbox exists because ChatGPT doesn't let you organize your own chats. That's the wedge, and also the single biggest strategic tension in the story, so worth naming for anyone reading this thinking of building something similar.
Building on a platform gap is the fastest possible distribution: you inherit ChatGPT's entire user base, and the pain is pre-validated because millions already feel it. That's how you hit 35k users and 5-figure MRR in under two years with no marketing budget. The platform IS the marketing. But the same dependency is the risk that never sleeps. The day OpenAI ships native folders and search, and they will, the core feature is commoditized overnight. Every "fill the gap in a big platform" business is racing the platform's own roadmap.
What separates the ones who survive from the ones who get absorbed: use the platform-gap wedge to acquire users cheap, then build value the platform won't replicate. Cross-model support is the obvious one (organize across ChatGPT AND Claude AND Gemini), because no single provider will ever help you leave their walled garden. That neutrality is defensible in a way "better folders" isn't. Winners migrate from "we fix ChatGPT's gap" to "we're the neutral layer across all your AI tools" before the gap closes.
The pattern worth internalizing if you're building on any big platform: the gap gets you in the door, but the moat has to be something the platform is structurally unable or unwilling to build itself. Structural, not just currently-missing. That distinction is the whole game.
For anyone building in this space, that platform-dependency-to-neutral-layer path is the kind of positioning problem I spend my time on, part of the team building Hivemind, an AI strategy copilot. Adi, genuinely impressive execution.
This is exactly the map we're navigating by, well put. The neutral-layer migration isn't hypothetical for us - it's done: we're on ChatGPT, Claude, Gemini, and Grok today, and cross-platform search across all four in one place is the feature no single provider will ever build, for exactly the walled-garden reason you name. Worth adding from the inside: the platforms shipping native versions of our features has already happened several times, and each time it hurt less than we feared - native is built for the median user, and the people who pay us are the power users the median feature underserves. The gap closes slower than the roadmap threat suggests, but we're not betting the company on that. Thanks for the kind words on execution
"Native is built for the median user, and the people who pay us are the power users the median feature underserves" is the sharpest thing in this whole thread, and it's a better moat than cross-platform alone. Worth pulling out because it generalizes to anyone building on a platform: the gap the platform eventually fills isn't the gap you actually monetize. They ship the 80% version for everyone, which quietly re-segments your market for you, the casual users you'd have lost anyway leave, and what remains is the dense core of power users whose needs scale past what any median feature will ever justify. The platform shipping your feature can actually concentrate your paying base rather than destroy it.
Which reframes the "racing the roadmap" fear I led with. It's not a race to stay ahead of native, it's a race to climb the depth curve faster than native rises. Native sets a rising floor. Survival is about always being enough above that floor that the people who feel the difference are the ones with wallets. Cross-platform is one axis of that depth, but the game-design retention work you mentioned is another, and arguably deeper, because habit and ownership are things the platform won't build for a feature they consider peripheral.
The part I'd watch, as a genuine question not a gotcha: cross-platform neutrality is defensible against any single provider, but copyable by another third party doing what you do. The walled-garden logic protects you from OpenAI, not from the next AI Toolbox. So the durable moat might end up being the 20k-member community and the same-day-shipping loop more than the cross-platform feature itself, because those compound and a competitor can't fork your relationship with your users.
For anyone else reading this and building on a platform, this depth-curve-and-moat stuff is exactly what I spend my time on, part of the team building Hivemind, an AI strategy copilot: https://hivemind.myosin.xyz. Adi, genuinely one of the clearest founder breakdowns I've read here.
You've said the quiet part better than I did: the copyable thing is the feature list, and the uncopyable thing is the loop that produces it. A competitor can fork our functionality in a quarter - what they can't fork is thousands of support conversations telling us what to build next, or the trust that makes users report bugs instead of churning. That stream is the actual product engine, features are its output.
One more compounding layer you didn't mention: data gravity. Years of folders, tags, and organized history live inside our structure. Even a perfect clone starts every user at zero, and "re-organize everything again" is a price power users won't pay twice. So I'd rank the moat: relationship loop, then accumulated structure, then depth, and cross-platform last - it's the wedge, not the wall.
Genuinely one of the best comments this thread has produced - thanks for thinking this hard about it
I mean as a growth marketer who has worked for several companies over the years, I had to actually tell you that most of the time, as a growth marketer, you build a go‑to‑market plan and growth strategies. With startups, especially, founders interfere and disrupt it. They want their version of marketing to be followed, along with some bits of what we have brought into those stores.
But for a product like yours, you did the right thing from the start: no advertisement, nothing. You launched the product free for everyone, then turned it into freemium. Most companies I have worked with are not open to demos or to inviting people who have high intent. They have mentioned their intent on other platforms—no cold emailing and no reach‑outs. They have a very different approach, and we always lose three to six months following the founder’s strategy. When we pivot back to our marketing strategy, we have wasted three to six months and burned money.
So, when I read your post, I was astonished at how great we have done as programmers and coders. You built a beautiful marketing strategy without trying to. You found the problem, launched the product, kept it free, then made it freemium. That’s how product evolution should be: first gather the audience, then… I was so happy reading this that I had to comment here.
This made our day, thank you. Honest confession though: what looks like strategy was mostly constraints. No budget for ads, no audience, no room to guess - so we went where users already were and built what they were already complaining about. We were too broke to ignore our users, and that turned out to be the best marketing discipline there is
As a teacher with TutorXcel, I see something very similar in education every day. Students don't improve because we give them hundreds of resources at once, they improve when we identify one problem, solve it, and then move to the next challenge. Reading your journey reminded me of that. I also liked that you paid attention to what people were actually struggling with instead of assuming what they needed. That's a lesson many educators and founders can learn from. Whether it's building a learning platform or a software product, real progress comes from listening, making small improvements consistently, and never losing sight of the people you're trying to help. Thanks for sharing your story, it was worth the read.
Thank you, this is a lovely parallel - and I think it runs deeper than analogy. A feature request is basically a student telling you where they're stuck, and the temptation in both worlds is the same: to respond with everything you know instead of the one thing they need next.
The hardest discipline for us has been the second half of what you described: solving one problem, then moving to the next.
This comment was deleted 22 days ago