Groupchats.ai Post-mortem

Groupchats.ai was a project I launched in August of 2025. I allowed my ownership of the domain to expire in November of 2026. In between, two customers purchased a combined total of two months of membership. In other words, it was a complete flop.

Here's how it went and what I learned.

Background

In mid-2024 I got curious about groupchatting with ChatGPT and Claude at the same time. Rather than just giving both models an identical prompt, what would happen if they could actually see and respond to each other? For example, I could ask ChatGPT how to write a function in Python, but then give Claude an opportunity to tweak the function ChatGPT wrote.

I wrote a small script which included both models in the same conversation via their respective APIs. The results were exciting! The models were "conversing" with each other by name, and building upon and critiquing each others' response. I even moderated some mock debates between them.

I looked around for products that facilitated these kinds of LLM groupchats and found none. I could smell opportunity: a product that definitely needed to exist (I wanted to use it, which meant people like me would also want to use it), yet it was nowhere to be found. I purchased a juicy .ai domain and got to work.

The shipped product

These are AI-generated demo conversations

Groupchats.ai worked by using user-provided API keys (stored only in secure browser storage and never transferred to anyone but their respective providers) to connect to each LLM providers' APIs. It supported Anthropic/Claude, ChatGPT, and Google Gemini.

This is also fake conversation content

Users could create "personas" (a model, a name, and an optional custom system prompt, e.g. "You are an expert software engineer"), and organize personas into "channels" (a collection of personas and conversations).

Conversations in a channel automatically included the personas assigned to that channel, who would take turns responding to each user message upon receiving a log of the entire conversation up to that point. At launch, personas always responded in a random order to each user prompt. Shortly after launch, I added a "tagging" feature where you could preface a message like "@ChatGPT @Claude how do I blah blah?" which would prompt only ChatGPT and Claude to respond, and in that order.

What I got right

Free to try with no commitment

The core interaction--groupchatting with multiple LLMs at once--was free to use with no signup or credit card required. People could optionally choose pay to unlock extra functionality, but the site did what it said "on the tin," with no commitment. I learned this from my other project, SlowedAndReverb.Studio, which is meaningfully profitable. While only a little over 1,300 people actually added their API keys, I have no doubt that number would've been significantly smaller had I asked for an email address first (not to mention I would've had to set up user accounts; see the next section!)

Skipped some expensive features

The product I shipped was much smaller than what I imagined the project could've been. I try to stay very aware that some of the projects I launch will not be successful. Pieter Levels of Remote OK and Nomads.com (formerly Nomad List) fame has talked openly about how most of the projects he launches are not successful enough to justify supporting.

I intentionally built a simpler, smaller version of Groupchats.ai that still provided value, so I could validate the idea without wasting time adding bells and whistles to something no one actually wants to use. Unfortunately, I still ended up doing a ton of work that wasn't necessary for launch, which I'll talk about later. That said, there are features I deliberately excluded from the launch version which I'm now extremely happy to have not spent time on:

• No API keys required: Obviously, most users don't know what API keys are, let alone have them at the ready or even know how to get them. However, by requiring users to use their own API keys, I didn't have to add support for user accounts, build some method for purchasing and tracking usage tokens, or run a proxy service for the APIs (which was also good for privacy since I had no way to intercept messages!). This reduced the amount of work needed to get to launch by at least an order of magnitude. I was also inspired by TypingMind, a wildly successful product (according to its creator, Tony Dinh) that, as of October 2026, still requires users to provide API keys.

  Had Groupchats.ai been successful, I planned to add support for using it without your own API keys. By launching without that feature and failing to even acquire users who have their own API keys, I saved so much time--which would've ultimately been a waste--without losing the ability to validate the project within a subset of the potential customer base.

• Custom providers: Even more niche than people with API keys are those who host their own model providers with tools like Ollama. I would've loved to support these eventually, but it was an easy choice to wait to build it until someone asked.

• Response ordering control: I was originally planning to enable users to choose whether a channel's personas responded in a random order or a preconfigured order. Then I realized it would be simpler to just have them respond in a random order every time. While using the app, I found myself wishing I could tag specific personas to control the order a little better and occasionally get responses from specific personas only, so I did add a "tagging" feature shortly after launch but mostly for my own use.

Cross-project traffic

My more successful project, SlowedAndReverb.Studio, enjoys a good deal of daily traffic. While I'm a little skeptical of how much overlap there is in the two potential groups of users, I came up with a non-intrusive way to tell my existing SlowedAndReverb.Studio users about Groupchats.ai. I had hundreds of daily visits to Groupchats.ai right from launch day until I stopped "advertising" it on SlowedAndReverb.Studio several months later, and I didn't get any complaints from SlowedAndReverb.Studio users.

What I got wrong

Skipped a crucial feature

In my efforts to ship something smaller and simpler, I didn't bother to support streamed responses from the APIs. Streamed responses enable you to read whatever has been generated so far while the rest of the response is generated. This is much faster than waiting for the entire response to be generated, since you can start reading the text that's ready and the rest is filled in while you read.

After prompting a model in Groupchats.ai, the only feedback you receive is "ChatGPT is thinking..." until the entire response is complete. This might not seem like a big deal, but the wait became pretty annoying, especially after "thinking tokens" were introduced which increased response duration. I found this discouraged me from using my own product, so I have no doubt any users were even more irritated. The only saving grace was that once the first model responded you could read that while the next response was generated.

It wouldn't have been much effort to support streamed responses, but by the time I was really considering it, I felt it would be too little, too late.

Mistook novelty for value

My little proof of concept script was really fun, and I felt confident that if I built something I wanted to use, others would want to use it too. However, just a few months after launch, my own usage dropped significantly. While the lack of streamed responses didn't help, there just wasn't enough value in groupchatting with models to justify it over the free web UIs direct from the providers.

As I built the site, I imagined what would happen if OpenWebUI added a groupchat feature (which they did) or when Slack inevitably supported talking to Claude and ChatGPT in the same thread (which I also think you can do). I should've recognized that groupchatting with LLMs was really more of a feature for other chat apps than a whole product. That said, I still feel the best way to validate ideas is to put them out and seeing what sticks, which is why it's more important to avoid scope creep...

Scope creep

Even though I knew there was a good chance the project wouldn't succeed, and I told myself I was building "the smallest possible thing someone might actually pay for" to validate the idea, I went way, way overboard. "What about creating your own personas to chat with?" turned into, "It needs channels to organize personas," turned into, "Let's clone Slack's UI," and before I knew it, I was several more months deep into the project than I'd intended, and I launched nearly a year after purchasing the domain.

My original proof of concept script was so simple--a way to chat with ChatGPT and Claude at the same time. The simplest, valuable, productized version of it would be a site where you just add your API keys and get put into a chatroom with ChatGPT, Claude, and Gemini. That would've allowed me to validate the idea in much less time.

This is my biggest learning from the project: I could've built a much simpler site, much faster, and reached the same conclusion--"No one wants this"--in probably a tenth of the time. Had the project managed to find an audience, a simpler version would've been easier to understand and use, and actual users could've told me what to build next.

Looking forward

Feeling like I wasted a bunch of time is a bummer. That said, I really value the lesson I learned, even if I learned it the hard way, because now I'll never forget it: launch the smallest, simplest, viable version of the idea, with the least time commitment possible. Be pleasantly surprised if it works, and go from there. Otherwise, be glad to have more time for the next attempt.

I also appreciate this process just for the raw experience designing, building, and shipping software. The more I design and code, the better I get at it, and this project looked and felt like a step up compared to the ones I made before it.

Income vs expense breakdown