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 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. Luego, una pantalla que dice «estás sin conexión». Y después, nada.

Ese momento es la razón por la que existe 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 contingencia para cuando las cosas van mal. ToolBerry es todo lo contrario. La red es el plan de contingencia. Tu dispositivo es la fuente de información fiable. A eso nos referimos con «offline-first», y no es una característica que hayamos añadido a posteriori: 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 «primero sin conexión»

Hay una distinción que conviene dejar clara 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 pierda 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 nerviosismo por si se ha perdido algo de 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 la caldera del sótano sin señal alguna, la aplicación se comporta exactamente igual.

ToolBerry pertenece al segundo tipo. Tus trabajos, clientes, obras, 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 cobertura 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 que prioriza el modo sin conexión eso no le importa.

Velocidad. Leer desde tu dispositivo local es aproximadamente mil veces más rápido que esperar a que el servidor responda. 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 donde 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 gratis de por vida para los autónomos, lo decimos en serio porque un usuario gratuito realmente no nos cuesta casi 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 el concepto mismo de lo que puede ser el nivel gratuito. En lugar de una versión de prueba recortada diseñada para empujarte a actualizarte 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 en tiempo real para tu equipo- 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 dólares al mes y llegan a entre 250 y 500 dólares 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 hay un contratiempo en el backend, 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. No hay conexiones de mantenimiento, ni «búsquedas de actualizaciones» cada treinta segundos. Si conectas Dropbox, Free lo comprueba al abrir la aplicación y cada 10 minutos mientras está abierta, además de en segundo plano según la programación de tu propio teléfono. Esto supone un alivio discreto para tu batería y tu plan de datos, especialmente si utilizas el tethering cuando estás de viaje o si tienes un operador económico con un límite de datos ajustado.

Sin registro, no hay complicaciones

Esto no se debe estrictamente a que prioricemos el modo sin conexión, 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 configuración. Abre la aplicación y empieza a añadir tareas.

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 en tiempo real del equipo es una función de pago. La versión gratuita mantiene tu teléfono, tu tableta y tu ordenador de la oficina sincronizados automáticamente a través de tu propia cuenta de Dropbox -ahora también en segundo plano- y un pequeño equipo puede compartir un espacio de trabajo mediante el almacenamiento compartido. La sincronización en tiempo real en nuestros servidores, con roles impuestos por el servidor y un registro de auditoría, forma parte de la versión Pro. Eso requiere un backend, y los backends cuestan dinero. No vamos a fingir lo contrario ocultando ese coste en la cuota mensual de todos.

Las copias de seguridad son tu responsabilidad en el plan gratuito. 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 se solucione (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 se pierden 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. Escríbenos a contact@toolberry.net.

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 consumo que utilizas a 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 iOS y Android nativos, se accede a SQLite a través de las API estándar del sistema mediante Capacitor. En el navegador o PWA, utilizamos una versión de SQLite compilada en WebAssembly, que se almacena en el 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 de cierta envergadura.
• IndexedDB es más potente, pero tiene una API notoriamente complicada, 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 plan gratuito están totalmente desconectados por diseño y sincronizan sus dispositivos a través de su propio Dropbox. Los planes de pago añaden sincronización en tiempo real en nuestros servidores, y la arquitectura se basa en que el dispositivo es la fuente de autoridad:

1. Cada escritura se envía primero a la base de datos SQLite local, de forma inmediata y sin intervención de la red.
2. Las escrituras también se registran en una bandeja de salida local.
3. Cuando el dispositivo está conectado y el usuario tiene un plan de pago, la bandeja de salida se vacía en nuestro backend.
4. 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 en la red, y la sincronización pasa a ser una tarea en segundo plano en lugar de un paso crítico.

Por qué la estructura de costes es tan diferente

Un SaaS tradicional de tipo «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 en 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