The RSI Launcher installs, updates, and starts Star Citizen. At Turbulent, I helped maintain the first version before becoming Lead Frontend Developer on V2. I led its frontend architecture, migration, development foundations, and design system with a team of four to five developers.
A critical entry point
The launcher sits between the player and the game. It manages installation, updates, multiple environments, service status, and the settings required before launch.
That position makes problems immediately visible. A download error, an unstable update, or ambiguous information can prevent access to the game. Reliability and clarity matter just as much as adding new features.
The work ahead was to rebuild what existed: consolidate what already worked, address the users’ friction points, and improve their experience, without starting from a blank slate.
Moving from V1 to V2
Modernization had to happen inside an existing application with technical history and versions already in use. A complete rewrite would have concentrated too much risk into one release.
The work involved reducing the fragility of a historical JavaScript codebase, sharing components and conventions, following major Electron changes, and continuing to ship. We also had to maintain integration with a central native C++ engine responsible for downloading, verifying, and updating the game, while coordinating several teams across time zones.
My responsibility on V2
After contributing to V1 maintenance, I led the frontend work on V2. I defined the frontend architecture, prepared the migration, established the project foundations, and supported a team of four to five developers. Delivery was collective, while technical direction and overall consistency were part of my responsibilities.
My work included the TypeScript migration, monorepo architecture, design system, communication between Node.js and the native C++ engine, and more than ten major Electron upgrades. The aim was to stay close to a current runtime in spring 2023 without interrupting product delivery.
Modernizing without interrupting the product
Migrate progressively to TypeScript
We treated TypeScript as an evolution of an active codebase. Areas could be typed as they changed, without blocking other work until a complete conversion was finished.
Organize the code as a monorepo
The monorepo brought together the parts of the product that needed to share tools, types, and components. The goal was not centralization for its own sake, but clearer dependencies and conventions.
Build a design system the product could use
The design system reduced unnecessary variation and made new screens more consistent. It did not replace product decisions. It provided a shared base for recurring components, states, and behaviors.
Upgrade Electron without stopping the product
Major Electron upgrades meant following runtime, dependency, and security changes while preserving expected launcher behavior. We handled them as regular product evolution instead of postponing them into a separate high-risk project.
Stabilize the native engine boundary
Downloading and updating the game relied on a central C++ engine. The Electron application communicated with it through Node.js bindings without exposing that complexity in the interface. This boundary needed explicit contracts, understandable error states, and close coordination with other teams.
A foundation ready for what came next
The frontend team delivered the visible V2 experience on an architecture designed to evolve. The project adopted TypeScript, a monorepo structure, and a shared design system while the Electron foundation continued to move forward. At the time, the launcher served more than one million users.
Launcher 2.0 now provides broader control over downloads, environments, and service status. The public screenshots shown here illustrate the product and its context, not an individual delivery.
Working at the pace of a live product
The difficult part was sequencing the changes. TypeScript, Electron, the monorepo, and the design system all had to move forward without creating a long period where the product could not ship.
The technical choices mattered because they supported the team’s daily pace and the reliability players expected.