My job generates a lot of surfaces to monitor. Between Linear for projects, Freshservice for the support queue, Google Calendar, Gmail, CrowdStrike, and the endless stream of Slack, I was constantly context-switching. None of these systems talk to each other, and the manual effort of turning those disjointed feeds into a coherent daily plan was work I kept skipping.

So, I built Command Center: a local Node.js server with a card-based UI that lives at http://localhost:3838. Every card is an independent module that owns its own data fetching and rendering. I wanted something that allowed me to maintain different configurations (daily workflow, on-call, weekly review) without managing a dozen separate browser tabs.

The Architecture

Command Center runs as a Node.js server, with a single-page React client that uses Babel: no build step, no webpack, no external CDN dependencies. The server handles all API traffic, communicating with the client via fetch and Server-Sent Events (SSE) for streaming content. All configuration lives in two local files, config.json and .env, and because the settings card can edit config.json in-browser, I haven’t had to touch the terminal for daily changes since the initial setup.

Reviews: Synthesizing the Workday

The review system is the engine of the dashboard. It pulls data from every integration and streams it through Claude’s API, rendering the response as Markdown in real time.

  • Morning: Generates a prioritized plan using my calendar and ticket queues.
  • EOD: Summarizes completed work and identifies carry-overs or new tasks worth creating.
  • Weekly: Performs a retrospective with velocity context from the last twelve cycles.

It runs entirely server-side, with a cron job to auto-generate these reviews and optionally fire them as Slack DMs. For quarterly prep, I also added Monthly and Yearly cards that synthesize these daily and weekly logs into a single assessment.

Linear: Workflow End-to-End

I moved the bulk of my Linear workflow into four primary cards.

  • My Issues: Lists everything assigned to me, grouped by project, with inline edit panels to update state, priority, and cycles without ever opening the actual Linear tab.
  • Triage: Surfaces unassigned and untriaged issues with team KPI pills for fast queue management.
  • Reports: Generates seven structured types, like Team Health and Cycle Planner, formatted specifically for stakeholders or 1:1 prep.
  • Project Builder: Scaffolds new projects with milestones and issues via Claude, creating them in Linear with a single button press.

The CrowdStrike Vulnerability Card: A Lesson in API Design

This card took the most debugging to get right. My first attempt showed only six vulnerable hosts, which was wildly off for a fleet of 750. It turned out to be a chain of oversights: the MAX_RECORDS cap was hitting a wall, the FQL filter wasn’t scoped to workstations, and 9,400 of those records were actually GKE nodes and Linux servers.

Scoping the Spotlight API query to product_type_desc:'Workstation' fixed the noise. But the real headache was the endpoint architecture: the combined Spotlight endpoint doesn’t return CVE details, meaning I had to write a second pass to the /v2 vulnerability metadata endpoint just to get severity and exploit status. This little detour cost me an entire afternoon, but the final result is a compliance grid that actually shows me what I need to worry about, rather than just raw volume.

Quick Modals: The “Beacon” Bridge

I wanted keyboard shortcuts that worked from anywhere, not just when the dashboard was focused. Since Command Center runs in Beacon, I mapped ⌘. for scratch notes, ⌘K for Claude, and ⌘I for Linear issues to global hotkeys. When triggered, Beacon dispatches synthetic keyboard events into the web app, driving the same modals regardless of what I’m doing on the machine. It removes the friction of having to “go find” the dashboard just to jot something down.

Storage and Access

For single-user instances, everything writes to local directories (REVIEWS_DIR and DAILY_DIR). For multi-machine setups, I implemented a Google Drive adapter; the app only requests drive.file scope, so it only sees the files it creates.

If sharing an instance with teammates, the server fetches JumpCloud group memberships at startup to restrict card visibility. If there’s no JumpCloud API key configured, the system simply defaults to full visibility, keeping the setup minimal for personal use.

The project remains private. It’s running every workday and I haven’t opened five separate tabs to start my morning in months.