Scaling Linear's Project Architecture

Linear is beloved for its speed and minimalism — until project lists grow beyond what the interface was designed to hold.

A community thread on r/Linear surfaced the pattern: a user posted a screenshot of their "Move to project…" dialog showing a scrolling list of mostly-completed projects, with no visual distinction between active and stale work. Other users confirmed the same problem. Linear staff acknowledged the feedback. The workaround — auto-archiving buried six clicks deep in team settings — exists. But for most users, it may as well not.

Before designing a single frame, I needed to validate whether this was one team's complaint or a systemic pattern. I used an AI-augmented research workflow to synthesize signals across two Reddit threads, five individual G2 reviews, an AI-generated G2 summary aggregating 74 reviews, Linear staff responses, and a first-hand usability test attempting to locate the auto-archive setting myself.

AI was the synthesis partner, not the generator. I used it to identify patterns appearing across 3+ independent sources, distinguish feature requests from UX problems, and stress-test my initial framing by asking it to argue against my hypothesis. The pattern surfaced in hours, not days: Linear scales well for small teams and quietly breaks down for larger ones — and the cause isn't missing functionality. It's how Linear exposes, defaults, and contextualizes the functionality it already has.

This is an information architecture problem, not a UI problem.

A surface-level fix would add a "hide completed" toggle or a better filter. These would help — marginally. The deeper diagnosis: Linear currently treats all projects as equivalent — active or completed, current or stale — and relies on the user to mentally filter them every time.

Three reframings shaped the redesign. Defaults matter more than features: Linear already has auto-archive, but it's invisible, defaults to six months, and requires manual configuration. A well-designed system makes the default safe, visible, and contextual. Hierarchy should reflect usage, not equality: a project worked on yesterday shouldn't sit at the same visual weight as one completed six months ago. User workflow patterns differ: managers pin critical projects, contributors jump between active sprints, and a single flat list cannot serve both.

These three reframings led to three interconnected surfaces — none of them new features, all of them re-expressions of functionality Linear already has. The system thinking matters more than any single screen: each surface only works because the others do. Remove one and the leverage disappears.

Three surfaces, one system.

Project List Hierarchy restructures the default project view: active projects visible by default, completed projects collapsed into a findable "Completed" section, sorted by when work last happened rather than alphabetically or by creation date.

Smart Project Picker restructures the "Move to project…" dialog around how people actually work: pinned projects at the top, recent projects from the past week below, and search-first access to everything else.

Discoverable Auto-Archive turns a buried setting into a default-on behavior for new teams, starting at 30 days instead of six months. When a team accumulates 10+ completed projects without archiving, the system surfaces a proactive prompt — not a buried configuration option.

The three work as a system. The picker is faster because the list is shorter. The list is shorter because archiving happens automatically. Archiving happens automatically because the default is sensible and the prompt is discoverable. Remove any one piece and the others lose leverage.

This is a speculative case study, which means the honest answer to "does this work?" is: not validated yet. The recency-as-default-sort assumption, the 10-project threshold, and the pinned-vs-recent weighting are all hypotheses that would need testing before shipping. The point isn't to claim I've solved Linear's project architecture. It's to show how I'd approach the problem — and to be honest about where the work would continue.