Developer Workbench
An Electron desktop app built to close the developer experience gaps a 70-engineer team was working around every day: devbox management, merge queue, AWS, RabbitMQ, and more.
fli-gui is a 40,000-line Electron/Angular desktop application I built incrementally over several years. It started with a specific problem: the daily developer workflow at a company with 70+ engineers, a complex devbox setup, a merge queue, and multiple environment types required too much context switching. Browser tabs, CLI sessions, SSH connections: no single place to see what was happening. fli-gui became that place.
322 commits later it covers devbox management, Elasticsearch exploration, QA Box management, a full merge queue interface (submit diffs, track builds, manage the pipeline), an AWS EC2 browser, Phabricator teams browsing, git stats with gamification, consumer management, and RabbitMQ control. It has its own packaging pipeline, Electron IPC layer, persistence layer, and self-upgrade mechanism. The engineering team uses it daily.
Hosts
Remote host management with live state, log streaming, and service control for dev environments.
Git Stats
Contribution tracking across the org: commit graphs, repository distribution, and year-in-review summaries.
AWS EC2
Browse running instances, health checks, and instance metadata without leaving the app.
Teams & Components
Audit surface for org-wide Phabricator hygiene. Surfaces violations live (dead teams, unowned components, wrong contacts) based on a codified ruleset covering 5 project subtypes.
Test Runner
Run functional and integration tests against remote environments with live output streaming.
Merge Queue
QA environment provisioning and submission management: submit diffs, track builds, manage the merge pipeline.
What I find interesting about it
Shipping a desktop app to engineers who don’t want to think about updates is a real problem. The self-upgrade mechanism means people are always on the current version without doing anything, and that had to work reliably or adoption would have stalled.
The Teams view has the longest backstory of anything in the app. At 70+ engineers, Phabricator’s project structure had accumulated ~500 violations: teams with no active members, components owned by nobody, critical bugs landing on dead tags, contacts pointing at people who’d left. The project type rules existed from day one, written into the creation wizard. Nobody was enforcing them at runtime. The only audit path was writing MySQL queries against the Phabricator database and producing spreadsheets. In 2025 I moved the rules into a validation service in the app (covering 5 project subtypes with specific constraints on ownership, contacts, naming, color, and icon) so violations surface live to any engineer who opens the page, and teams can fix them without knowing what the rules even are.
The git stats view is the clearest illustration of how the app grew. It took roughly a day to build. It generates year-in-review summaries, contribution graphs, per-engineer breakdowns. The team started comparing numbers. People noticed where they ranked. It created more engagement than the EC2 browser that took a week. It got better exactly when the team hit a friction point. Something is slow or annoying, here is a screen for it. Over enough of those, that becomes 40,000 lines.