What problem were we trying to solve?
Flux exists because every project management tool we used treated our boards as static documents instead of live systems. We would drag a card to a new column and wonder whether our teammates saw the move. We would accidentally delete a card and spend twenty minutes reconstructing it from Slack messages. We wanted to wire our CI pipeline to our board but the API was an afterthought bolted onto a UI-first product. These are not edge cases. They are the daily reality of software teams trying to ship with tools designed for filing and reporting.
We did not set out to build another project management tool. We set out to fix three specific problems that slowed our own team down every single day: stale board state, irreversible actions, and the gap between the board UI and the developer toolchain. Flux is the result of solving those problems from first principles.
Why are most kanban boards stale?
Traditional project management tools use a request-response model. You load the board, you see a snapshot. Your teammate moves a card. You do not see it until you refresh the page or navigate away and come back. In the meantime, you might move the same card, or start working on something that someone else already picked up, or assume a column is empty when it has three cards in it.
This staleness is not a minor inconvenience. It is the root cause of the most common project management failure: the board stops reflecting reality, so people stop trusting the board, so they stop using the board, and the team reverts to asking each other for status updates in Slack. The board becomes decoration.
Flux solves this with server-sent events (SSE). When any user moves a card, edits a title, adds a comment, or changes an assignment, every other connected client sees the update instantly. There is no polling interval, no manual refresh, and no stale state. The board is a live view of the project, not a cached snapshot. When you look at it, you see what is happening right now.
The technical implementation matters here. SSE is lighter than WebSockets for our use case - unidirectional server-to-client updates. The client maintains an EventSource connection to a board-specific endpoint. When the server processes a mutation, it emits an event to all connected clients for that board. The client invalidates its local cache and refetches the authoritative state. This means every client converges on the same truth within milliseconds of any change. For the full technical architecture of our real-time collaboration system, see the product page.
Why should every action be undoable?
The second frustration was irreversibility. In most tools, deleting a card is permanent or requires digging through a trash folder to find and restore it. Moving a card to the wrong column? Hope you remember where it was. Changing a description overwrites the previous text with no way to recover it.
We wanted undo to work the way it works in a text editor - press a button, the last action is reversed, the system returns to its previous state. But project management is collaborative, so undo has to be conflict-aware. If you delete a card and someone else adds a comment to it before you undo, the system needs to warn you that reversing the deletion will also affect the comment.
This led us to event sourcing. Every mutation in Flux - card creation, column reorder, description edit, label change - is recorded as an immutable event in the activity log with before-and-after state snapshots. Undo reads the most recent event, checks for conflicts with subsequent events, and applies the inverse operation. The activity log is not just an audit trail - it is the mechanism that makes undo possible.
Event sourcing also gives you a complete project history for free. Who created this card? When was it moved to Review? Who changed the description, and what was it before? These questions are trivially answered when every action is an immutable event rather than a destructive overwrite.
Why does a kanban board need a REST API?
Developer teams do not live in a browser tab. They live in terminals, CI pipelines, Slack bots, and increasingly, AI agents. A project management tool that can only be operated through a web UI is a tool that cannot participate in the developer workflow.
Flux ships with a full REST API from day one - not a limited integration API, but the same API that powers the web client. Every operation you can perform in the UI, you can perform via HTTP. Create cards from a GitHub Action when a PR is opened. Move cards to Done when a deployment succeeds. Read board state from a monitoring script. Archive cards older than 30 days from a cron job.
The API uses scoped API keys with granular permissions. A CI integration might get a key with only write scope for a specific workspace. A read-only dashboard gets a key with read scope. Every request is idempotent via the X-Idempotency-Key header, so retried CI jobs do not create duplicate cards.
We also implemented optimistic concurrency with version numbers on every entity. If two systems try to update the same card simultaneously, the second request gets a 409 Conflict response instead of silently overwriting the first change. This is table stakes for any system that multiple processes touch concurrently, but most project management APIs do not bother.
How does the MCP server extend the API story?
The REST API solved the integration problem for scripts and pipelines. But in 2025-2026, the most interesting new "users" of project management tools are AI agents - Claude, Cursor, Windsurf, and custom agents built with the Anthropic SDK or LangChain.
AI agents do not call REST APIs the way scripts do. They speak the Model Context Protocol (MCP), a standard that lets an agent discover and invoke tools exposed by a server. Flux's MCP server exposes board operations as MCP tools: read a board, list cards in a column, create a card, move a card, add a comment. An AI agent connected to Flux can manage your board as naturally as it can read a file or run a shell command.
The practical implications are significant. A coding agent can read the top card from your Backlog, implement the feature, then move the card to Review and add a comment with the PR link. A planning agent can review your board weekly and flag cards that have been stalled for more than five days. A triage agent can categorize incoming bug reports by reading the card description and applying the appropriate labels.
This is not speculative. It works today with Claude Desktop, Cursor, and any MCP-compatible client. The MCP page has setup instructions for each client.
Why did we make self-hosting a first-class option?
Many developer teams - particularly those at security-conscious companies, regulated industries, or simply teams that prefer to own their infrastructure - cannot or will not send their project data to a third-party SaaS. We have been on both sides of this decision, and we think both are valid.
Flux is designed to run anywhere: our hosted service, your own server, or a container in your private cloud. The same codebase, the same features, the same API. Self-hosting is not a degraded experience with missing features - it is the same product running on infrastructure you control.
For teams evaluating self-hosted options, we wrote a longer piece on the case for self-hosted project management that covers data sovereignty, latency, and customization tradeoffs.
What did we intentionally leave out?
Building a new tool means deciding what not to build. We intentionally left out several features that are standard in other tools, because we think they cause more harm than good for the teams we are building for.
- Story points and velocity tracking. Story points are a proxy metric that optimizes for estimation accuracy rather than delivery speed. We track cycle time instead - how long a card takes from start to finish. Cycle time is objective, automatic, and directly measures what matters: how fast your team ships.
- Gantt charts and timeline views. Gantt charts assume predictable task durations and sequential dependencies. Software development is neither. We use kanban boards and multi-board views because they show the current state of work rather than a speculative future timeline.
- Mandatory meetings and ceremonies. Flux has no built-in standup feature, no sprint planning wizard, no retro template. The activity log replaces the daily standup. The board itself replaces sprint planning. If your team wants ceremonies, nothing stops you - but the tool does not require them.
What are we building next?
Flux is production-ready and teams are using it today. But the roadmap is driven by the same principle that started the project: remove friction between the developer and the shipped feature.
Current priorities include deeper CI/CD integrations (GitHub Actions, GitLab CI), automation rules that trigger on card state changes, and expanded MCP capabilities for AI agents that can reason about project state over time. We are also investing in the multi-board experience for engineering leads who manage multiple teams and need cross-project visibility without context switching.
If any of this resonates with how your team works - or how you wish it worked - the best way to evaluate Flux is to use it. Sign up, create a board, invite your team, and see whether the board stays alive or becomes another abandoned tool.