Local-first: la guía definitiva (2026)
¿Qué es local-first?
El término nació en 2019, cuando el laboratorio de investigación Ink & Switch publicó un ensayo fundacional titulado "Local-first software: You own your data, in spite of the cloud". Los autores — incluyendo a Martin Kleppmann, investigador de la Universidad de Cambridge — propusieron un conjunto de principios para software colaborativo donde el dispositivo del usuario es la fuente de verdad, no un servidor remoto.
Los 7 principios del ensayo original (resumidos):
| # | Principio | Qué significa |
|---|---|---|
| 1 | Tus datos están en tu dispositivo | El archivo real vive localmente, no es una caché de la nube |
| 2 | Funciona offline, sin advertencias | No necesitas conexión para leer, escribir o editar |
| 3 | Permanencia local | Si la empresa cierra, tus datos siguen en tu disco |
| 4 | Sin vendor lock-in | Los datos están en formatos abiertos o legibles, no atrapados en un servidor propietario |
| 5 | Colaboración cuando la hay | Si quieres sincronización, es opcional — no obligatoria ni centralizada |
| 6 | Rendimiento instantáneo | Leer y escribir en disco local es más rápido que hacer roundtrips a un servidor |
| 7 | Facilidad de uso | La experiencia no debería ser peor que la de una app de nube |
Fuente: Ink & Switch, "Local-first software: You own your data, in spite of the cloud" (2019). Disponible en inkandswitch.com/essay/local-first.
La idea no es nueva — los documentos de escritorio siempre fueron locales. Lo que cambió es que ahora existe la tecnología para tener software colaborativo que también es local. Eso incluye CRDTs (tipos de datos replicados sin conflictos), sync engines y APIs modernas de acceso al filesystem del navegador.
Local-first vs cloud-first vs offline-first
Estos tres términos suenan parecidos pero describen arquitecturas distintas. Esta es la diferencia:
| Aspecto | Cloud-first | Offline-first | Local-first |
|---|---|---|---|
| Fuente de verdad | El servidor | El servidor (caché local temporal) | Tu dispositivo |
| Sin internet | No funciona | Funciona parcialmente (caché) | Funciona completo |
| Si la empresa cierra | Pierdes todo | Pierdes todo (sin servidor) | Tus datos siguen |
| Colaboración | Nativa (tiempo real) | Se sincroniza al reconectar | Opcional, sin servidor central |
| Cuenta requerida | Sí | Sí | No |
| Ejemplo típico | Google Docs, Trello, Notion | Progresivas web apps con service worker | Obsidian, Joplin, Hito |
La diferencia clave: offline-first sigue teniendo un servidor como dueño de los datos. El modo offline es una caché temporal. En cambio, local-first invierte la relación: el servidor (si existe) es un espejo, no el original.
El estado del movimiento en 2026
Siete años después del ensayo de Ink & Switch, el local-first pasó de ser una idea académica a un ecosistema con herramientas reales, conferencias dedicadas y librerías maduras.
Señales de adopción
- FOSDEM 2026 incluye un devroom completo dedicado a local-first, CRDTs y sync engines — un espacio que compite con temas como Rust y WebAssembly.
- Smashing Magazine publicó en mayo 2026 un artículo sobre la arquitectura local-first en desarrollo web, con una perspectiva honesta: funciona, pero tiene trade-offs reales que la mayoría de tutoriales ignoran.
- Librerías como Automerge y Yjs son estables y se usan en producción en herramientas como Notion (internamente), Logseq y Zed.
- Múltiples sync engines compiten por ser el "Firebase de local-first" — algunos open source (PowerSync, Electric), otros propietarios.
Lo que todavía duele
La comunidad es honesta sobre los problemas:
- Colaboración en tiempo real es difícil. Los CRDTs resuelven conflictos de edición, pero la experiencia de ver a otro cursor moverse en tiempo real es más compleja que con un servidor central.
- Mobile tiene limitaciones. La File System Access API de Chrome no funciona en iOS Safari. Las apps nativas lo resuelven mejor que las PWAs.
- Backup sigue siendo tu responsabilidad. Si tu disco se rompe y no tenías un backup, los datos se pierden. La nube resolvía esto "gratis".
Herramientas local-first que existen hoy
No es un concepto teórico. Hay herramientas de producción que funcionan así:
| Herramienta | Tipo | Local-first real? | Nota |
|---|---|---|---|
| Hito | Gestión de proyectos | ✅ Sí | JSON local, sin backend, PWA offline |
| Obsidian | Notas / knowledge base | ✅ Sí | Archivos Markdown en disco, plugins opcionales |
| Anytype | Todo (notion-like) | ⚠️ Parcial | Local-first pero source-available, no open source |
| Logseq | Notas outliner | ✅ Sí | Archivos org-mode local, sync opcional |
| Joplin | Notas | ✅ Sí | Open source, sync opcional via DropBox/WebDAV |
| AppFlowy | Notion-like | ✅ Sí | Open source (AGPLv3), Flutter nativo |
La mayoría comparte un patrón: guardan tus datos en archivos legibles en tu disco, ofrecen sync opcional (sin obligar) y no requieren cuenta para usarlos.
Si quieres ver comparativas más detalladas de algunas de estas herramientas, tenemos posts sobre alternativas a Notion y Hito vs Trello.
Trade-offs honestos: lo que local-first NO resuelve
Antes de emocionarte (y nosotros somos un proyecto local-first, así que nos emociona), hay que ser honesto sobre lo que no funciona bien:
Lo que se pierde
- Colaboración en tiempo real fluida. Si tu equipo necesita editar el mismo documento simultáneamente y ver cambios al instante, un servidor central (Google Docs, Notion) lo hace mejor hoy. Las herramientas local-first están mejorando, pero todavía no es su punto fuerte.
- Setup inicial. En una app de nube, entras, creas cuenta y listo. En local-first, necesitas elegir dónde guardar tus archivos, configurar sync si quieres colaboración, y planificar backups. Es más fricción inicial.
- Múltiples dispositivos sin sync. Si trabajas en la PC de la oficina y la laptop de casa sin ningún mecanismo de sincronización, vas a tener versiones desactualizadas. La solución típica es usar Dropbox, Google Drive o Git — pero eso agrega complejidad.
- IA asistida requiere enviar datos. Esto vale la pena destacarlo porque es un punto de confusión. Si usas un asistente de IA integrado (como el de Hito), tus datos se envían al modelo de IA (en nuestro caso, Gemini, con tu propia API key). El storage sigue siendo local, pero la IA necesita ver tus datos para ayudarte. Es un trade-off consciente: puedes simplemente no activar el asistente si tus datos son extremadamente sensibles. Si quieres entender cómo funciona esto a nivel técnico, tienes nuestro post sobre Qué es MCP.
Cómo funciona Hito como caso real
Para que no sea todo teoría, acá va cómo se ve local-first en la práctica con Hito:
Arquitectura de almacenamiento
Hito usa dos adaptadores de almacenamiento, dependiendo de tu navegador:
| Adaptador | Navegador | Cómo funciona |
|---|---|---|
| FileSystemAdapter | Chrome, Edge, Brave | Usa la File System Access API para leer y escribir archivos JSON directamente en la carpeta que elegiste. Persiste el acceso entre sesiones usando IndexedDB. |
| DownloadAdapter | Firefox, Safari, móvil | Como fallback, descarga archivos JSON individuales y pide que subas archivos cuando quieres cargar. Más manual pero funcional. |
En ambos casos, cada entidad (proyecto, tarea, persona, etc.) es un archivo .json separado y legible. No hay una base de datos propietaria ni un servidor al que consultar.
Offline
Hito es una Progressive Web App (PWA) con service worker. Eso significa que la aplicación se instala en tu navegador y funciona sin conexión. Tus datos están en disco, no en la nube, así que no necesitas internet para crear tareas, mover tarjetas en el kanban o editar procesos.
Sync (opcional)
No hay servidor de sync. Si quieres compartir tu workspace con el equipo, pones la carpeta en Dropbox, Google Drive o Git, y cada persona abre esa misma carpeta con Hito. Es sync a nivel de archivos, no a nivel de registros — simple, transparente y sin intermediarios.
IA (opcional)
El asistente usa Gemini con tu propia API key. Si lo activas, envía datos de tu workspace a Google para generar respuestas. Si no lo activas, Hito nunca se comunica con ningún servidor externo.
¿Te conviene local-first?
Sí, si:
- Manejas datos sensibles: información legal, médica, financiera o de clientes que no debería estar en un servidor de terceros.
- Quieres control total sobre tus datos: no te gusta que una empresa pueda cerrar tu cuenta, cambiar los precios o perder tus datos por un breach.
- Trabajas solo o en equipos pequeños-medianos: la fricción de sync no es tan grande.
- Valoras el offline: viajas mucho, trabajas en lugares con mala conexión o simplemente no quieres depender del WiFi.
- Te interesa el open source: poder auditar el código que maneja tus datos.
Probablemente no, si:
- Colaboración en tiempo real es crítica: tu equipo edita documentos simultáneamente y necesita ver cambios al instante (Google Docs sigue siendo mejor para eso).
- No quieres pensar en backups: si no tienes un hábito de respaldar tus archivos, la nube te da un safety net que local-first no tiene por defecto.
- Tu equipo es grande y distribuido: sin una estrategia de sync clara, vas a tener problemas de versiones.
Conclusión
El software local-first no es una vuelta al pasado ni una utopía anti-nube. Es un punto intermedio: tus datos viven en tu dispositivo, pero puedes elegir si y cómo sincronizarlos. En 2026 ya hay herramientas maduras que lo implementan bien, y el ecosistema sigue creciendo (FOSDEM, librerías estables, nuevas apps).
El trade-off es real: ganas privacidad, control y offline, pero pierdes algo de la fluidez colaborativa de las apps de nube. Para muchos equipos — especialmente los que manejan datos sensibles — el intercambio vale la pena.
Si quieres probar cómo se siente, Hito es gratis, open source y no necesita cuenta. Eliges una carpeta, creas tu primer proyecto y listo. Tus datos quedan ahí, en tu disco, sin intermediarios.
Sobre Hito: Gestión de proyectos, procesos y checklists 100% local-first. Open source (MIT), sin nube, sin cuenta, sin suscripción. Pruébalo gratis →
Equipo Hito
Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.