Sou o Alexandre. Há 20 anos transformo problemas de operação em software: de fábrica, de clínica, de loja. Esta é a história de como aprendi a fazer isso.

Antes do software, a oficina

Minha porta de entrada não foi um curso de computação: foi o técnico em Eletrônica, na Escola Técnica Tupy, entre 2001 e 2004. Na oitava série eu nem gostava de computador; gostava de desmontar coisas. Por isso a programação chegou junto com o ferro de solda, no CLP (o controlador lógico programável das máquinas de fábrica) e no assembler de microcontrolador PIC. Ali se programava instrução por instrução, com tão pouca memória que um teclado musical de sete botões que fiz ficou sem espaço antes de completar a escala. Em casa, o Linux cobrava o mesmo tipo de esforço: em 2001, fazer a placa de rede funcionar no Debian era um projeto em si. Nos dois casos, eu era obrigado a entender o que estava por baixo.

Terminado o técnico, fiquei na escola. Em 2005 virei laboratorista, cuidando dos laboratórios de eletrônica e automação e dando as aulas práticas. O trabalho me levava também às oficinas de mecânica, plásticos, edificações e metalurgia, e à convivência com professores de áreas que não conversam entre si. Saí de lá sabendo tornear peça, programar CNC e passar massa numa parede. Foi ali que peguei a mania que me define até hoje: entender como as coisas funcionam e como elas se conectam, sejam máquinas, operações ou sistemas. Anos depois descobri que isso tem nome: nexialista, o generalista que conecta especialidades.

Dessa época vem também o jeito que uso para resolver qualquer problema, de software ou não: quebro em caixas, as caixas em blocos, e desço do big picture até o mínimo que dá para resolver. Não aprendi isso em livro; é herança do assembler. Foi a primeira ferramenta de um canivete suíço que eu passaria os vinte anos seguintes montando, uma experiência de cada vez.

A primeira dor de usuário

Enquanto isso, a faculdade me levou para outro lado da computação. Em 2006, no curso de Sistemas de Informação da SOCIESC, o professor Marco André me apresentou o Python e o Guxlle, o Grupo de Usuários Linux de Joinville. Pela mão dele caí no meio da turma que formava a comunidade Python brasileira, entrei na tradução do Django quando ele chegou ao Brasil e ajudei a organizar a Python Brasil de 2007, em Joinville, fazendo o que aparecesse: wiki, credenciamento, palco. No Guxlle descobri que eu gostava de fazer acontecer: install fests, o FLISOL (o Festival Latino-americano de Instalação de Software Livre) de 2007 e caravanas ao FISL, o Fórum Internacional do Software Livre.

Foi numa dessas caravanas, no FISL de 2008, que resolvi pela primeira vez o problema de um usuário contra o relógio. O Instituto Nokia de Tecnologia montou a Arena de Programação Livre, e na final o alvo era o N800, um tablet da Nokia rodando Maemo, um Linux embarcado. Minhas duas origens, a eletrônica e o Linux, no mesmo aparelho. Com o Éverton Ribeiro e o Rafael Floriano, fomos atrás de uma dor real: o aparelho não abria documento de texto. Em dois dias escrevemos em Python um leitor de ODT, o formato aberto de documento. A decisão mais importante não foi técnica: não reinventar nada que já estava resolvido, porque o prazo era o chefe. Ganhamos.

Ganhamos um N800 e um N95, este antes mesmo de ser lançado no Brasil. O N800 virou relíquia mais rápido do que eu imaginava. O Maemo nunca decolou, e poucos anos depois a própria Nokia saiu do mercado de smartphones, levando junto o S60 e o Symbian. Daí veio a segunda ferramenta: toda plataforma pode acabar. O que vale carregar de uma para a outra é o jeito de resolver o problema, e não a tecnologia em que ele foi resolvido.

Consultoria: roer osso

Em 2008 saí da escola técnica (voltaria em 2010, já como professor) e, no fim daquele ano, comecei a Aupi, a consultoria de software que toquei por 15 anos, com um time que oscilou entre 5 e 20 pessoas. Nunca fui contratado como programador: inventei a própria vaga, e aprendi muito com as pessoas que contratei.

Consultoria é roer osso. A gente não escolhe o problema que chega, e ele raramente chega com cara de problema de software. Na Aupi fizemos controle de processos para a TÜV Rheinland, automação de atendimento para redes de clínicas odontológicas, venda de ingressos e plataformas de ensino numa época em que EAD ainda não era palavra comum. Um dos primeiros sistemas calculava o tempo de corte a laser de peças de acrílico a partir do arquivo CAD do cliente, e só consegui desenhar aquela solução porque tinha programado CNC no laboratório. Foi a primeira vez que a oficina e o software se encontraram num projeto, e entendi para que serve saber um pouco de cada área: entender o problema na língua de quem tem o problema.

