Renacimiento del software local-first: por qué tus aplicaciones vuelven a tu dispositivo
En 2019, un laboratorio de investigación llamado Ink & Switch publicó un ensayo donde describía lo que llamó "software local-first". La premisa era simple y las implicaciones, enormes: las aplicaciones debían almacenar sus datos en el dispositivo del usuario, funcionar completamente sin conexión a internet y tratar la nube como una capa de sincronización, no como la fuente de verdad. La respuesta de la comunidad de desarrolladores fue cálida, intelectualmente comprometida, pero sobre todo teórica. Las herramientas para construir aplicaciones local-first con calidad de producción aún no existían.
Siete años después, ya existen. ElectricSQL alcanzó la versión 1.0 en marzo de 2025, llevando sincronización estable de Postgres a SQLite local. Automerge y Yjs — las dos bibliotecas CRDT dominantes — han madurado considerablemente. La Local-First Conference en Berlín atrajo a investigadores, startups e ingenieros de empresas consolidadas. Y la inteligencia artificial en el dispositivo le ha dado a este enfoque arquitectónico una nueva razón comercial para existir, más allá de la ideología.
Qué significa realmente local-first
El término se usa de forma bastante vaga, así que vale la pena ser precisos. Una aplicación local-first almacena sus datos principales en el dispositivo del usuario — en una base de datos local, como archivos planos o en el almacenamiento del navegador — y sincroniza esos datos con otros dispositivos o un servidor como operación secundaria. La invariante de diseño crítica es que la app funcione completamente sin conexión de red. No "muestra datos en caché" — funciona, lee y escribe, con todas las funcionalidades.
Los siete principios originales de Ink & Switch incluyen: operaciones instantáneas sin ruedas de carga, funcionalidad offline completa, sincronización fluida entre dispositivos, colaboración en tiempo real, longevidad de datos (la app funciona incluso si la empresa cierra), seguridad por defecto y propiedad de los datos del usuario con portabilidad de exportación. La mayoría de las apps cloud-first fallan al menos en cuatro de estos. La mayoría de las apps local-first construidas con las herramientas actuales pueden cumplir los siete.
La tecnología que lo hace posible: CRDTs
La razón por la que la sincronización local-first era antes poco práctica son los conflictos de fusión. Si editas un documento en tu móvil mientras estás offline, y otra persona edita el mismo documento en su portátil, ¿cómo fusionas las dos versiones cuando el móvil se reconecta? El enfoque ingenuo es elegir una versión y descartar la otra, lo que es catastrófico para la colaboración. El enfoque sofisticado implica transformaciones operacionales — algoritmos complejos que funcionan, pero requieren un servidor central para arbitrar.
Los CRDT, o Conflict-Free Replicated Data Types, resuelven este problema con matemáticas, no con infraestructura. Un CRDT es una estructura de datos diseñada para que las ediciones concurrentes en múltiples réplicas siempre puedan fusionarse en un resultado consistente sin necesidad de un coordinador central. Las matemáticas garantizan consistencia eventual — todas las réplicas terminan con el mismo estado — sin que un servidor tenga que intervenir. Google Docs, Figma y WhatsApp usan CRDTs para sus funciones de colaboración y sincronización entre dispositivos.
Para las apps local-first, esto significa que dos móviles pueden editar el mismo documento estando completamente offline, reconectarse y llegar automáticamente a un resultado fusionado correcto. La pesadilla de los conflictos de fusión que tanto temían los desarrolladores resulta ser, en la práctica, prácticamente inexistente para escenarios típicos de edición de documentos y datos.
Las herramientas están listas para producción
Yjs es el estándar de la industria para edición de texto colaborativo en tiempo real. Escrito en JavaScript con un puerto rápido a Rust (Yrs), se integra directamente con ProseMirror, Tiptap y CodeMirror — cubriendo la mayor parte del ecosistema de editores de texto enriquecido. Si has usado un editor de documentos web en los últimos tres años, probablemente has usado Yjs sin saberlo.
Automerge adopta un enfoque diferente: almacena el historial completo de cada cambio como un objeto de primera clase. Esto lo hace más parecido a Git para datos de aplicación: puedes ramificar, hacer diff, fusionar y seleccionar cambios entre réplicas. Compilado a WebAssembly para uso web, sacrifica un mayor tamaño por capacidades de historial más ricas.
ElectricSQL ocupa un nicho diferente: en lugar de gestionar CRDTs directamente, sincroniza subconjuntos de una base de datos PostgreSQL a SQLite local en el cliente. Para equipos que ya usan Postgres, esta es la ruta de menor fricción hacia una arquitectura local-first — tu base de datos existente se mantiene; añades una capa de sincronización delante. La versión 1.1, lanzada en agosto de 2025, ofreció escrituras 102 veces más rápidas y lecturas 73 veces más rápidas en comparación con la versión anterior. Está en producción en Trigger.dev y gestionando millones de actualizaciones diarias.
Por qué el momento es adecuado en 2026
Tres fuerzas convergentes están impulsando el renovado interés en la arquitectura local-first, más allá del idealismo de los desarrolladores.
Primera: la IA en el dispositivo. Las unidades de procesamiento neuronal que ofrecen más de 70 TOPS ya son estándar en los teléfonos insignia. Los Foundation Models de Apple ejecutan un modelo de lenguaje de 3 mil millones de parámetros completamente en el dispositivo, en iPhone y Mac. Cuando la inferencia de IA se traslada al dispositivo, los datos sobre los que opera la siguen naturalmente — no puedes tener un asistente de IA verdaderamente privado si todas tus notas y documentos viven en los servidores de un proveedor. La arquitectura de datos local-first y la inferencia de IA local son una pareja natural.
Segunda: fatiga de la nube y regulación de privacidad. Años de filtraciones de datos, políticas opacas de entrenamiento de IA y cierres de servicios han elevado el costo de la dependencia de la nube en la mente de los usuarios. El cumplimiento de GDPR, HIPAA y CCPA es dramáticamente más sencillo cuando los datos del usuario permanecen en sus dispositivos. Los equipos de salud, legal y servicios financieros se sienten cada vez más atraídos por las herramientas local-first precisamente porque simplifican el cálculo de cumplimiento normativo.
Tercera: rendimiento. La herramienta de gestión de proyectos de Linear — uno de los ejemplos más citados de arquitectura local-first — almacena sus datos principales en IndexedDB en el navegador y sincroniza en segundo plano. Cada acción es primero una escritura local. El resultado es una interfaz que se siente instantánea en comparación con las herramientas cloud-first que deben hacer un viaje de ida y vuelta al servidor en cada clic. Los equipos describen sistemáticamente Linear como la herramienta de gestión de proyectos más rápida que han usado. La velocidad, no la filosofía, es lo que hace que los usuarios se cambien.
El problema del modelo de negocio, y cómo se está resolviendo
La objeción obvia al software local-first desde una perspectiva empresarial: si los usuarios poseen sus datos y pueden exportarlos libremente, ¿por qué cobrar? Obsidian, la app local-first más exitosa por número de usuarios (más de un millón de usuarios activos), lo ha resuelto limpiamente. La app es gratuita y de código abierto. Las notas se almacenan como archivos Markdown planos que posees por completo. Obsidian Sync — un complemento opcional por $4 al mes — ofrece sincronización cifrada entre dispositivos. Pagas por el servicio, no por el bloqueo de datos. El modelo de negocio funciona porque el producto es excelente, no porque los usuarios estén atrapados.
ElectricSQL y PowerSync han optado por el modelo open-core: aloja el motor de sincronización tú mismo de forma gratuita, paga por la versión cloud gestionada. Linear cobra suscripciones por funciones para equipos e integraciones, no por la custodia de datos. El patrón está surgiendo: las empresas local-first cobran por conveniencia, fiabilidad y funciones de colaboración, no por retener tus datos como rehenes.
El ecosistema aún es temprano si se mide por la familiaridad general de los desarrolladores. Construir una aplicación local-first de producción requiere entender CRDTs, semántica de sincronización y resolución de conflictos a un nivel que la mayoría de los desarrolladores de aplicaciones no han necesitado antes. Las herramientas siguen mejorando, pero hay una razón por la que el ensayo de Ink & Switch comparaba el estado del desarrollo local-first en 2025 con React en 2013. La tecnología está lista. La documentación y la experiencia del desarrollador se están poniendo al día.