Um banco para cinco produtos

Existe uma pergunta que separa as ferramentas de marketing em duas categorias, e quase ninguém faz essa pergunta na hora de contratar: onde, fisicamente, os dados desta ferramenta vivem — e quem mais consegue lê-los sem pedir licença?

A resposta padrão da indústria é desconfortável quando você a escreve por extenso. O seu assinante de newsletter vive no banco do Mailchimp. O lead que preencheu a landing page vive no banco do Webflow. O destinatário do email transacional de boas-vindas vive no banco do Postmark. O post do blog que esse mesmo lead leu antes de converter vive no banco do Ghost. Quatro pessoas? Não — quase sempre uma pessoa só, registrada quatro vezes, em quatro bancos que não se conhecem, sob quatro contratos diferentes.

A LaunchWithAgency começa recusando essa fragmentação na camada mais profunda possível: a do armazenamento. Os cinco produtos — News, Blogs, Pages, Flows e Emails — não são cinco aplicativos que "se integram". São cinco superfícies de um único banco de dados SQLite. Este artigo explica por que essa escolha existe, como ela é implementada e o que ela muda para quem opera.

O problema não é o número de ferramentas. É o número de bancos.

É tentador descrever o problema do stack moderno como "ferramentas demais". Não é bem isso. O problema é mais específico e mais corrosivo: cada ferramenta carrega seu próprio banco de dados privado, e a fronteira entre esses bancos é onde a sua operação sangra tempo.

Pense no que acontece quando você quer responder uma pergunta simples — "quantos dos assinantes que entraram pela landing de Black Friday abriram o email da semana seguinte?". Essa pergunta cruza três bancos: o da landing (quem entrou), o da newsletter (quem é assinante) e o do transacional (quem abriu). Nenhuma das três ferramentas pode respondê-la sozinha, porque nenhuma das três tem os dados completos. Você acaba exportando três CSVs, abrindo o Excel, e fazendo PROCV por endereço de email — um JOIN manual entre bancos que deveriam ser o mesmo banco.

Esse PROCV é o sintoma. A doença é arquitetural: você está pagando cinco fornecedores para manterem cinco cópias parciais e dessincronizadas da mesma realidade.

A inversão: um schema, um arquivo, cinco produtos

A LaunchWithAgency inverte a ordem da construção. Em vez de "primeiro o produto, depois um banco para ele", a fundação é o banco — e os produtos crescem como vistas diferentes sobre ele.

Concretamente: existe um arquivo, data/local.db, um banco SQLite. Dentro dele convivem as tabelas de todos os cinco produtos. As listas e assinantes da newsletter (newsletter_lists, newsletter_subscribers). Os blogs e posts (blogs, blog_posts). As landing pages (landing_pages). As automações e seus históricos de execução (flows, flow_runs). Os templates, logs e eventos de email (email_templates, email_logs, email_events). E, atravessando todas elas, a tabela users do sistema de autenticação.

A consequência mais importante dessa decisão aparece nas chaves estrangeiras entre tabelas de produtos diferentes. Quando um blog pode declarar attachedNewsletterId apontando diretamente para uma linha de newsletter_lists, isso não é uma "integração". É o banco relacional fazendo o que bancos relacionais fazem: garantindo, na camada de armazenamento, que o blog e a newsletter falam da mesma entidade. Não há sincronização porque não há nada a sincronizar — há um dado só.

> Integração, na maioria das ferramentas, é um botão escrito "conectar". Aqui, integração é o fato de não existir botão nenhum: os produtos nascem na mesma tabela.

O que isso muda na prática

A teoria de arquitetura só importa se ela muda o seu dia. Muda — em pelo menos quatro lugares concretos.

O lead já é o assinante. Quando alguém preenche uma landing page do produto Pages, o registro dessa pessoa não precisa ser "empurrado" para a newsletter por uma integração. Pages e News leem e escrevem o mesmo banco. O lead capturado é, no mesmo instante e sem nenhum passo intermediário, uma linha que a newsletter enxerga. O export/import entre captura e nutrição simplesmente deixa de existir.

A automação vê tudo. O produto Flows não precisa de credenciais de API para "olhar" os outros produtos. Uma automação que dispara quando alguém assina a newsletter não consome um webhook de terceiros — ela reage a um evento interno (newsletter.subscribed) registrado na tabela flow_events, no mesmo banco. Não há uma integração que possa quebrar silenciosamente, porque não há integração: há uma consulta SQL.

O contexto é completo num lugar só. Como os dados não estão espalhados, o dashboard pode mostrar o quadro inteiro de uma campanha — landing, captura, nutrição, envio — sem juntar fontes. A pergunta do PROCV lá de cima vira uma consulta que cruza tabelas vizinhas do mesmo arquivo.

Uma fatura, um fornecedor, um backup. Cinco mensalidades crescendo em paralelo viram uma. E, talvez mais importante: o seu backup é um arquivo. Copiar local.db é copiar a operação inteira — assinantes, posts, automações e logs — em um movimento só.

A honestidade sobre os limites

Uma decisão de arquitetura séria também precisa declarar onde aperta. SQLite é um banco de arquivo único — ele brilha em leitura concorrente e em simplicidade operacional, e é por isso que ele cabe nesta proposta. Não é a escolha de um sistema que precisa de centenas de escritas simultâneas por segundo distribuídas entre regiões. A LaunchWithAgency é desenhada para a operação de marketing de uma agência ou de um time de produto — uma carga em que o gargalo nunca é o banco, e em que a simplicidade de ter tudo num arquivo vale muito mais do que a escala teórica de um cluster que você nunca vai usar. Escolher SQLite aqui não é economia: é desenho.

Por que isso é a fundação, e não um recurso

Se houvesse uma única frase para levar deste artigo, seria esta: na LaunchWithAgency, a integração não é uma funcionalidade que pode ser adicionada ou removida — ela é a forma do banco.

Toda suíte all-in-one promete que "tudo conversa". A maioria entrega isso como um produto principal com módulos satélites, cada módulo com seu armazenamento, e uma camada de sincronização correndo por baixo para manter a ilusão de unidade. Essa camada é onde os bugs moram, onde os dados divergem, e onde a conta de manutenção cresce.

A LaunchWithAgency não tem essa camada porque não tem essa fronteira. Cinco produtos, um schema, um arquivo. O que para outras ferramentas é a feature mais difícil de manter, aqui é simplesmente o ponto de partida.

> Você não precisa de doze abas. Precisa de um banco que não obrigue você a ter doze abas.