Aero v3 shipped in April 2026. From the outside, it looked like a minor release - the board is still a board, tickets still have statuses, the sprint timeline is still in the sidebar. From the inside, we replaced the data model that the board runs on, the real-time sync protocol, and the way we handle multi-user concurrent edits. This is a short account of what we changed, what we didn't, and one decision we made and then reversed.
The design constraint
The constraint that drove v3 was latency. The v2 board had a perceived input latency of 80–120ms on fast connections and 300–400ms on mobile. That range puts it on the wrong side of the perception threshold - users could feel that dragging a ticket was slower than it should be. The v3 goal was sub-20ms perceived latency for drag-and-drop operations on any connection type.
We did not want to rebuild the product to hit this number. We wanted to change the specific things that caused the latency, and leave everything else alone.
What changed
The first change was moving optimistic updates earlier in the event path. In v2, a drag-and-drop operation sent the new position to the server and waited for acknowledgment before moving the ticket on screen. In v3, the ticket moves immediately on the initiating client, and the server synchronizes other connected clients afterward. The user who initiated the drag sees zero latency. Other connected users see the change within one round-trip time.
The second change was the board model. In v2, the board was a list of columns, and each column was an ordered list of ticket IDs. Moving a ticket required updating two lists in a transaction: removing from the source list and inserting at the target position. Under concurrent edits, this caused conflicts that required a full board refresh to resolve.
In v3, the board uses a fractional indexing model. Each ticket has a float64 position key within its column. Moving a ticket updates only that ticket's key. Concurrent moves can be resolved without a full board read because no two operations write to the same row. Merge conflicts become trivially resolvable by taking the later timestamp.
The third change was the real-time sync protocol. We moved from long-polling to a persistent WebSocket connection with a per-board subscription model. Connected clients receive only the events for the boards they have open.
What we didn't change
We did not change the ticket data model. Status, assignment, labels, estimates, sprint membership - all of these fields have the same schema they had in v2. The API for reading and writing individual ticket fields is backward-compatible.
We did not change the sprint timeline view. It is the same component running against the same data. The v3 real-time layer improved its update latency incidentally, as a byproduct of the WebSocket protocol change, without any direct modification.
We did not change the integration model for Aegis credential linking. Tickets can still be associated with credentials in Aegis; that connection surface was untouched.
The thing we walked back
We shipped v3 with a compact mode for the board - a denser layout that showed more tickets per column at the cost of showing less information per ticket. It reduced the visible area of each ticket to just the title and assignee avatar.
Three weeks after launch, usage data showed that compact mode had a 34% adoption rate at launch and an 11% rate at three weeks. The teams that tried it switched back. Exit surveys told us why: when tickets show less information, engineers spend more time clicking into tickets to understand their state. The cognitive overhead of the denser layout exceeded the benefit of seeing more tickets at once.
We removed compact mode in the v3.1 patch. We documented the finding in our internal design log as a reminder that density does not always improve information consumption.
Migration notes
No migration is required for most users. Boards open automatically with the new model; no data export or re-import is needed.
One exception: boards with more than 500 tickets in a single column may see a one-time reindex operation on first open. This takes under 10 seconds and only occurs once. If you have a backlog column with thousands of tickets accumulated over multiple years, consider archiving old items before upgrading to avoid this delay.
The v2 API endpoints remain available through June 2026 for teams with custom integrations against the board positioning API. After that date, the v2 endpoint returns a 410 Gone. The v3 board positioning model is documented in our API reference.