Soberania de dados

Existe uma pergunta que deveria ser a primeira de toda avaliação de software, e que quase nunca é feita: se eu quiser sair desta ferramenta amanhã, o que, exatamente, eu consigo levar comigo?

A pergunta é desconfortável porque a resposta honesta da maioria das ferramentas é "menos do que você imagina". E ela é evitada porque, no dia em que você contrata, sair é a última coisa em que você pensa. Mas é justamente nesse dia — o da contratação — que a sua capacidade de sair é definida. Depois, é tarde.

Este artigo é sobre soberania de dados: o que significa ser de fato dono dos dados da sua operação, por que quase nenhum SaaS oferece isso, e por que o modelo de arquivo único da LaunchWithAgency oferece — não como uma promessa de marketing, mas como uma consequência da arquitetura.

O lock-in não é um plano maligno. É a forma do produto.

É tentador imaginar o aprisionamento de dados como uma decisão deliberada e cínica de um fornecedor. Quase nunca é. O lock-in é, na esmagadora maioria dos casos, simplesmente a forma natural de um SaaS comum.

Pense em como esses produtos são construídos. Os seus dados vivem num banco de dados que pertence ao fornecedor, numa infraestrutura que pertence ao fornecedor, num schema que só o código do fornecedor sabe interpretar. Você nunca toca nesse banco. Você o acessa através da interface e, se tiver sorte, de uma API e de um botão de "exportar".

E é aí que a soberania escorre pelos dedos. O export quase sempre te dá um subconjunto: os contatos, talvez, mas não os logs de envio; os posts, talvez, mas não o histórico de versões; as listas, mas não as automações, os eventos, os estados intermediários. Você recebe um retrato dos seus dados, achatado em alguns CSVs, e perde tudo o que era relação entre eles — porque a relação vivia no schema do fornecedor, e o schema não vem no export. Sair, na prática, é recomeçar com fragmentos.

Repare que ninguém precisou ser malicioso para isso acontecer. Bastou a forma padrão: o banco é deles, o schema é deles, você é visita.

> Lock-in raramente é uma cláusula no contrato. É uma propriedade da arquitetura — e por isso ele é decidido na fundação do produto, não na sua negociação de saída.

A inversão da LaunchWithAgency: o banco é um arquivo, e o arquivo é seu

A LaunchWithAgency parte de um modelo diferente, e a diferença é concreta, não retórica.

A operação inteira — os cinco produtos, News, Blogs, Pages, Flows, Emails — vive em um banco SQLite. E um banco SQLite é um arquivo. data/local.db. Não é um banco abstrato escondido atrás de uma API; é um arquivo, um objeto que existe, que pode ser copiado, aberto, lido.

Pense no que esse fato simples implica para cada uma das operações que definem soberania.

Backup. Fazer backup da sua operação inteira é copiar um arquivo. Não é exportar de cinco ferramentas, achatar em CSVs e torcer para que esteja tudo lá. É cp local.db. Os assinantes, os posts, as landing pages, as automações e seus históricos de execução, os logs de email e seus eventos — tudo, na sua forma relacional completa, num movimento.

Inspeção. Você não depende da interface para saber o que o sistema sabe sobre você. SQLite é um formato aberto, padronizado, com ferramentas livres em qualquer sistema operacional. Você pode abrir o seu banco e rodar SELECT * FROM newsletter_subscribers com as próprias mãos. O README do projeto sequer esconde isso — ele te mostra os comandos. A transparência não é uma feature; é o formato.

Portabilidade. Como SQLite é um padrão aberto, e como o schema é declarativo e legível — as tabelas que descrevemos na série inteira são arquivos JavaScript curtos —, os seus dados não estão num formato proprietário. Eles estão num banco que mil outras ferramentas sabem ler, com uma estrutura que você pode inspecionar. Sair não é recomeçar com fragmentos. É levar o arquivo.

Soberania não é um recurso. É a ausência de uma barreira.

Aqui está a parte sutil. A LaunchWithAgency não oferece soberania de dados como um recurso que ela adicionou — uma caixa marcada numa lista de funcionalidades. Isso seria suspeito, porque um recurso adicionado pode ser um recurso removido.

A LaunchWithAgency oferece soberania porque ela não construiu a barreira que tira a soberania das outras ferramentas. As outras ferramentas não aprisionam seus dados por acréscimo; elas aprisionam por omissão — por nunca terem te dado o banco. A LaunchWithAgency te dá o banco. A soberania não é algo que foi posto; é algo que nunca foi tirado.

Os princípios declarados do projeto dizem isso com todas as letras: "Você é o dono dos dados. Um arquivo SQLite. Seus assinantes, posts e logs num lugar que você pode inspecionar, fazer backup e levar embora. Sem reféns." A frase "sem reféns" não é uma promessa de boa conduta — é a descrição de um fato arquitetural. Não há como manter refém quem segura o próprio arquivo.

Por que isso pertence à mesma história dos outros nove artigos

Quem leu esta série inteira já viu o padrão. O banco único elimina os silos. A automação-nativa elimina a cola frágil. O i18n no schema elimina o remendo de tradução. E agora: o arquivo único elimina o lock-in.

É sempre o mesmo movimento. A LaunchWithAgency não resolve esses problemas adicionando um recurso que os combate. Ela os resolve recusando, na fundação, a decisão de arquitetura que os cria. O silo, a cola, o remendo e o lock-in não são quatro problemas diferentes — são quatro sintomas da mesma doença: dados fragmentados, presos, atrás de fronteiras que pertencem a outra pessoa.

Um banco. Um arquivo. Seu. Essa é a frase que sustenta a suíte inteira — e a soberania de dados é só o nome que ela tem quando você faz a pergunta que ninguém faz: e se eu quiser sair amanhã? Na LaunchWithAgency, você leva o arquivo, e o arquivo é tudo.