← Voltar ao blogue

Por que razão o ToolBerry dá prioridade ao modo offline

Imagine o seguinte. Chega a um local de trabalho nas traseiras de uma propriedade, depois de três curvas numa estrada de cascalho, e o seu sinal cai para uma barra. Abre o seu…

Por Equipa Toolberry10 Tempo de leitura:

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 adicioná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 possa continuar a trabalhar quando o sinal falha, mas, no momento em que perde a ligação, a experiência deteriora-se - as funcionalidades deixam de funcionar, os ecrãs ficam em branco e fica preocupado se o que escreveu irá sobreviver.

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 tenha cinco barras de LTE ou esteja sentado numa despensa na cave sem qualquer sinal, a aplicação comporta-se de forma idêntica.

O ToolBerry é do 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, há 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 de campo decorre 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 trabalhos - 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 eles tiverem uma falha de serviço, forem adquiridos, alterarem os seus preços ou decidirem 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 armazenados numa base de dados no teu dispositivo. Nós não os temos. Não podemos perdê-los, divulgá-los, vendê-los nem mantê-los como reféns. 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 -, essa é 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 no momento em 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 não nos custa, 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 a essência do que o plano gratuito pode ser. Em vez de uma versão de avaliação reduzida, concebida para o pressionar a atualizar em 30 dias, pode ser, na verdade, o produto completo para quem não precisa de sincronização em 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 entre dispositivos - 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 dólares por mês e vão até 250–500 dólares 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á ligado ao nosso

Quando a vossa 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 vosso 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 back-end prejudica a sincronização, não a própria aplicação. Continuas a trabalhar. A sincronização recupera mais tarde.

Amigo da bateria e do plano de dados

As aplicações que dão prioridade ao modo offline não estão constantemente a comunicar com um servidor. Sem sondagens em segundo plano, sem ligações de manutenção, sem «verificação de atualizações» a cada trinta segundos. Isso poupa discretamente a vossa bateria e o vosso plano de dados, especialmente se estiverem a partilhar a ligação à Internet enquanto viajam ou a utilizar um operador económico com um limite de dados restrito.

Sem registo, sem complicações

Isto não se deve estritamente ao facto de sermos «offline-first», mas só é possível porque o somos. Uma vez que os teus dados ficam armazenados 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 trabalhos.

O número de períodos de avaliação gratuita que as pessoas abandonam na página de registo é impressionante. Simplesmente removemos essa página.

As verdadeiras contrapartidas

A abordagem «offline-first» não é gratuita. Existem compromissos reais e preferimos ser claros sobre eles do que fingir que não existem.

A sincronização entre vários dispositivos é uma funcionalidade paga. Se quiser os mesmos dados no seu telemóvel, no seu tablet e no computador do escritório, precisa do nosso backup opcional baseado no Dropbox ou do nosso plano Team, que é pago. A sincronização em tempo real entre vários dispositivos requer um backend, e os backends custam dinheiro. 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 cliente leve. Vais notar isso uma 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 vos vamos dizer 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. Os dados que introduzem não desaparecem 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 é integrada de forma natural, não é uma funcionalidade acrescentada à força.

Se estiver a avaliar o 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.app.

Para os curiosos em termos técnicos

Se quiser compreender como isto está realmente construído, eis o que se passa nos bastidores.

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 isto com centenas de milhares de registos em telemóveis comuns e o desempenho mantém-se estável.

No iOS e Android nativos, o SQLite é acedido através das APIs padrão do sistema via Capacitor. No navegador/PWA, utilizamos uma versão do SQLite compilada para WebAssembly, armazenada em disco via 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 no fio 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 totalmente offline por definição. Os planos pagos incluem a sincronização, e a arquitetura é construída em torno do dispositivo como fonte autoritativa:

  1. Cada gravação vai primeiro para a base de dados SQLite local, de imediato, sem envolver a rede.
  2. As gravações são também registadas numa caixa de saída local.
  3. Quando o dispositivo está online e o utilizador está num plano pago, a caixa de saída é enviada para o nosso backend.
  4. 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. Isto significa que a aplicação local nunca fica bloqueada devido à 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 tradicional baseado em FSM 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 predominante.

O nível gratuito do ToolBerry é uma SPA estática servida a partir de uma CDN - os custos de largura de banda medem-se 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

Partilhar
XLinkedIn