One flat list.
One living map.

Your team already knows what it is building. That knowledge lives in a list, sorted by priority, one row at a time. Fervio lays the same issues out as a map: the steps a user walks through go across the top, and the releases you are cutting go down the side. Nothing is imported and nothing is copied. The map is a second way to look at the issues you already have.

Move a card and the issue changes. Drag it to another column and its labels change. Drag it to another row and its release changes. There is nothing to sync and nothing to push, because there is only ever one copy of the truth, and it is in Linear.

Journeys come from initiatives

The bands across the top are your initiatives. The columns beneath them are label groups, so a card belongs to a step by carrying a label — something Linear already understands and already filters by.

Rows come from cycles or releases

Slice the map by cycle if your team runs them, or by release labels if it does not. Either way the row a card sits in is a fact stored in Linear, not in Fervio.

Fervio keeps almost nothing

What Fervio stores is the arrangement — which journey a step belongs to, and in what order. Issue titles, states and assignees are read live every time you open a map, so the map cannot drift from Linear.

1 · Sign in with Linear

All you need is one Linear team. Fervio asks for the permissions it needs to read your issues and write your changes back, and nothing beyond them.

2 · Pick a team

Fervio builds the map from the issues that are already there. If your team has initiatives, they become the journeys straight away.

3 · Share the plan

Publish a read-only snapshot and send the link to anyone. They see the plan; they never touch your workspace.

The full setup guide is at fervio.co/docs.

Fervio does the same thing for GitHub Projects, as a separate product with its own account. It lives at fervio.co.