Por que razão o ToolBerry privilegia o modo offline
Imagine o seguinte. Chega a um local de trabalho nas traseiras de uma propriedade, após três curvas numa estrada de cascalho, e o sinal do telemóvel cai para uma barra. Abre o seu…
26 de abril de 2026 atualizado

Imagine o seguinte. Chega ao local de trabalho nas traseiras de uma propriedade, após três curvas numa entrada de cascalho, e o seu sinal cai para uma barra. Abre a sua aplicação de agendamento para verificar que equipamento o cliente lhe pediu para verificar - e aparece um ícone a girar. Depois, um ecrã a indicar «está offline». E depois, nada.
Esse momento é a razão de ser da ToolBerry.
A maioria das aplicações de serviços no terreno trata a rede como se estivesse sempre presente e o «modo offline» como se fosse um plano de contingência para quando as coisas correm mal. O ToolBerry é o oposto. A rede é o plano de contingência. O teu dispositivo é a fonte de verdade. É isso que entendemos por «offline-first», e não é uma funcionalidade que acrescentámos à última da hora - molda quase todas as decisões que tomamos sobre o produto.
Eis porque o criámos assim e o que isso realmente significa para si.
O que «offline-first» significa realmente
Há uma distinção que vale a pena fazer desde já, porque o termo é usado de forma imprecisa.
As aplicações «tolerantes ao modo offline» partem do princípio de que a nuvem é a fonte de verdade. Elas armazenam alguns dados em cache para que possas continuar a trabalhar quando o sinal falhar, mas, no momento em que perdes a ligação, a experiência deteriora-se - as funcionalidades deixam de funcionar, os ecrãs ficam em branco e ficas preocupado se o que escreveste irá permanecer.
As aplicações «offline-first» partem do princípio de que o dispositivo é a fonte de verdade. A nuvem é um destino de sincronização, não uma dependência. Quer tenhas cinco barras de LTE ou estejas sentado numa despensa na cave sem qualquer sinal, a aplicação comporta-se exatamente da mesma forma.
O ToolBerry pertence ao segundo tipo. Os teus trabalhos, clientes, locais, contactos, ativos e horários residem numa base de dados real no teu telemóvel - não num cache, nem numa fila à espera de comunicar com um servidor. Utilizamos o SQLite, o mesmo motor de base de dados que alimenta a maioria das aplicações já instaladas no teu telemóvel. Se estiver curioso, encontrará mais informações técnicas no final desta publicação.
As razões óbvias: velocidade e fiabilidade
Se já trabalha no terreno há algum tempo, já sabe isto:
O teu sinal não é fiável, mas o trabalho é. Caves. Edifícios industriais. Propriedades rurais. Parques de estacionamento subterrâneos. Qualquer lugar com paredes metálicas. O trabalho no terreno ocorre em locais que não foram concebidos a pensar em torres de telemóvel. Uma aplicação que funciona primeiro offline não se importa com isso.
Velocidade. Ler a partir do seu dispositivo local é cerca de mil vezes mais rápido do que esperar pela resposta de um servidor. Carregar o histórico de um cliente, aceder a uma ordem de trabalho, pesquisar entre centenas de tarefas - tudo é instantâneo, porque nada está a ser buscado. Não há estado de carregamento para os seus próprios dados. Simplesmente aparecem.
Sem a ansiedade do «a guardar…». Cada alteração que faz é gravada no seu dispositivo imediatamente. Sem estados parcialmente guardados, sem «tem a certeza de que quer sair desta página?», sem risco de perder o que escreveu por causa de uma falha momentânea na ligação.
Estas são as razões básicas. São aquelas com que todas as apresentações sobre a abordagem «offline-first» começam. As razões mais interessantes são as menos óbvias.
As razões menos óbvias (que são, sem dúvida, as mais importantes)
Os teus dados são teus, não nossos
A maioria das ferramentas SaaS funciona assim: introduz o nome, a morada e o número de telefone do seu cliente num formulário, e essa informação é enviada para um servidor no centro de dados de outra entidade. Estás a confiar as tuas relações com os clientes a essa empresa - e se ela sofrer uma falha de serviço, for adquirida, alterar os seus preços ou decidir utilizar os teus dados de formas que não previste, não tens muitos meios de recurso.
O plano gratuito do ToolBerry inverte essa situação. Os teus clientes, locais e histórico de trabalhos ficam numa base de dados no teu dispositivo. Nós não a temos. Não podemos perdê-la, divulgá-la, vendê-la ou mantê-la como refém. Se desaparecêssemos amanhã, os teus dados continuariam no teu telemóvel.
Para profissionais independentes e pequenas equipas - especialmente em setores onde a lista de clientes é o próprio negócio - isso representa uma diferença significativa. Não estás a alugar o acesso às tuas próprias informações.
«Gratuito para sempre» é uma característica estrutural, não promocional
Todas as ferramentas de serviço de campo que já avaliou têm um problema de que não falam: cada utilizador gratuito custa-lhes dinheiro. Servidores, bases de dados, largura de banda, assistência - tudo isso se soma. Por isso, limitam rigorosamente o nível gratuito e empurram-no para planos pagos assim que começa a achar o produto útil. A Heroku tinha um nível gratuito famoso pela sua generosidade e acabou por o eliminar por completo em 2022 exatamente por esta razão.
Quando dizemos que o ToolBerry é gratuito para sempre para profissionais independentes, podemos afirmá-lo com toda a convicção, porque um utilizador gratuito custa-nos, na verdade, quase nada. Não há servidor a armazenar os seus dados, nem base de dados pela qual paguemos para manter em funcionamento, nem custos de infraestrutura por utilizador. A aplicação no seu dispositivo é que faz o trabalho.
Isso muda o que o plano gratuito pode ser. Em vez de uma versão de avaliação reduzida, concebida para o pressionar a fazer o upgrade em 30 dias, pode ser, na verdade, o produto completo para quem não precisa de sincronização de equipa. Faz a atualização quando as necessidades do negócio mudarem genuinamente - quando contratar um segundo técnico, quando quiser integração com o QuickBooks, quando precisar de sincronização em tempo real da equipa - e não porque o limitámos artificialmente. O modelo de pagamento está alinhado com o crescimento do seu negócio, não com a nossa conta do servidor.
A título de referência: os preços típicos dos concorrentes de FSM começam em cerca de 169 $/mês e vão até 250–500 $ por técnico por mês no segmento empresarial. Conseguimos ser radicalmente mais baratos porque a nossa estrutura de custos é radicalmente diferente.
O seu tempo de atividade não está vinculado ao nosso
Quando a sua aplicação de agendamento fica indisponível durante duas horas numa terça-feira de manhã, toda a equipa fica paralisada. Todos criaram fluxos de trabalho em torno de uma ferramenta que, de repente, deixa de estar disponível. Com o plano gratuito da ToolBerry, este tipo de problema não existe - a aplicação no seu telemóvel continua a funcionar, independentemente do que estiver a acontecer do nosso lado.
Mesmo nos planos pagos, onde a sincronização faz parte do pacote, o modelo «local-first» significa que uma falha no backend afeta a sincronização, não a própria aplicação. Continuas a trabalhar. A sincronização recupera mais tarde.
Poupa bateria e dados
As aplicações que dão prioridade ao modo offline não estão constantemente a comunicar com um servidor. Sem ligações de manutenção, sem «verificação de atualizações» a cada trinta segundos. Se ligares o Dropbox, o Free verifica-o quando abres a aplicação e a cada 10 minutos enquanto estiver aberta, e em segundo plano, de acordo com a programação do teu próprio telemóvel. Isso poupa discretamente a tua bateria e o teu plano de dados, especialmente se estiveres a partilhar a ligação à Internet enquanto viajas ou a utilizar um operador económico com um limite de dados restrito.
Sem registo, não há complicações
Isto não se deve estritamente ao facto de darmos prioridade ao modo offline, mas só é possível porque é assim que funcionamos. Uma vez que os teus dados ficam no teu dispositivo, não precisamos de uma conta no servidor para te identificar - o que significa que não há e-mail, nem palavra-passe, nem verificação por SMS, nem assistente de configuração. Abre a aplicação e começa a adicionar tarefas.
O número de períodos de teste gratuito que as pessoas abandonam no ecrã de registo é impressionante. Simplesmente removemos esse ecrã.
As verdadeiras contrapartidas
A abordagem «offline-first» não é gratuita. Existem compromissos reais e preferimos ser sinceros sobre eles do que fingir que não existem.
A sincronização em tempo real da equipa é uma funcionalidade paga. A versão gratuita mantém o teu telemóvel, o teu tablet e o teu computador do escritório sincronizados automaticamente através do teu próprio Dropbox - agora também em segundo plano - e uma pequena equipa pode partilhar um espaço de trabalho através do armazenamento partilhado. A sincronização em tempo real nos nossos servidores, com funções definidas pelo servidor e um registo de auditoria, faz parte do plano Pro. Isso requer um backend, e os backends têm um custo. Não vamos fingir o contrário, ocultando esse custo na mensalidade de todos.
Os backups são da sua responsabilidade no plano gratuito. Se perder o telemóvel e não tiver ligado o Dropbox nem feito o upgrade, os seus dados desaparecem com ele - tal como se tivesse perdido um caderno de papel. Facilitamos a resolução deste problema (o backup no Dropbox é gratuito e demora cerca de trinta segundos a configurar), mas queremos que saiba que isso acontece.
O tamanho inicial da aplicação é maior. «Offline-first» significa que incluímos o motor de base de dados, o teu esquema completo e infraestrutura suficiente para funcionar de forma independente. A aplicação é alguns megabytes maior do que um equivalente de «thin-client». Vais notar isso uma única vez, na instalação.
Os modos privado/incógnito do navegador bloqueiam a aplicação. Os navegadores impedem intencionalmente o armazenamento local persistente nos modos privados, o que significa que o ToolBerry não consegue guardar nada nessas janelas. Já escrevemos sobre isto separadamente - há uma publicação dedicada ao assunto -, mas vale a pena referi-lo aqui como parte de uma visão honesta da situação.
Algumas funcionalidades avançadas necessitam genuinamente de um backend. Coordenação de equipa em tempo real, visualizações do despachante, encaminhamento de ordens de trabalho entre clientes, integrações de contabilidade - estas não são funcionalidades que estejamos a reter atrás de um paywall como um artifício. Elas requerem, de facto, um servidor. A abordagem «offline-first» resolve uma grande parte do problema, mas não é uma resposta universal, e não vamos dizer-vos que o é.
O que isto significa para si
Se geres trabalhos a partir de uma carrinha: o ToolBerry funciona da mesma forma, quer estejas estacionado numa garagem no centro da cidade ou numa propriedade rural sem rede. Não há modo online ou offline a ter em conta - há apenas a aplicação, e ela funciona.
Se gere agendamentos, expedições ou operações a partir de um escritório: o modelo «local-first» significa que as pessoas no terreno podem realmente confiar na ferramenta que lhes está a fornecer. A introdução de dados não desaparece numa fila de sincronização que não pode auditar. A aplicação não bloqueia quando a ligação falha momentaneamente. E quando estiver pronto para coordenar toda a equipa, os planos pagos assentam na mesma base - a sincronização é uma camada integrada, não uma funcionalidade acrescentada à força.
Se estiver a avaliar a ToolBerry em comparação com os operadores estabelecidos: a arquitetura pertence a uma categoria diferente, não se trata de uma melhoria incremental. O modelo de custos, a postura em matéria de privacidade e a fiabilidade no terreno decorrem todos da mesma decisão central. Vale a pena ponderar isto cuidadosamente.
Tem alguma dúvida?
Temos sempre todo o gosto em explicar como isto funciona na sua situação específica. Contacte-nos através do e-mail contact@toolberry.net.
Para os curiosos em termos técnicos
Se quiser compreender como isto está realmente construído, eis o que se passa por baixo do capô.
SQLite no dispositivo
O ToolBerry utiliza o SQLite como base de dados local - o mesmo motor que vem integrado no iOS, Android, Chrome, Firefox, macOS e na maioria das aplicações de consumo que utiliza diariamente. Não é uma cache. Não é o localStorage. É uma verdadeira base de dados relacional com suporte completo a SQL: junções, transações, índices, chaves estrangeiras, tudo o que é necessário. Testámos-a com centenas de milhares de registos em telemóveis comuns e o desempenho mantém-se estável.
No iOS e no Android nativos, o SQLite é acedido através das APIs padrão do sistema via Capacitor. No navegador/PWA, utilizamos uma compilação do SQLite para WebAssembly, armazenada em disco através do OPFS (Origin Private File System) - uma API de navegador relativamente nova, concebida precisamente para este tipo de caso de utilização.
Porquê o SQLite em vez do IndexedDB ou do localStorage
A maioria das aplicações web com modo offline utiliza o IndexedDB ou o localStorage. Ambos têm limitações:
- o localStorage é um armazenamento de chave-valor com um limite rígido de cerca de 5 MB e E/S síncrona na thread principal. Inutilizável para qualquer conjunto de dados significativo.
- O IndexedDB é mais capaz, mas tem uma API notoriamente complicada, não suporta SQL, apresenta fraca consistência entre navegadores e tem problemas de fiabilidade conhecidos.
- O SQLite, em vez do OPFS, oferece-nos SQL verdadeiro, transações reais, comportamento previsível em todas as plataformas e a mesma camada de consultas que partilhamos com o nosso backend. É a única opção que se adapta a um conjunto de dados de produção real sem comprometer a qualidade.
Como a sincronização (eventualmente) se encaixa
Os utilizadores do plano gratuito estão, por definição, totalmente offline e sincronizam os seus dispositivos através do seu próprio Dropbox. Os planos pagos adicionam sincronização em tempo real nos nossos servidores, e a arquitetura é construída com base no dispositivo como fonte autoritativa:
- Cada gravação vai primeiro para a base de dados SQLite local, de imediato, sem envolver a rede.
- As gravações também são registadas numa caixa de saída local.
- Quando o dispositivo está online e o utilizador tem um plano pago, a caixa de saída é enviada para o nosso backend.
- As alterações provenientes de outros dispositivos chegam como um fluxo e são integradas na base de dados local.
Este é o mesmo padrão geral utilizado pelo Linear e pela maioria das aplicações colaborativas modernas que dão prioridade ao local. Significa que a aplicação local nunca fica bloqueada na rede, e a sincronização passa a ser uma preocupação em segundo plano, em vez de um caminho crítico.
Por que razão a estrutura de custos é tão diferente
Um SaaS FSM tradicional hospeda os dados de cada cliente numa base de dados central, executa servidores API por pedido e paga pelo armazenamento, computação e largura de banda em cada interação. O custo marginal por utilizador gratuito é real e, em grande escala, torna-se dominante.
O nível gratuito da ToolBerry é uma SPA estática servida a partir de uma CDN - os custos de largura de banda são medidos em frações de um cêntimo por utilizador - e todos os dados residem nos dispositivos dos utilizadores. Não há nada que tenhamos de alojar para além do próprio pacote da aplicação. Os níveis pagos reintroduzem infraestrutura de back-end para sincronização e integrações, mas apenas para os utilizadores que realmente precisam dela.
Esta é a razão estrutural pela qual o modelo «grátis para sempre» funciona para nós, ao passo que não funcionou para a Heroku. Eles estavam a pagar custos reais de infraestrutura por utilizador e a tentar recuperá-los através da conversão. Nós não.
Leitura adicional
- Por que é que o ToolBerry não funciona no modo de navegação anónima ou privada - a ressalva do navegador em detalhe
- SQLite - Quando utilizar
- MDN - Origin Private File System
- Software «Local-First» - Os teus dados pertencem-te, apesar da nuvem - o argumento académico a favor deste padrão de arquitetura
