Linear's speed is a one-way door: the local-first retrofit trap

What happened

A technical breakdown of Linear's frontend at performance.dev hit #1 on Hacker News with 379 upvotes, the latest in a multi-year drumbeat of posts dissecting why the project tracker feels faster than every other SaaS tool on the market. The piece walks through the now-familiar architecture: a client-side database in IndexedDB, a sync engine that streams transactions over WebSocket, optimistic mutations that resolve locally before the server confirms, and a read path that never — under any circumstance — blocks on the network.

The community response was telling. Half the thread was engineers nodding along: yes, this is why Jira feels like wading through mud. The other half was founders and tech leads asking the wrong question — *how do we add this to our app?* — as if local-first were a library you `npm install` on a Tuesday.

Linear's speed is not a feature. It is the shape of the entire backend, the data model, the schema migration story, and the team's hiring profile, fused into a single architectural commitment that cannot be unwound. That's the part the breakdowns keep underselling, and the part every team chasing "Linear-fast" is about to learn the expensive way.

Why it matters

The published narrative — local database, sync target, no network reads — is correct but incomplete. What it omits is the cost of admission. A sync engine is not a cache. A cache can be wrong, evicted, or bypassed; a sync engine is the source of truth's projection, and once clients depend on it, the server can never again do anything the protocol can't express.

Consider what Linear had to commit to from day one. Every mutation has to be modeled as a transaction with a deterministic identifier, so the client can replay it on reconnect without duplicating. Every entity has to fit a delta model — partial updates, not full-object writes — because shipping the whole issue across the wire on every edit defeats the point. Schema changes have to be backward-compatible across every connected client, including the laptop that's been closed in a backpack for six weeks. Authorization can't be a server-side filter anymore; it has to be a partition the client can compute against its local replica. Search has to run locally or it ruins the illusion. Once a sync engine ships, every product decision is filtered through "can the protocol express this?" — and the answer is permanently no for a long list of obvious features.

This is why the retrofit story keeps failing. Teams add IndexedDB caching to an existing REST app, get a 30% improvement on warm loads, declare victory, and then discover that conflict resolution, offline writes, and cross-device consistency are not features you bolt on — they're constraints that should have shaped the schema two years ago. Figma rebuilt their entire multiplayer engine in Rust to get there. Notion has been migrating toward it for years and still has the sluggish bits where the old architecture peeks through. Linear had the luxury of starting from zero in 2019 with a team that understood, on day one, that they were building a distributed system disguised as a Kanban board.

The HN commenters who clocked this called it the "Local-First trap": you get the perceived speed, but you lose architectural optionality forever. Want to switch from Postgres to a graph database? The sync protocol assumed relational semantics. Want to add a workflow that requires server-side enforcement of a multi-row invariant? The clients have already mutated their replicas and the server is now the conflict resolver, not the authority. Every speed advantage Linear has is purchased with a permanent constraint on what the backend is allowed to become.

What this means for your stack

If you're a senior engineer evaluating whether to adopt a sync engine — Replicache, ElectricSQL, Zero, Jazz, or a hand-rolled equivalent — the right question isn't *can we get Linear-fast?* It's *are we Linear-shaped?* The shape matters more than the technique.

Linear-shaped products have a few traits in common. The objects are small (issues, comments, status changes — not 50MB documents). The edit frequency is high but the per-edit payload is tiny. The graph is single-tenant or workspace-scoped, so each client only syncs a bounded slice. The collaboration model is eventually consistent — two people editing the same issue title can both "win" with a CRDT and nobody dies. And the team has senior systems engineers who can debug a vector clock at 2am when a customer's replica diverges.

If your product is a finance app where two clients writing the same balance can't both win, you don't want this. If your objects are large documents with structured embeds, you're signing up for the Figma engineering budget. If your team is three full-stack devs maintaining a CRUD app, the sync engine will become the thing they fight every sprint instead of shipping features.

The teams getting real value from local-first in 2026 are the ones who chose it before writing line one of product code, not the ones bolting it onto a year-three codebase to chase a competitor's Lighthouse score. Bundle splitting, route prefetching, partial hydration, and a competent N+1 audit will get a normal app from 800ms to 200ms perceived latency without committing to a sync protocol you'll be maintaining in 2032.

Looking ahead

The wave of sync-engine-as-a-service startups — Replicache, ElectricSQL, Zero, Jazz — is betting that the architectural cost can be commoditized down to library-level. They're partially right: the protocol layer can be abstracted. The data modeling discipline, the schema evolution constraints, the authorization rethink, and the offline conflict UX cannot. Expect a cohort of post-mortems in 2027 from teams that adopted a sync engine for the speed and then spent eighteen months unwinding the assumptions it baked into their product. Linear got there first because they paid the cost upfront. Everyone else is about to discover what the bill looks like in arrears.