What happened
This is what AI app development without writing a single line of code looks like when it actually works. On Friday, September 25, at 22:35, a developer sent one prompt: a wall of text with no commas, everything jumbled together. He wanted a working product like Discord, but with chats built the way Telegram does them — because the way Discord does them drives him nuts — plus voice and stability like Zoom with modern codecs, voice rooms, roles and permissions, screen sharing, PostgreSQL, and one demand standing on its own line: "there should be absolutely no echo."
By the following evening, version 0.3.1 was live in production: signed builds for macOS, Windows and Linux, a web version, and a landing page. He sent 90 messages. Twenty-nine of them were screenshots captioned "make it look like this." He wrote zero lines of code and ran zero tests himself. The models handled the rest. The product is called Calab, and the code lives on GitHub.
What's actually inside Calab
It's a self-hosted messenger for teams. Voice rooms work the way walking into a room does — you join and hear your colleagues. The Opus codec with DTX means silence sends no packets at all: traffic falls to 0.1 kbit/s, and speech runs 30–45 kbit/s. Noise suppression comes from RNNoise, a neural network that runs on your own device, and echo cancellation comes from AEC3 in the WebRTC stack.
Screen sharing uses AV1 with simulcast. In plain English: the sender encodes the picture in several quality tiers, and each viewer gets the tier they can actually see. Any tier nobody is watching never gets encoded at all. Text stays sharp, and a code file or document floats along at 20–300 kbit/s. Up to three streams per room, with an SFU running on LiveKit. Think of a dispatcher at a busy station: they don't mash every stream into one soup, they hand each person exactly what they need.
It also survives corporate networks. If UDP gets blocked, the connection drops to TCP, then to TURN/TLS on port 443 — so from the outside it looks like ordinary HTTPS traffic. One public IP, and it was tested from behind a VPN.
A chat you'd actually want to use
The chat side is modeled on Telegram: bubbles, reactions, pins, mentions, link previews, and search that understands word forms. Guests join through a link without registering. The server is written in Go, the desktop clients run on Electron, and there's a web and mobile web version too, in four languages. The server image weighs about 20 MB and sits at roughly 40 MB of RAM while idle.
The numbers behind the build
This is where it stops sounding like a weekend toy. The project ended up with 92,972 lines of source code: 28,471 in Go, 60,871 in TypeScript, and the rest split across proto, SQL and CSS. There were 282 commits on main, 31 of them merges from agent branches, and 7 releases from v0.1.0 to v0.3.2.
Testing wasn't skipped either: 60 Go test files running against real Postgres, Valkey and LiveKit, 92 client unit tests covering 750+ cases, 13 end-to-end specs, and visual baselines. Documentation ran to 37 documents and 22 ADRs — short notes that record what was decided and why — plus a TESTING.md with roughly 150 manual scenarios. Localization reached 1,186 keys across four languages.
The night the human went on "vacation"
For the first hour, the lead agent — Fable 5.1 — read up on codecs, TURN and echo, then produced 11 architecture documents and the first ADRs. The human stepped in exactly twice. First: "that bitrate bothers me." A worst-case figure of 435 Mbps for the SFU got rewritten into ceilings measured against typical traffic. Second: "backend in Go, as light as possible."
Around midnight, an hour and a half after the prompt, there was an MVP that wasn't just a skeleton: two clients called each other through the SFU and showed each other their screens. The two of them checked it together, and the call worked. Everything after that went into "make it a product" rather than "make it run."
What it means for you
The takeaway isn't that a mystery genius built Discord overnight. It's that the gap between "I have an idea" and "here's a working thing" just got a lot shorter, and you don't have to be the one typing. You describe what you want, the same way you'd brief a contractor, and you keep correcting it with screenshots and plain sentences.
At home
Say your family keeps losing track of who's driving whom where, or your friend group is scattered across three apps. Instead of paying for another subscription, you could run a small private server that only your people can reach — voice rooms included — and know exactly where your data sits.
At work
Small teams usually end up in whatever chat tool the company bought. If your team needs one specific thing — a channel that only opens during on-call hours, or a search that actually finds old decisions — you can build that instead of filing a ticket and waiting three quarters.
For a small business
Think about a clinic, a repair shop or a tutoring studio. Their real problem isn't chat, it's a conversation that needs to sit somewhere safe and stay private. A self-hosted setup means client conversations stay on hardware you control, which is a much easier answer when someone asks where the data lives.
For studying
If you're learning to code, this is the single most useful shift in years. You can ask for a working example, read it, break it, and ask why it broke. The architecture docs and ADRs alone are a free course in how real software decisions get made.
For creative projects
Writers, podcasters and small studios can spin up a private space for collaborators without wrestling with permission settings on someone else's platform. If you're stuck on how to phrase your request, the free AI tools at MyKreaTool can hand you a starting structure in seconds.
As a way to earn
Agencies already charge for exactly this: taking a messy idea and shipping a working tool. The difference now is that one person with good taste and clear instructions can deliver what used to take a small team.
How to try it right now
You don't need to build Discord. Pick something small and follow the same path.
1. Start with Fable 5.1, the coding agent behind Calab. Pick the plan that fits your budget — you'll know within an hour whether this way of working suits you.
2. Write your first prompt as one long brain dump. Don't structure it. List everything you want, even contradictory things, and include the things that annoy you about existing tools. That's exactly what the Calab prompt did.
3. Send screenshots instead of descriptions. Nearly a third of the messages in this project were images with the caption "make it look like this."
4. Ask for architecture docs and ADRs early. They're what keeps a fast build from turning into a mess three days in.
5. Intervene on big decisions only. Two corrections were enough here — one about bitrate, one about the backend language.
6. Test at the end, not instead of testing. Ask the agent to write the tests: this build finished with 60 Go test files, 13 end-to-end specs and a TESTING.md with roughly 150 manual scenarios.
7. Self-host Calab if you want the real thing. The code is on GitHub, and it's small enough to run comfortably on a modest server.
Upsides and what changes
Speed is the obvious one: a day instead of a quarter. But the quieter win is that the experiment becomes cheap. A prototype you'd never have funded is now something you can just... try. Self-hosting means no per-seat math, a 20 MB image, and around 40 MB of RAM at idle — the kind of footprint that runs on almost anything. And the artifacts that come out of it, the docs and ADRs, are things most human teams skip under deadline pressure.
So is SaaS dead? Not really. But the assumption that you have to rent everything, forever, because building is too hard, is losing its grip.
Limitations
The author says it himself: without the list of mistakes, the story looks too good, and he wouldn't believe it either. That's the honest part. A model that just read about codecs, TURN servers and echo cancellation will happily produce an architecture that looks right, and the 435 Mbps figure only got caught because a human was paying attention. He wrote no code and ran no tests himself, which means he was trusting a pipeline he hadn't personally verified. Running a self-hosted messenger means you own the uptime, the updates and the security, not a vendor. And "works for a small team" is a very different claim from "works at Discord scale."
Conclusion
A working messenger, with voice rooms, screen sharing and tests, went from a messy paragraph to version 0.3.1 in about 24 hours. Do one thing today: open Fable 5.1, write a single unstructured paragraph describing the small tool you keep wishing existed, and send it.
Comments 0