The second link in the body of OP is the dev explaining that he’d been working on it in his spare time for 5 years before releasing it as a public beta on Github.

He does mention using AI in a limited capacity.

Fluxer was largely built before LLMs became a normal part of day-to-day development. I do use them now, but in a limited way: as a rubber duck and for mechanical implementation work when I already have a detailed spec. I treat the code it outputs like I would any external contribution.

No LLM designed the system, wrote the specs, or made architectural decisions. That was all me. I only use LLMs when I already know the platform well enough to review the result properly.

Ultimately, you’ll have to take my word for it that I’m trying to handle this responsibly. Fluxer is a large, complicated codebase because the project itself is large and complicated. LLMs still aren’t capable of autonomously producing anything like what Fluxer is today.

If it were that easy to create something this polished on a whim using only LLMs, we’d already be swimming in credible Discord alternatives.

In short, for Fluxer: PRs should be reviewable, understandable, and test-backed. Submitting generated code you cannot explain, or using an LLM to bypass review standards, isn’t acceptable. At the same time, responsible use of LLMs as a tool is fine, and contributors should not be harassed for using them.

Moreover, the OSS release began from a clean slate, so the public commit count doesn’t reflect the full private iteration timeline, how long it has been deployed in production, or how extensively it has been tested. Going forward, what matters is that contributions will be reviewed, and tests will be required where appropriate. I also don’t condone low-effort, unreviewed AI slop.

I published the project with a squashed history because the early work happened privately, and I didn’t want to make 3,000+ messy commits part of the public record. I’m proud of where things are now, and the codebase has improved a lot over the 3+ years it was developed in private. Squashing commits during a closed source to open source transition is common practice, and it doesn’t imply the project was vibe-coded.

This is my work, and it’s hard-earned. If something seems too good to be true, it’s because I’ve put real effort into making it good.

I get that in the age of LLMs, people are more suspicious and may assume bad intent behind every project. But some projects come from true passion and domain understanding. That’s the case for Fluxer.

I could’ve built and maintained this platform without using LLMs for the mechanical parts of the work. It just would’ve taken about three times as long. At that pace, I’d need a full-time job to make a living, and then I wouldn’t have time for Fluxer anyway. This is the world we live in, and sometimes compromises are unavoidable.

Starting with no money, the realistic options were to raise VC funding (since most people won’t back a project like this until it’s already close to what they expect), or to use LLMs in a limited, controlled way to speed up the mechanical tasks. I chose the latter so the project could stay independent.

If you feel conflicted about this, know that I do too. I’m happier writing code by hand. Going forward, LLMs don’t need to be quite as involved. Now that I’ve released publicly, I don’t necessarily need to work on this alone, and I’ve prepared the codebase to make it attractive to people who want to self-host the software.

According to the blog:

What I’m about to introduce is a brand new OSS community chat app I’ve worked on solo, on and off, for the past 5 years. I believe it’s one of the closest public attempts at feature parity with platforms like Discord or Slack to date.

Without checking it, it’s likely that the first commit had already years of work.