Why KALYIX is being rebuilt
KALYIX is not stopping at the first app. V1 was a sensible starting point, but the current approach is no longer enough for the next step. That is why V2 is being built as a new app with its own shell, a new core, and a cleaner split between editor, runtime, and output.
Starting point
V1 was not a false start
The first KALYIX version proved what the product can fundamentally be: a local tool for overlays, alerts, preview, and streaming-adjacent workflows. For that stage, the Tauri and HTML-based route made complete sense.
The issue is not that V1 was bad. The issue is that V1 becomes too tight for the next step once editor, runtime, output, and long-term extensibility need to work together cleanly.
Why the rebuild is necessary
The current path hits real product limits
I could keep working around those limits. That is exactly what I do not want to do. V2 should not be built out of more and more bridges. It should sit on a cleaner foundation.
- fast product start with a working interface
- a tangible entry point for overlay and OBS-adjacent workflows
- a usable base to validate features and direction early
- too much coupling to HTML and webview logic in the hot path
- more detours between UI, runtime, and later output
- harder to modularize cleanly without building more special-case paths
Why V1 ends technically
This break is not a gut feeling. It is an architecture decision.
V1 does not end because the current build is worthless. V1 ends because the core path stays too tightly bound to HTML, webview, and OBS-adjacent flows. Every major feature after this would lock that coupling in even further.
- UI, HTML, and webview sit too close to the actual hot path
- editor logic, presentation, and runtime are tied together too tightly
- OBS-adjacent paths force architectural choices into the core too early
- new features quickly create more bridges and one-off paths
- every new core building block would harden those couplings even more
- a clean editor core is harder to keep stable this way
- more webview workarounds would be possible, but they are not the right base
- a clear rebuild makes more sense than endless patchwork around the wrong center
What the product is aiming for
V2 should feel clearer in the end, not more technical
The rebuild is not an end in itself. In day-to-day use, KALYIX should become easier to follow: a clear editor, a predictable live path, and less friction around technical edge cases.
A tool instead of a workaround
KALYIX should not feel like a collection of detours. The goal is a tool that carries the real workflow instead of just bridging gaps between several systems.
More control during live use
Overlays, alerts, preview, and control should run through a cleaner flow. For users, that means less friction between editing, preparing, and going live.
Clear roles inside the system
Shell, core, runtime, integrations, and later output each get clearer responsibilities. That makes KALYIX more modular instead of bending the core every time something new gets added.
How V2 thinks technically
V2 moves the technical center away from the webview and closer to the Rust core
For developers, the real difference is not just 'rewritten in Rust'. The real difference is how responsibility is distributed. V2 treats shell, core, runtime, and integrations as separate roles instead of one tightly chained UI path.
- HTML is not just presentation, it sits too close to the actual source of truth
- browser and webview layers influence too many core decisions
- OBS-adjacent flows quickly become the silent default for the rest
- extensions happen more through bridges than through clean system boundaries
- OverlayDocument and runtime state become the actual source of truth
- the shell handles startup, windows, and activation, not product logic
- integrations connect to clearer interfaces instead of the hot path
- runtimes can later run more deliberately locally, distributed, or on Linux
Who this is for
For users, the result should feel simpler, not more complicated
Even though the technical side of V2 goes deeper, the result should become easier for users. The rebuild is not an end in itself. It is meant to produce a more stable and clearer product.
KALYIX is aimed first at streamers and creators who want more control over the editor, alerts, and the live workflow without depending on somebody else's platform logic.
- Windows first as the main platform
- Twitch first as the real platform priority
- local use before cloud lock-in
- clear product boundaries instead of a mixed old/new stack
What this unlocks later
Modular runtimes instead of one giant block
The new structure opens up more than just a better desktop app. Individual runtimes can later run outside the main app when that makes sense for a specific job.
That makes Linux runtimes, split processes, external event handling, and multi-access more realistic later on. Even so, the first focus stays on a strong local product for Windows and Twitch.
Next step
You can find the concrete build plan in the roadmap
This page is mainly about the why and the product picture behind it. If you want to see what gets built first, what follows after that, and where V1 fits as a legacy build, head to the roadmap.