Enterprise software teams frequently struggle with UI latency: a traditional CRUD app takes about 300ms to update an issue, according to a technical breakdown by Dennis Brotzky. Linear, the project management platform, achieves response times measured in milliseconds. How? The company inverted the conventional client-server model.
Database in the Browser
Most web apps force users to wait on a network round trip: click, HTTP request, server query, response, repaint. “The biggest bottleneck you will fight is the network,” Brotzky writes. Linear eliminates that bottleneck by making the browser’s IndexedDB the primary database for the UI. Mutations apply locally first, then asynchronously push to the server, which broadcasts deltas to other clients via WebSocket.
In practice, updating an issue looks like this:
issue.title = "Faster app launch"; // updates in-memory datastore immediately
issue.save(); // queues transaction for sync engine
The in-memory datastore uses MobX observables. The UI re-renders synchronously off the local update, eliminating spinners and skeleton screens. “Any data sent between the client and server costs hundreds of milliseconds. The best approach is to eliminate the need for a network request entirely,” Brotzky notes.
The Sync Engine as the Foundation
Linear’s co-founder Tuomas stated at a 2024 conference: “Literally the first lines of code that I wrote was the sync engine, which is very uncommon to what you usually do when you're a startup.” This engineering priority enabled the entire architecture. Brotzky, who has never worked at Linear but studied the app and its public content, emphasises that building a custom sync engine is not necessary for most companies. Libraries like Tanstack Query and SWR can achieve similar responsiveness with optimistic updates.
| Aspect | Traditional CRUD App | Linear Approach |
|---|---|---|
| Data location | Server database | Browser IndexedDB (local first) |
| Mutation timing | Await network response | Apply locally, sync async |
| Typical latency | ~300ms | Milliseconds |
| Loading states | Spinners, skeletons | None |
| Key enabler | None | Custom sync engine + WebSocket |
Optimistic Updates for the Enterprise
For enterprise procurement leaders evaluating software, the lesson extends beyond Linear. Brotzky argues that “most web apps feel slow because the UI waits for each network request to complete before updating state.” Using optimistic updates—assuming network success and rolling back on failure—can dramatically reduce perceived latency. The code pattern is simple:
mutate(`/api/issues/${issue.id}`, { title: "New title" }, { optimisticData: ... });
Designed for Speed from Day One
Linear’s architecture was not retrofitted; it was baked in from the start. Brotzky notes that “there's no secret silver bullet to performance. The reality is that it's built from the ground up on the right foundation, then improved by countless decisions.” For CTOs overseeing product development, this suggests that performance must be a first-class architectural concern, not an optimisation afterthought.
The techniques outlined—local-first data, optimistic mutations, and a sync engine—are directly applicable to any enterprise application where user experience and offline capability matter. While Linear is a project management tool, the underlying principles generalise to any web app that requires fast, collaborative editing.
Sources:
