Our objective is to deliver a best-in-class local-first experience: one that approaches perfection in speed, reliability, consistency, and user trust.
I do not want us to ever repeat the situation we had last week, where the app felt so low-quality and unreliable. We should not accept that level of experience. I do not want to see another loader unless the user is opening a new document or performing an action where waiting is truly unavoidable.
The effort we made last week was important, but it cannot be a one-time push. We need to keep pressure on this problem until the local-first experience is genuinely excellent.
The app should feel like a Kindle for your workspace: calm, focused, instantly available, and fully reliable even offline.
This is not just a performance goal. It is a product-quality goal. Users should feel that the app is always ready, that their data is close to them, and that the interface never makes them doubt whether the system is working.
Plan
1. Map the data flow
We need a current, shared picture of how data moves through the client.
Let’s create a Mermaid data-flow chart that shows every data avenue in the client: local storage, daemon, sync, network, cache, document loading, subscriptions, UI state, and any fallback paths.
The goal is to make the current situation visible so we can reason about it clearly.
2. Define and track performance metrics
We need to measure the experience clearly and continuously.
We already have metrics for the daemon. We need equivalent metrics for the clients: startup time, document open time, sync readiness, local data availability, time spent showing loaders, perceived latency, and any moments where the user is blocked.
Without client-side metrics, we are guessing. We need visibility into where the experience breaks down.
3. Identify the problems and attack them one by one
Once we have metrics and a clear data-flow map, we should identify the specific causes of loaders, delays, stale states, and unreliable behavior.
Then we attack them one by one with clear solutions.
Each solution should be coherent with the overall architecture. We should avoid patching symptoms in isolation. The work needs to move us toward a simpler, more reliable local-first system.
Standard
The bar is simple:
The app should feel instant unless there is a truly unavoidable reason not to.
The user should trust that their workspace is available, local, and ready.
A loader should be treated as a product-quality failure unless we can clearly justify it.
We are aiming for a local-first experience that feels calm and fast by default.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime