A month ago I wrote a defence of building Daccord’s client on a game engine. I stand by every word of it. I’m also rebuilding the client in Flutter.
Both of those are true at once, and the reason is worth writing down — because this isn’t a story about Godot falling short. It’s a story about an app whose shape stopped matching the tool.
This isn’t Godot’s fault
Let me say the nice things first, and mean them. Godot has a genuinely powerful UI engine. It’s very performant — it performs the way an application should, not the way you’d fear a game engine would. There are real knobs for bringing the frame rate down when nothing’s moving and for not drawing what doesn’t need drawing, so it sits idle without cooking a laptop. It’s a fantastic platform for both game and app development, and I still love working in it.
So the pivot is purely about the type of app Daccord is, and how deeply it lives on the web. None of what follows is a defect I found. It’s a mismatch I should have weighed more heavily.
The web keeps leaking in
Daccord is a chat app, and chat in 2026 is web-shaped whether you like it or not. Take rich link previews — paste a URL, and the app should reach out, pull back the parts the site wants shown, and render them the way the site intends. That’s table stakes for a chat client. In Godot it’s a nightmare of manual HTTP, HTML parsing, and image fetching that I’d be maintaining forever. In Flutter it’s close to out of the box.
Then there’s voice and video. The previous post made a point of “the engine already has the pipeline” — and it does, but in practice I’d built a pile of custom integration around LiveKit, especially for screen recording. Flutter ships libwebrtc built in. All of that bespoke glue simply goes away. That’s not a marginal saving; that’s an entire subsystem I no longer own.
Mobile was the dealbreaker
The thing that actually tipped it was mobile.
Godot’s UI feature set for phones is thin. Responsive layout is very manual — you’re hand-building the behaviour that an app framework gives you for free. Getting a genuinely functional client across the range of mobile platforms and screen sizes would have been a large, ongoing chunk of work to solve a problem that Flutter and its UI libraries already consider solved.
For a one-person project, that math matters more than anything else. I have a lot of life outside this, and not much time to spend on it. I’d rather spend that time on Daccord, not on re-deriving responsive layout.
Why Flutter specifically
Flutter is only about UI, and that narrowness is the point.
There’s a large community pointed squarely at app and UI work,
and a deep pool of free, liberally licensed libraries I can
actually pull in. After a year of building my own components on a
game engine, “someone has already written this and I can pub add it” is a quietly enormous relief.
That cuts the other way from the previous post’s argument, and that’s fine. “Build your own component library” is a fair trade when the alternative is a 200MB Electron binary. It’s a worse trade when there’s a mature, free ecosystem already aimed at exactly the app you’re making.
What this means if you’re using it
This is a hard new version, deployed fresh on GitHub. There’s no clever in-place migration and I’m not going to pretend there is. Only a handful of people have tried Daccord so far, so reinstalling isn’t a big ask — and it’s a far smaller ask now than dragging a compatibility story along for years would be.
daccord.gg is still the home page. The shape of the app isn’t changing. The foundation under it is — and for this app, on this timeline, with this one pair of hands, that’s the right call.