Pitch: Build in public: criando um SaaS na força do ódio

Ato I - O relato: sou dev, trabalho em duas empresas gringas e sonho em largar tudo pra viver do próprio negócio. Já tentei quase tudo nessa vida: já tive uma empresa de desenvolvimento em 2016 (a Mavins), vendi uma healthtech (a Bludworks) pra uma empresa Alemã, arrisquei dropshipping (não recomendo), criei um blog de programação (Python Academy), já fui servidor público na TI do Banco do Brasil e passei por várias empresas. Pensei em abrir perfil na plataforma azul... Mas minha esposa não deixou (e a skin de dev também não ajuda 😆)

O bicho do negócio próprio morde uma vez e nunca mais solta.

Ato II - O Problema: A tentativa da vez nasceu de uma dor minha. Tenho um curso de Python, a Jornada Python, e nesse mercado, ebooks são essenciais (como isca digital, bônus de aluno, material de apoio). Eu levava três fins de semana pra produzir UM. Quando o ChatGPT surgiu, ele acelerou a escrita. Mas a escrita era só um pedaço do problema. Sobrava: capa, imagem, infográfico, diagramação, gerar PDF sem quebrar. Eu montava tudo no Canva e o resultado... Melhor nem falar sobre.

Como todos somos programadores, fiz o óbvio. Tentei automatizar tudo: script pra interagir com a OpenAI, script pra tinificar as imagens (reduzir tamanho), script pra gerar artigo pro blog, script pra automatizar o caminho Markdown -> HTML -> PDF (via pandoc + WeasyPrint). No final, uma bagunça e eu sem lembrar a linha de comando que rodava o primeiro script 😅

Cansei dessa bagunça. E daí, nasceu o Ebookr.ai.

Essas duas sentenças - "cansei dessa bagunça" e "E daí" - são separados por 6 meses de desenvolvimento e alguns milhões de tokens kkkkkk

Ato III - A Solução: A primeira versão do gerador era um prompt gigante que cuspia o ebook inteiro de uma vez. Funcionou por uns 20 minutos: o capítulo 3 repetia o capítulo 2, o sumário prometia seções que nunca foram geradas e livro técnico vinha com código que não rodava. A virada foi parar de pedir "um livro" e começar a pedir peças: quebrei tudo num pipeline multi-agente com LangGraph: o Arquiteto monta o sumário, o Escritor escreve seção por seção, o Coder assume quando o assunto é técnico e o QA revisa com poder de rejeitar o texto do Escritor, com feedback (as brigas dos dois nos logs são ótimas). Infográfico e layout viraram agentes próprios mais tarde, quando aceitei que texto bom em página feia continua sendo produto ruim.

A geração do PDF seguiu a mesma trilha de dor. Comecei pelo caminho óbvio de quem vive de Markdown: Pandoc + WeasyPrint. Serve pra relatório, mas não funciona bem para layout "fru fru". Engoli o orgulho e reescrevi a saída inteira: templates Jinja2 renderizados em Chromium headless via Playwright, com um motor de paginação próprio decidindo as quebras, porque tabela e lista adoram "pular a cerca", pulando pra página seguinte. Sim, acabei escrevendo um motor de paginação em 2026. Não me julguem, nada funcionava 😬

O resto da arquitetura é proposital e sem glamour: Django 5, Celery com Redis, Postgres (com pgvector) e Stripe. Escolhi tecnologia entediante porque... Bem, é a stack que sempre pagou os boletos e não queria inventar.

Não que isso tenha me salvado dos bugs. O servidor caiu no dia em que vários Chromium renderizaram PDF ao mesmo tempo e o OOM killer do kernel passou a foice. A correção não foi elegante: criei uma fila só pra renders, com concorrência 1 e limite de memória, e segui a vida. Depois, mais bugs: a prévia gratuita carregava o ebook completo no navegador, incluindo os capítulos que a pessoa ainda nem tinha pago. E depois? Mais bugs: o editor travava em ebooks grandes. Depois de muito profiling, o vilão era uma textura decorativa de fundo (famoso "grain"), recalculada em cada uma das 70 páginas. Ficava bonito, quebrava tudo.

Quando lancei, pensei "bem, eu sei programar. Não sei vender. Vou contratar uma Agência". E acabei caindo no papinho de uma dessas "agências de marketing especializada em SaaS". Sim, caí no conto do vigário. Um OCEANO AZUL de problemas (os bons entenderão kkkkkkk)

Os números nunca batiam: o relatório da agência dizia uma coisa, a plataforma de anúncio dizia outra, meu BD dizia uma terceira, e eu, dev, no meio, tentando decifrar dashboard de mídia.

Então - depois de gastar mais de R$ 10k nessa brincadeira - e entender que quase tudo hoje é "visível" para IA via MCPs, montei um agente de marketing com subagentes (analista de dados, CRO, copy) e acesso somente-leitura a Google Ads, GA4, Search Console, Clarity, Stripe e ao banco de produção via túnel SSH. A regra que importa: ele lê tudo, não altera nada, e não aceita número de plataforma sem cruzar com cadastro e receita reais. Esse cruzamento de dados é "O OURO"! Façam isso e não sigam o exemplo do trouxa aqui que gastou R$ 10k com marketeiro 🤦

A primeira missão dele foi auditar a tal agência. O relatório dela comemorava "132 inícios de trial" num produto que nunca teve trial: o evento disparava quando alguém visitava a página de cadastro. O número real da mesma campanha, direto do meu banco: 1 assinatura por R$ 634 gastos 🤬 Achei até ativo de outro cliente da agência dentro do meu Business Manager. Bastou dar alguns acessos ao meu Agente de Marketing, que só faltou ele me perguntar: "você é burro?" kkkkkkkk

Ato IV - Os Números: vou dizer (porque eu sei que todo Dev quer ouvir os números do negócio do coleguinha): 10 assinantes, R$ 670 de MRR, 1 cancelamento na história toda (retenção é o ponto forte). Orgânico converte uns 11% em pagante. Tráfego frio do Google Ads: menos de 1%, e essa é a briga do momento: o cadastro sai a R$ 3 e pouco, a assinatura do frio ainda não saiu. Sigo atacando com gravação de sessão, funil instrumentado e teimosia.

É pouco e está longe de sair do vermelho (ainda tem custo com infra, custo com o Claudinho - vulgo Claude Code, custo com anúncio), mas está sendo divertido.

Ver seu produto online, recebendo acessos, cadastros, assinaturas, pessoas reais utilizando, LLMs sugerindo; é bem legal!

Link pra quem quiser acessar: Ebookr.ai. Qualquer feedback, dúvida ou sugestão é bem vindo! 😉