Com o tempo, as ferramentas mais úteis vieram dos erros. Para uma rede de clínicas de otorrino, construímos no navegador um sistema de captura de exames que substituía um software caro da Siemens. Eu já tinha 12 anos de estrada e mesmo assim comecei superengenheirando, com protocolo DICOM e tudo, até a gente perceber que os recursos nativos do browser resolviam. Num sistema de gestão de planos de saúde, o tropeço foi o oposto: otimizamos um formulário que levava 15 segundos para responder, ele passou a responder na hora, e os usuários acharam que a tela tinha quebrado. Resolvemos com um loading falso de um segundo e meio. Os usuários pediam velocidade, mas o que precisavam era confiar que o sistema tinha feito o trabalho. Ficou mais uma ferramenta: entregar o que o usuário pede nem sempre é entregar o que ele precisa. Não basta o sistema funcionar; ele também precisa parecer que funciona.

O acerto de que mais me orgulho dessa época tem pouco de genial. Numa migração de ERP em 15 dias, com CNPJ novo, troca de regime tributário e 10 canais de venda, deu tudo certo porque cada peça estava mapeada antes de mexermos na primeira. Já contei essa em detalhe.

Fora do software, o mesmo método

Em 2010 voltei à escola técnica, agora como professor de microcontroladores e eletrônica, e fiquei até 2016, com uma passagem pelo IFSC, o Instituto Federal de Santa Catarina. A coordenação me passava matéria nova e eu tinha duas semanas para virar especialista, o que me ensinou a aprender rápido e a explicar com clareza. A recompensa vinha no laboratório: ver um aluno entrar sem saber o que era um resistor e sair automatizando coisas com um microcontrolador é das coisas mais gratificantes que já vivi. Por isso carrego uma frase: se um dia eu falir, quero falir dando aulas, porque estarei feliz.

Nesse meio-tempo, também empreendi fora da tecnologia. Em 2015 abri o Clover Pub com um sócio e fiquei com a parte que eu já conhecia de outros lugares: processos, regularização e fluxo. Um bar que recebe 160 pessoas numa sexta também é um sistema, com fila, gargalo e rotina, e só funciona se foi planejado antes de a porta abrir. Foi o pub que me deu confiança para algo maior. Em 2018 abri a Imaculada, uma fábrica de cachaça, e planejei e executei o pacote inteiro: projeto e obra, registro no MAPA (o Ministério da Agricultura), POPs (procedimentos operacionais padrão), receita e fornecedores. Decompus a operação física como decomponho um sistema, e a fábrica funcionou. Ali ficou claro que planejar e executar com processo vale para qualquer área, seja um deploy, um bar ou uma fábrica.

O que o processo não resolveu foi vender: sei resolver uma venda quando ela chega até mim, mas não sei gerar demanda. Vendemos a operação em 2023, e saí dali com a ferramenta que mais uso hoje como líder: saber o que eu não sei. Fazer funcionar é metade do trabalho; a outra metade depende de gente que entende do que eu não entendo.

Hoje: CTO

A Alva era cliente da Aupi desde 2012. Em doze anos de projetos juntos, de e-commerce a implantação de sistemas e integrações de todo tipo, a relação virou proposta. Em agosto de 2024 vendi a Aupi ao meu sócio e, em setembro, assumi como CTO da Alva Personal Care, a maior empresa de cosméticos naturais do Brasil. Aceitei também por um motivo pessoal: queria provar a mim mesmo que conseguia ser CTO numa empresa que não fosse minha. Síndrome do impostor não some com tempo de carreira.

Desde então, o trabalho é levar a Alva da planilha para a automação. O caso mais visível foi o live shopping de outubro de 2025: construímos a plataforma em duas semanas, com três pessoas, e ela fez R$ 680 mil em pedidos em cinco horas, com pico de 212 usuários simultâneos e zero downtime. Já contei em detalhe. O resto aparece menos, mas é o que sustenta a operação: a automação do fiscal e dos processos que viviam em planilha, um painel de receita, a integração com a operação logística e a sustentação dos e-commerces. Em agosto de 2026 lançamos a Compre Alva, a plataforma de força de vendas B2B. Tudo isso com um time quase todo júnior e um fluxo de desenvolvimento assistido por IA, da tarefa à entrega.

Em cada um desses projetos, a pergunta é a mesma da consultoria: onde a tecnologia vira margem, e onde vira custo? Para responder, abro o canivete inteiro. Entendo a operação como aprendi no laboratório, decomponho como no assembler, não reinvento o que já existe, como na Arena, e chamo quem sabe o que eu não sei. Nenhuma dessas ferramentas veio de curso. Cada uma veio de algum osso que precisei roer.

Fora do expediente, co-apresento com o Gabriel Nunes o Escovando Bits, o podcast quinzenal da Codecon, onde rediscuto com convidados as ideias que aqui viram texto.