Por qué ToolBerry da prioridad al modo sin conexión
Imagínate esto. Llegas a una obra situada en la parte trasera de una propiedad, tras dar tres curvas por un camino de grava, y la señal de tu móvil se reduce a una barra. Abres tu…
Actualizado 26 de abril de 2026
Imagínate esto. Llegas a una obra situada en la parte trasera de una propiedad, tras dar tres curvas por un camino de grava, y tu señal se reduce a una barra. Abres tu aplicación de planificación para comprobar qué equipo te ha pedido el cliente que revises, y te aparece un cargador giratorio. A continuación, una pantalla que dice «estás sin conexión». Y luego, nada.
Ese momento es la razón de ser de ToolBerry.
La mayoría de las aplicaciones de servicios de campo tratan la red como si siempre estuviera ahí, y el «modo sin conexión» como si fuera un plan de respaldo para cuando las cosas van mal. ToolBerry es todo lo contrario. La red es el plan de respaldo. Tu dispositivo es la fuente de información fiable. Eso es lo que entendemos por «sin conexión primero», y no es una característica que hayamos añadido a posteriori: es lo que determina casi todas las decisiones que tomamos sobre el producto.
A continuación te explicamos por qué lo hemos diseñado así y qué significa realmente para ti.
Qué significa realmente «prioridad al modo sin conexión»
Hay una distinción que conviene aclarar desde el principio, ya que el término se utiliza de forma imprecisa.
Las aplicaciones «tolerantes a la desconexión» asumen que la nube es la fuente de verdad. Almacenan algunos datos en caché para que puedas seguir trabajando cuando se caiga la señal, pero en el momento en que pierdes la conexión, la experiencia se deteriora: las funciones dejan de funcionar, las pantallas se quedan en blanco y te entra el pánico pensando si se conservará lo que has escrito.
Las aplicaciones «offline-first» asumen que el dispositivo es la fuente de verdad. La nube es un destino de sincronización, no una dependencia. Tanto si tienes cinco barras de cobertura LTE como si estás en el cuarto de servicio del sótano sin señal alguna, la aplicación se comporta exactamente igual.
ToolBerry pertenece al segundo tipo. Tus trabajos, clientes, emplazamientos, contactos, activos y horarios residen en una base de datos real en tu teléfono, no en una caché ni en una cola a la espera de comunicarse con un servidor. Utilizamos SQLite, el mismo motor de base de datos que impulsa la mayoría de las aplicaciones que ya tienes en tu teléfono. Si tienes curiosidad, al final de esta entrada encontrarás más información sobre los aspectos técnicos.
Las razones obvias: velocidad y fiabilidad
Si llevas algún tiempo trabajando sobre el terreno, ya sabes lo siguiente:
La señal no es fiable, pero el trabajo sí lo es. Sótanos. Edificios industriales. Fincas rurales. Aparcamientos subterráneos. Cualquier lugar con paredes metálicas. El trabajo de campo se lleva a cabo en lugares que no se diseñaron pensando en las antenas de telefonía móvil. A una aplicación «offline-first» eso no le importa.
Velocidad. Leer desde tu dispositivo local es aproximadamente mil veces más rápido que esperar a que la señal vaya y vuelva del servidor. Cargar el historial de un cliente, acceder a una orden de trabajo, buscar entre cientos de trabajos: todo es instantáneo, porque no hay que recuperar nada. No hay estado de carga para tus propios datos. Simplemente se muestran.
Sin la ansiedad de «guardando…». Cada cambio que realizas se guarda en tu dispositivo de inmediato. Sin estados a medio guardar, sin «¿estás seguro de que quieres salir de esta página?», sin riesgo de perder lo que has escrito porque la conexión ha fallado momentáneamente.
Estas son las razones básicas. Son las que se esgrimen en todos los argumentos a favor del enfoque «offline-first». Las razones más interesantes son las menos obvias.
Las razones menos obvias (que podrían decirse que son las más importantes)
Tus datos son tuyos, no nuestros
La mayoría de las herramientas SaaS funcionan así: introduces el nombre, la dirección y el número de teléfono de tu cliente en un formulario, y esa información se envía a un servidor situado en el centro de datos de otra empresa. Estás confiando a esa empresa tus relaciones con los clientes, y si sufren una interrupción del servicio, son adquiridos, cambian sus tarifas o deciden utilizar tus datos de formas que no habías previsto, no tienes muchos recursos a los que recurrir.
El plan gratuito de ToolBerry invierte esa situación. Tus clientes, tus sitios web y tu historial de trabajos se almacenan en una base de datos en tu dispositivo. Nosotros no la tenemos. No podemos perderla, filtrarla, venderla ni retenerla como rehén. Si desapareciéramos mañana, tus datos seguirían estando en tu teléfono.
Para los autónomos y los pequeños equipos -especialmente en sectores en los que la lista de clientes es el negocio- eso supone una diferencia significativa. No estás alquilando el acceso a tu propia información.
«Gratis para siempre» es una característica estructural, no una promoción
Todas las herramientas de servicio de campo que has evaluado tienen un problema del que no hablan: cada usuario gratuito les cuesta dinero. Servidores, bases de datos, ancho de banda, asistencia técnica… todo suma. Por eso limitan estrictamente el nivel gratuito y te empujan hacia los planes de pago en cuanto empiezas a encontrar útil el producto. Heroku tenía un nivel gratuito famoso por su generosidad y acabó eliminándolo por completo en 2022 precisamente por esta razón.
Cuando decimos que ToolBerry es gratuito de por vida para los profesionales autónomos, lo decimos en serio porque un usuario gratuito realmente no nos cuesta prácticamente nada. No hay ningún servidor que almacene tus datos, ninguna base de datos por la que paguemos para mantenerla en funcionamiento, ni factura de infraestructura por usuario. La aplicación de tu dispositivo se encarga de todo.
Esto cambia la naturaleza del nivel gratuito. En lugar de una versión de prueba recortada diseñada para empujarte a pasarte a un plan superior en 30 días, puede ser, de hecho, el producto completo para quienes no necesitan sincronización en equipo. Te pasas a un plan superior cuando las necesidades de tu negocio cambian de verdad -cuando contratas a un segundo técnico, cuando quieres integración con QuickBooks, cuando necesitas sincronización entre dispositivos- y no porque te hayamos limitado artificialmente. El modelo de pago se adapta al crecimiento de tu negocio, no a nuestra factura de servidores.
A modo de referencia: los precios habituales de la competencia en el sector de la gestión de servicios de campo (FSM) parten de unos 169 $ al mes y llegan a entre 250 y 500 $ por técnico al mes en el segmento empresarial. Podemos ser mucho más baratos porque nuestra estructura de costes es radicalmente diferente.
Tu tiempo de actividad no depende del nuestro
Cuando tu aplicación de planificación deja de funcionar durante dos horas un martes por la mañana, todo el equipo se queda atascado. Todos habéis creado flujos de trabajo en torno a una herramienta que, de repente, ya no está disponible. Con el plan gratuito de ToolBerry, este tipo de problema no existe: la aplicación de tu móvil sigue funcionando independientemente de lo que ocurra por nuestra parte.
Incluso en los planes de pago, donde la sincronización entra en juego, el modelo «local primero» implica que, si se produce un fallo en el servidor, lo que se ve afectado es la sincronización, no la aplicación en sí. Tú sigues trabajando. La sincronización se pone al día más tarde.
Ahorra batería y datos
Las aplicaciones que dan prioridad al modo sin conexión no se comunican constantemente con un servidor. Sin sondeos en segundo plano, sin conexiones de mantenimiento, sin «buscar actualizaciones» cada treinta segundos. Esto supone un alivio silencioso para tu batería y tu plan de datos, especialmente si utilizas el tethering mientras viajas o si tienes un operador económico con un límite de datos ajustado.
Sin registro, sin complicaciones
Esto no se debe estrictamente a que seamos una aplicación «offline-first», pero solo es posible gracias a ello. Como tus datos se almacenan en tu dispositivo, no necesitamos una cuenta en el servidor para identificarte, lo que significa que no hay correo electrónico, ni contraseña, ni verificación por SMS, ni asistente de registro. Abre la aplicación y empieza a añadir trabajos.
El número de pruebas gratuitas que la gente abandona en la pantalla de registro es abrumador. Simplemente hemos eliminado esa pantalla.
Las ventajas y desventajas reales
El enfoque «offline-first» no es gratuito. Hay compensaciones reales, y preferimos ser sinceros al respecto antes que fingir que no existen.
La sincronización entre varios dispositivos es una función de pago. Si quieres tener los mismos datos en tu teléfono, tu tableta y el ordenador de la oficina, necesitas nuestra copia de seguridad opcional basada en Dropbox o nuestro plan Team de pago. La sincronización en tiempo real entre varios dispositivos requiere un servidor, y los servidores cuestan dinero. No vamos a fingir lo contrario ocultando ese coste en la cuota mensual de todos.
En el plan gratuito, las copias de seguridad son tu responsabilidad. Si pierdes tu teléfono y no has conectado Dropbox ni te has pasado a un plan superior, perderás tus datos, igual que si perdieras un cuaderno de papel. Facilitamos que esto sea fácil de evitar (la copia de seguridad en Dropbox es gratuita y se configura en unos treinta segundos), pero queremos que sepas que existe.
El tamaño inicial de la aplicación es mayor. «Offline-first» significa que incluimos el motor de base de datos, tu esquema completo y la infraestructura suficiente para funcionar de forma independiente. La aplicación ocupa unos pocos megabytes más que un cliente ligero equivalente. Lo notarás una sola vez, al instalarla.
Los modos privado o de incógnito del navegador lo bloquean. Los navegadores impiden intencionadamente el almacenamiento local persistente en los modos privados, lo que significa que ToolBerry no puede guardar nada en esas ventanas. Hemos escrito sobre esto por separado -hay una entrada dedicada al tema-, pero merece la pena señalarlo aquí para ofrecer una visión honesta.
Algunas funciones avanzadas realmente necesitan un backend. La coordinación de equipos en tiempo real, las vistas de los coordinadores, el enrutamiento de órdenes de trabajo entre clientes y las integraciones contables: estas no son funciones que estemos reservando tras un muro de pago como un simple truco. De hecho, requieren un servidor. El enfoque «offline-first» resuelve una gran parte de los problemas, pero no es una solución universal, y no vamos a decirte que lo sea.
Qué significa esto para ti
Si gestionas trabajos desde una furgoneta: ToolBerry funciona igual tanto si estás aparcado en un garaje del centro de la ciudad como si te encuentras en una finca rural sin cobertura. No hay que preocuparse por ningún modo «en línea» o «sin conexión»: solo está la aplicación, y funciona.
Si gestionas la programación, el envío de trabajos o las operaciones desde una oficina: el modelo «local-first» significa que el personal sobre el terreno puede confiar realmente en la herramienta que les proporcionas. Sus entradas de datos no desaparecen en una cola de sincronización que no puedes auditar. Su aplicación no se bloquea cuando la conexión falla momentáneamente. Y cuando estés listo para coordinar a todo un equipo, los planes de pago se basan en los mismos cimientos: la sincronización se integra de forma natural, no se añade a posteriori.
Si estás comparando ToolBerry con los líderes del mercado: la arquitectura pertenece a una categoría diferente, no es una mejora incremental. El modelo de costes, la política de privacidad y la fiabilidad sobre el terreno se derivan todos de la misma decisión fundamental. Vale la pena sopesarlo con cuidado.
¿Tienes alguna pregunta?
Siempre estaremos encantados de explicarte cómo funciona esto en tu situación concreta. Ponte en contacto con nosotros en contact@toolberry.app.
Para los curiosos en materia técnica
Si quieres entender cómo está construido realmente, aquí tienes una visión de cómo funciona por dentro.
SQLite en el dispositivo
ToolBerry utiliza SQLite como base de datos local: el mismo motor que viene integrado en iOS, Android, Chrome, Firefox, macOS y la mayoría de las aplicaciones de uso diario. No es una caché. No es localStorage. Es una auténtica base de datos relacional con soporte completo de SQL: uniones, transacciones, índices, claves externas, todo lo necesario. Lo hemos probado con cientos de miles de registros en teléfonos comunes y el rendimiento se mantiene estable.
En las versiones nativas de iOS y Android, se accede a SQLite a través de las API estándar del sistema mediante Capacitor. En el navegador o en la PWA, utilizamos una versión de SQLite compilada en WebAssembly, que se almacena en disco a través de OPFS (Origin Private File System), una API de navegador relativamente nueva diseñada precisamente para este tipo de uso.
¿Por qué SQLite en lugar de IndexedDB o localStorage?
La mayoría de las aplicaciones web con modo sin conexión utilizan IndexedDB o localStorage. Ambas tienen limitaciones:
- localStorage es un almacén de clave-valor con un límite estricto de unos 5 MB y E/S síncrona en el hilo principal. Inutilizable para cualquier conjunto de datos significativo.
- IndexedDB es más potente, pero tiene una API notoriamente engorrosa, no admite SQL, presenta una consistencia entre navegadores deficiente y tiene problemas de fiabilidad conocidos.
- SQLite sobre OPFS nos ofrece SQL auténtico, transacciones reales, un comportamiento predecible en todas las plataformas y la misma capa de consultas que compartimos con nuestro backend. Es la única opción que se adapta a un conjunto de datos de producción real sin comprometer la calidad.
Cómo encaja (eventualmente) la sincronización
Los usuarios del nivel gratuito están totalmente desconectados por diseño. Los niveles de pago añaden la sincronización, y la arquitectura se basa en que el dispositivo es la fuente de autoridad:
- Cada escritura se envía primero a la base de datos SQLite local, de forma inmediata y sin intervención de la red.
- Las escrituras también se registran en una bandeja de salida local.
- Cuando el dispositivo está conectado y el usuario tiene un plan de pago, la bandeja de salida se vacía en nuestro backend.
- Los cambios procedentes de otros dispositivos llegan en forma de flujo y se fusionan con la base de datos local.
Este es el mismo patrón general que utilizan Linear y la mayoría de las aplicaciones colaborativas modernas que dan prioridad a lo local. Esto significa que la aplicación local nunca se bloquea por la red, y la sincronización pasa a ser una cuestión de fondo en lugar de una ruta crítica.
Por qué la estructura de costes es tan diferente
Un SaaS tradicional de modelo FSM aloja los datos de cada cliente en una base de datos central, ejecuta servidores API por cada solicitud y paga por el almacenamiento, la potencia de cálculo y el ancho de banda en cada interacción. El coste marginal por usuario gratuito es real y, a gran escala, resulta determinante.
El nivel gratuito de ToolBerry es una SPA estática servida desde una CDN -los costes de ancho de banda se miden en fracciones de céntimo por usuario- y todos los datos residen en los dispositivos de los usuarios. No tenemos que alojar nada más allá del propio paquete de la aplicación. Los niveles de pago reintroducen la infraestructura de backend para la sincronización y las integraciones, pero solo para los usuarios que realmente la necesitan.
Esta es la razón estructural por la que «gratis para siempre» nos funciona a nosotros, mientras que a Heroku no le funcionó. Ellos pagaban costes reales de infraestructura por usuario e intentaban recuperarlos mediante la conversión. Nosotros no.
Más información
- Por qué ToolBerry no funciona en modo incógnito o privado: la salvedad del navegador al detalle
- SQLite: cuándo utilizarlo
- MDN: sistema de archivos privado de origen
- Software «Local-First»: tus datos te pertenecen, a pesar de la nube - el argumento académico a favor de este patrón arquitectónico