A real-time Kanban for screen deployments

A complete Kanban module I built with custom drag and drop, live WebSocket updates and spreadsheet imports.

My role: Module owner. I wrote the Kanban module and drag-and-drop library. The CRM API behind it was co-built with a three-person team.

October 2025 to present

• Svelte
• SvelteKit
• WebSockets
• TypeScript

From a table to a Kanban

The first version of this feature was a table of deployment cases. Updating a case meant opening a row, waiting for a modal, changing one field and saving it. This was fine for data that was mostly read, but these cases move between stages all day.

Around May 2026, I started rebuilding it as a Kanban. The new version was released in early July and is now used to follow a screen deployment from the first prospect to the final installation.

What I built

I built the complete case-management module in the fleet operations console. It has one column per deployment stage, draggable cards, popovers and detail views, quick assignment, filters, and bulk imports from spreadsheets.

I also wrote the drag-and-drop library myself. Moving a card is not only a visual reordering: when it crosses into another column, its stage changes through the API and every other open board needs to receive the same update.

The bulk import is handled by a 508-line parser. It takes the spreadsheets where the team previously stored these deals and turns them into cases, so adopting the board did not require retyping everything by hand.

Keeping several users in sync

The board receives live updates through WebSockets. If one person moves a card, it also moves on every other screen without a refresh.

The difficult part is that the local user and the WebSocket can update the same card at the same time. For example, an incoming event should not interrupt a drag already in progress. I had to decide which state wins for each action so the board stays consistent without feeling like it is fighting the user.

A performance problem

After the first version of the board worked, it still had a performance issue. Every pointer movement during a drag, and every keystroke inside the filters, could cause the complete board to render again instead of only the affected cards.

I profiled the renders, fixed the cascades, then wrote a performance audit in the repository with the patterns that caused them. This kind of issue does not fail a test, so keeping the explanation next to the code is important for the next person who changes the board.

Across the frontend and API

One breaking change required work on both sides: I moved the case stage to an integer-backed enum in the frontend module and in the CRM API the team co-built. The Kanban module itself and its drag-and-drop code were written entirely by me, while the larger CRM API is shared work.

In numbers

The rebuild added 5,938 lines across 72 files, including the 508-line bulk import parser. I am also the sole author of the drag-and-drop library and the performance audit.

The console this board lives in is 3,027 commits deep; 1,364 of them are mine (45%), which makes me its largest contributor. The data behind the board, including the Gmail and Calendar integrations, is a separate write-up.