O que eu construo, e por que escrevo sobre isso

Este blog existe por um motivo prático: eu esqueço.

Não o que fiz — o porquê. Seis meses depois de uma decisão de arquitetura o código continua lá, mas a razão evaporou. Sobram as consequências sem o argumento, e ninguém consegue revisar uma decisão que não sabe reconstruir. Escrever é a forma mais barata que encontrei de deixar o argumento junto com o resultado.

O segundo motivo é menos nobre e igualmente verdadeiro: explicar por escrito revela na hora se eu entendi. Quase todo texto que comecei aqui mudou de conclusão no meio, porque a versão que estava na minha cabeça não sobreviveu a ser dita em voz alta.

Onde eu trabalho#

Sou desenvolvedor no Grupo Coagro desde julho de 2024. O trabalho lá é estender um ERP que continua sendo o ERP: mapear onde a regra dele termina e construir só a borda em que o negócio pede uma regra que ele não tem. CRM de campo, emissão de receita agronômica, acesso único. Escrevi sobre isso em Onde o ERP termina.

Fora do horário, pego projeto freelance de web e mobile. Não é vida dupla: é o mesmo problema em escalas diferentes — alguém precisa de software que funcione e de alguém que responda por ele.

A stack, e por que é essa#

Lista de tecnologia não diz nada sobre ninguém. O que diz é o motivo de cada escolha.

Flutter é onde passo a maior parte do tempo. A razão não é a linguagem: é que time pequeno não sustenta duas bases nativas, e a alternativa honesta ao multiplataforma quase sempre é atender bem uma plataforma e mal a outra. Quando o app roda na mão de quem está em campo, com conexão ruim, o que importa é ele existir nos dois lugares e responder rápido.

React e Electron para o que vive no navegador e no desktop. Electron tem má fama merecida por peso, e ainda assim continua sendo a resposta certa quando o requisito é acesso ao sistema de arquivos com a mesma interface do web.

Supabase pela modelagem, não pelo atalho. O que ele resolve bem é entregar Postgres de verdade com RLS na frente — regra de acesso que mora no banco, não na aplicação. Regra de acesso em código de aplicação é regra que alguém esquece de aplicar em algum caminho.

Docker e Kubernetes para o que precisa subir igual em qualquer máquina. A parte que interessa não é o contêiner: é “funciona na minha máquina” deixar de ser uma frase possível.

CI/CD com GitHub Actions — e o hábito que mais mudou meu dia: rodar o pipeline localmente, no terminal, antes do push. Pipeline que só roda no servidor transforma cada erro de lint num ciclo de commit, push e espera. Rodando antes, o erro custa segundos e nunca vira ruído no histórico.

O que eu construo fora do trabalho#

App de academia. A parte visível é registro de treino; a parte difícil é a modelagem. Carga, série, repetição e progressão parecem quatro campos até você tentar responder “esta pessoa está evoluindo?” — aí viram histórico, comparação entre períodos e a diferença entre trocar de exercício e trocar de estímulo. É o tipo de problema em que errar o esquema cedo compra uma migração feia depois.

Integrações via API com plataformas grandes, como Dropbox e Google Maps. Integração é sempre a mesma lição com roupa nova: o contrato é de outra pessoa, muda sem avisar, e falha de rede não é exceção — é estado normal que o código precisa saber tratar.

SaaS e ferramentas com IA. Ainda em exploração, e a pergunta que carrego é onde o modelo agrega de fato e onde ele só acrescenta uma fonte de erro plausível. Resposta plausível e errada é o defeito mais caro que existe, porque ninguém confere o que não pareceu estranho.

O que vem aqui#

Decisão de arquitetura com o argumento junto. Erro que me custou tempo, contado com o número que me fez perceber. Solução que procurei e não achei escrita em lugar nenhum.

Não pretendo escrever tutorial de coisa que já tem documentação boa. Pretendo escrever o que eu teria gostado de encontrar às duas da manhã.