Como Eu Trabalho | Paulo H. Alkmin

Eu construo sistemas que sobrevivem ao contato com a realidade. Veja como isso funciona na prática.

Eu faço isso há 25 anos. Tempo suficiente para ter opiniões fortes sobre o que faz os projetos terem sucesso e o que os faz desmoronar silenciosamente três meses após a entrega. A maioria dos problemas para os quais sou contratado para resolver não são técnicos — são o resultado de alguém construindo algo sem pensar em quem o manterá a seguir.

Meu trabalho fica em uma interseção incomum: profundo conhecimento da plataforma WordPress/WooCommerce, sistemas de IA de produção (RAG, integração de LLM, pipelines de automação) e o tipo de experiência em infraestrutura que vem de rodar servidores desde antes de "a nuvem" ser um termo de marketing. Eu não me especializo em apenas uma dessas coisas. Eu me especializo no que acontece quando elas precisam funcionar juntas.

Como um Engajamento Geralmente Acontece

1. Auditoria e Diagnóstico Antes de escrever qualquer código, preciso entender o que está realmente quebrado — não o que alguém acha que está quebrado. Isso significa acesso ao código-fonte, logs do servidor e uma conversa honesta sobre o que foi tentado antes. Na maioria das vezes, o problema real está dois níveis abaixo do sintoma relatado.

2. Arquitetura e Escopo Eu defino o que estamos construindo, o que explicitamente não estamos construindo e como é a definição de "pronto". Sem aumento de escopo (scope creep). Se o escopo precisar mudar, teremos essa conversa antes de eu começar a escrever o código, não depois.

3. Construção Eu construo a solução. Escrevo as integrações, lido com os estados de erro e testo contra os casos extremos que só aparecem quando dados de pagamento reais ou consultas de clientes reais atingem o sistema. Trabalho em blocos focados, não em tópicos de Slack.

4. Documentação Tudo o que eu construo é documentado — não como um pensamento posterior, mas como parte da entrega. Registros de decisão de arquitetura, guias de integração, manuais operacionais. Se eu for atropelado por um ônibus, outra pessoa pode manter o sistema. Esse é o padrão.

5. Entrega e Suporte Entrego um sistema funcionando com documentação que não exige que eu esteja de plantão para sempre. Se você precisar de suporte contínuo, podemos estruturar isso. Mas o objetivo é sempre um sistema que funcione sem mim.

O Que Eu Preciso de Você

Eu faço meu melhor trabalho sob condições específicas e sou direto sobre elas:

Um tomador de decisão que responda. Eu não preciso de reuniões diárias, mas quando eu apresento uma decisão que bloqueia o progresso, preciso de uma resposta — não de uma reunião de comitê na próxima quinta-feira.
Acesso ao sistema desde o primeiro dia. Não posso diagnosticar o que não posso ver. Código-fonte, ambiente de homologação, acesso ao servidor, credenciais de API — quanto antes eu tiver isso, mais cedo serei produtivo.
Escopo claro. "Melhorar as coisas" não é um escopo. "Corrigir as falhas de faturamento de assinatura e documentar a arquitetura do gateway de pagamento" é um escopo. Se o escopo ainda não estiver claro, posso ajudar a defini-lo — mas essa é uma fase separada, não uma consultoria gratuita.
Confiança no trabalho assíncrono. Sou remote-first, baseado em São Paulo (UTC-3). Eu me comunico através de atualizações estruturadas, não presença constante. Você saberá no que estou trabalhando e quando estará pronto. Você não me verá digitando no Slack o dia todo, e isso é intencional.

Onde Eu Crio o Maior Impacto

Sistemas com dívida arquitetônica — plataformas que funcionam, mas são mantidas por gambiarras, integrações não documentadas e código que ninguém quer tocar.
Plataformas WordPress que precisam de integração de IA — não demonstrações de chatbot, mas sistemas de produção: atendimento ao cliente baseado em RAG, pipelines de conteúdo automatizados, ferramentas movidas a LLM que rodam em tráfego real.
Automação para equipes que precisam, mas não podem justificar uma contratação em tempo integral — fluxos de trabalho N8N, integrações de API, pipelines de relatórios que substituem o processo manual que alguém tem feito toda segunda-feira há dois anos.
Ambientes regulados ou sensíveis à conformidade — eu já construí para regulamentações de saúde canadenses e conformidade de CBD. Eu entendo que "mover rápido e quebrar as coisas" não se aplica quando há consequências legais.
Equipes que precisam de documentação, não apenas código — se o seu último desenvolvedor saiu e levou todo o contexto com ele, eu sou a pessoa que garante que isso não aconteça novamente.

O Que Eu Não Faço

Eu sou específico sobre isso porque economiza o tempo de ambos:

Não sou um operador de ferramentas no-code. Eu uso N8N e ferramentas semelhantes como camadas de implementação, não como a arquitetura em si. Se você precisa de alguém para clicar em uma interface do Zapier, eu não sou o ajuste certo.
Não faço contratos de manutenção sem entregáveis definidos. Todo engajamento tem um escopo, um cronograma e uma definição de "pronto". Se você precisa de alguém em prontidão permanente "por precaução", esse é um tipo diferente de contratação.
Não prospero em culturas de excesso de reuniões. Um sincronismo semanal e atualizações assíncronas funcionam. Daily standups, cerimônias de sprint e três canais de Slack por funcionalidade não funcionam — pelo menos não para o tipo de trabalho profundo que eu faço.
Não vou fingir que sua arquitetura atual está boa se não estiver. Se eu vir problemas durante a auditoria, eu lhe direi. Você está pagando por uma avaliação honesta, não por reafirmação.

A Versão Curta

Eu pego sistemas quebrados ou complexos, os torno estáveis e documentados, e os entrego de volta em um estado onde você não precise mais de mim. Se você precisar de mim novamente, é para o próximo problema — não porque o último desmoronou.

É assim que eu trabalho.