Eu me atraí pelo frontend desde cedo porque é a superfície onde a intenção encontra a realidade: pixels, latência, texto e fluxo decidem se alguém continua ou sai silenciosamente. É um lugar humilde para trabalhar - você não pode se esconder atrás de abstrações quando o usuário está olhando para o resultado. Ao longo dos anos, esse instinto se transformou em uma lente repetível: qual é o trabalho que essa tela está fazendo, qual é a restrição não negociável e qual é a menor mudança que podemos enviar que melhora de forma mensurável a confiança, a clareza ou a velocidade? Ainda escrevo UI, mas a pergunta por trás da UI é o que escala entre equipes e produtos.
Na Luma Health, passei um tempo significativo dentro do Communication Hub - um fluxo de trabalho pesado e de alto tráfego, onde o desempenho e a clareza não são apenas polimento; fazem parte da coordenação de cuidados. O produto havia acumulado camadas de fricção de UX e caminhos de código legados que tornavam cada mudança arriscada, o que é como as equipes desaceleram sem perceber. Ajudei a refatorar essa superfície para que a experiência parecesse mais leve para os usuários reais, e usamos canais de feedback (incluindo relatórios de usuários) para validar que estávamos consertando o que as pessoas realmente sentiam — não apenas o que era fácil de medir em um painel de controle. Em paralelo, tratei a segurança como parte da experiência do usuário: o texto rico gerado pelo usuário é um clássico ponto fraco para XSS se sanitizado apenas “em algum lugar”. Ajudei a eliminar a exposição crítica, sanitizando o conteúdo antes do processamento da API e novamente nos limites de renderização, e contribuí para APIs de componentes compartilhados e decisões de sistema de design para que outras equipes não precisassem redescobrir as mesmas arestas afiadas.
Parte do meu trabalho de maior impacto está onde o UX, o comportamento do backend e as operações se encontram — onde uma integração frágil se torna tickets, rotatividade ou uma página noturna. Um exemplo: um pipeline de transmissão SFTP em que “funciona na minha máquina” não era suficiente para os clientes em fluxos de dados sensíveis. Eu o redesenhei para que as equipes configurassem mapeamentos de campo externo→interno na IU com validação em vez de adivinhar e inundar o suporte. Os tickets de configuração incorreta caíram drasticamente e protegemos uma relação que não podia se dar ao luxo de ter entregas descuidadas. Na Sisnet, trabalhei em um mercado selecionado onde a velocidade do conteúdo era tão importante quanto a qualidade do código. Construí um CMS AdminJS em Node.js para que o marketing e as operações pudessem publicar conteúdo, imagens e estilos sem precisar de engenharia para cada ajuste - os exercícios semanais de emergência caíram para “quase nunca”, e a equipe pôde se concentrar em assinaturas, Stripe e Klaviyo, e na profundidade do produto em vez de publicações rotineiras.
Fora de meus papéis em tempo integral, co-fundei a Membrus: uma plataforma para igrejas gerenciarem membresia, comunicação e operações em um sistema coerente, em vez de um conjunto de planilhas, chats em grupo e ferramentas improvisadas. O trabalho não foi “adicionar outro aplicativo CRUD”. Foi entender como os pastores e a equipe realmente se movem ao longo de uma semana - quem precisa de acesso ao que, o que quebra quando os dados são inconsistentes e como entregar fluxos de trabalho administrativos que pessoas não técnicas possam possuir. Eu fui responsável pelo produto e pela entrega em várias superfícies: presença pública, experiências voltadas para os membros e ferramentas internas, iterando com líderes de igreja que foram generosos com feedback honesto. Esse é o tipo de produto que quero continuar construindo: enraizado em restrições reais, entregue a usuários reais, aprimorado em público — e não apenas um protótipo de apresentação.
Na Shifting, trabalhei em uma pequena equipe lançando um mercado de ingressos sob pressão de escopo real — a velocidade era importante, mas também não podíamos queimar as pessoas. Eu frequentemente atuava como a pessoa que tinha que escolher: o que cortamos, o que fortalecemos e no que recusamos comprometer? Meu foco era enviar coisas bem feitas, não de forma caótica: desbloqueio diário, revisão de código consistente para que o feedback fosse previsível e pequenas melhorias de DX que tornavam a semana seguinte mais fácil do que a anterior. Também construí ferramentas internas estilo CMS para que colegas não técnicos pudessem iterar conteúdo sem que a engenharia se tornasse um gargalo. O resultado não foi apenas “nós lançamos”—foi um mercado funcional entregue em um ritmo sustentável, com um cliente que se sentiu genuinamente bem atendido. Esse resultado é tão importante para mim quanto qualquer detalhe técnico.
Este site é intencionalmente mais do que um currículo estático. É i18n-first, compartilha a interface do usuário entre o monorepo e o layout prioriza uma hierarquia e espaçamento legíveis, de modo que páginas longas como esta permaneçam agradáveis de ler. O Lucas AI faz parte da mesma tese: um assistente que responde em primeira pessoa, mas apenas a partir de um contexto estruturado publicado aqui — projetos, experiência e como penso sobre compensações — para que a exploração se sinta fundamentada ao invés de genérica. Se você está lendo até aqui, está vendo o argumento do craft em miniatura: narrativa, sistemas e uma superfície de produto que convida à profundidade.
