Como eu Trabalho
Eu construo sistemas que aguentam o contato com a realidade.
Faço isso há 25 anos. Tempo suficiente pra ter opinião forte sobre o que faz um projeto dar certo e o que faz ele desmoronar em silêncio três meses depois da entrega. A maioria dos problemas que me chamam pra resolver não é técnica: é o resultado de alguém ter construído alguma coisa sem pensar em quem ia manter aquilo depois.
O meu trabalho fica num cruzamento pouco comum: conhecimento profundo de WordPress e WooCommerce, sistemas de IA em produção (RAG, integração com LLM, pipelines de automação) e a experiência de infraestrutura de quem roda servidor desde antes de "nuvem" virar termo de marketing. Não sou especialista em só uma dessas coisas. Sou especialista no que acontece quando elas precisam funcionar juntas.
Como um projeto costuma andar
1. Intro Call e depois um Diagnóstico Pago Tudo começa com uma Intro Call gratuita de 30 minutos, que responde uma pergunta só: esse é um projeto que eu devo pegar? Se for, vem o diagnóstico pago. Antes de escrever qualquer código, preciso entender o que está quebrado de verdade, e não o que alguém acha que está quebrado. Isso quer dizer acesso ao código, aos logs do servidor e uma conversa honesta sobre o que já foi tentado. Na maioria das vezes, o problema real está duas camadas abaixo do sintoma que foi relatado.
2. Arquitetura e Escopo Defino o que vamos construir, o que fica explicitamente de fora e o que conta como "pronto". Sem escopo inflando no meio do caminho. Se o escopo precisar mudar, a gente conversa antes de eu começar a escrever o código, e não depois.
3. Construção Eu construo a solução. Escrevo as integrações, trato os estados de erro e testo os casos extremos que só aparecem quando dado de pagamento de verdade ou pergunta de cliente de verdade bate no sistema. Trabalho em blocos de foco, e não em conversa de Slack.
4. Documentação Documentação faz parte da entrega. Registros de decisão de arquitetura, guias de integração, manuais de operação. Se eu for atropelado por um ônibus, outra pessoa consegue manter o sistema. Esse é o padrão.
5. Entrega e Suporte Entrego um sistema funcionando, com documentação que não exige que eu fique de plantão pra sempre. Se você precisar de suporte contínuo, dá pra estruturar isso, com a cobertura combinada desde o começo: horário comercial de São Paulo (UTC-3), resposta em até um dia útil pra pedidos normais e em até 4 horas pros urgentes. Mas o objetivo é sempre um sistema que funcione sem mim.
O que eu preciso de você
Eu trabalho melhor em algumas condições, e prefiro deixar isso claro logo:
- Alguém que decida e responda. Não preciso de reunião diária, mas quando eu trago uma decisão que está travando o andamento, preciso de uma resposta, e não de uma reunião de comitê na quinta que vem.
- Acesso ao sistema desde o primeiro dia. Não dá pra diagnosticar o que eu não vejo. Código, ambiente de homologação, acesso ao servidor, credenciais de API: quanto antes eu tiver isso, antes eu começo a render.
- Escopo claro. "Melhorar as coisas" não é escopo. "Corrigir as falhas de cobrança das assinaturas e documentar a arquitetura do gateway de pagamento" é escopo. Se o escopo ainda não estiver claro, eu ajudo a definir, mas isso é um diagnóstico pago, e não cabe na Intro Call gratuita.
- Confiança no trabalho assíncrono. Trabalho remoto, a partir de São Paulo (UTC-3). Eu me comunico por atualizações escritas e estruturadas, e não por presença constante: um relatório escrito por dia nos projetos complexos, e uma revisão escrita semanal de tudo que foi feito nos menores. Você sempre vai saber no que estou trabalhando e quando fica pronto. Você não vai me ver digitando no Slack o dia inteiro, e isso é de propósito.
Onde eu faço mais diferença
O trabalho que eu faço melhor começa com uma plataforma que já existe e já dói: dívida de arquitetura segurada por gambiarra, integração sem documentação, código em que ninguém quer mexer. Isso inclui plataformas WordPress colocando IA em produção, atendimento com RAG, pipelines de conteúdo automatizados e ferramentas com LLM rodando com tráfego de verdade.
Boa parte é automação pra times que não conseguem justificar uma contratação em tempo integral: workflows no n8n, integrações por API, pipelines de relatório que substituem o processo manual que alguém faz toda segunda-feira há dois anos. Também já construí sistemas sob as regras de saúde do Canadá e de conformidade de CBD, então sei que "mover rápido e quebrar as coisas" não vale quando existe consequência legal.
E se o seu último desenvolvedor saiu e levou todo o contexto junto, eu sou a pessoa que garante que isso não aconteça de novo.
O que eu não faço
Prefiro ser específico aqui, porque isso economiza o tempo de nós dois:
- Não sou operador de ferramenta no-code. Uso o n8n e ferramentas parecidas como camada de implementação, e não como a arquitetura em si. Se você precisa de alguém pra clicar numa interface do Zapier, eu não sou a pessoa certa.
- Não faço contrato de manutenção sem entregas definidas. Todo projeto tem escopo, cronograma e uma definição de "pronto". Se você precisa de alguém de sobreaviso permanente "por via das dúvidas", isso é outro tipo de contratação.
- Não funciono bem em cultura de reunião demais. Uma conversa semanal e atualizações assíncronas funcionam. Reunião diária, cerimônia de sprint e três canais de Slack por funcionalidade não funcionam, pelo menos não pro tipo de trabalho profundo que eu faço.
- Não vou fingir que a sua arquitetura está boa se não estiver. Se eu vir problema durante a auditoria, eu vou te falar. Você está pagando por uma avaliação honesta, e não por um tapinha nas costas.
A versão curta
Eu pego sistemas quebrados ou complexos, deixo eles estáveis e documentados e devolvo num estado em que você não precisa mais de mim. Se você me chamar de novo, que seja pro próximo problema, e não porque o último desmoronou.
É assim que eu trabalho.