Não vim da informática. Vim das telecomunicações.

De onde venho

Nasci no Porto, em Cedofeita, e cresci na Ramada Alta.

Depois da escola, grande parte do meu tempo livre era na empresa dos meus pais. Foi lá que ganhei o gosto pelos computadores, e sempre como hobby: ficheiros .bat, formatar máquinas, montar e desmontar computadores com configurações à medida. Muito antes de pensar nisto como trabalho, já era isto que eu fazia.

Mais tarde passei a construir a sério: primeiro as ferramentas que faltavam onde trabalhava, depois projetos web pessoais para testar ideias, e por fim projetos para outras pessoas.

Em paralelo, passei mais de uma década em telecomunicações a medir, planear e resolver problemas com prazos: indicadores de operação, previsão de volumes, alocação de recursos, coordenação de equipas.

Passei também pelo lado administrativo e orçamental de uma empresa familiar: as primeiras contas a sério foram ali, em folhas de Excel com fórmulas para orçamentos, custos e preços. Vi por dentro como um orçamento se perde, como uma cobrança se arrasta e o que custa a uma empresa fechar o mês.

Trago isso para o código: medir antes de decidir, escrever requisitos que se percebem, e dizer-te o que não faço.

Onde isto se vê no código

• Instrumento o que entrego. Anos a acompanhar indicadores, relatórios e dashboards. Se não se mede, não se melhora - e um painel diz mais do que uma opinião.
• Dimensiono antes de escrever. Quanto pesa, quanto custa e o que acontece no pior dia.
• Penso em restrições e disponibilidade. O mesmo raciocínio que está por dentro de um motor de reservas.
• Sei o que é um orçamento feito à pressa, uma cobrança que se arrasta e uma folha que só o autor entende. Escrevi as primeiras fórmulas em Excel, e é desse lado - dos custos, dos prazos e dos números que têm de bater - que penso quando construo uma ferramenta de orçamentos ou de faturação.
• Penso em conformidade antes de pensar em features. Vivi de perto o que custa um erro fiscal, uma coima ou uma obrigação mal cumprida. Desenho sistemas que não deixam esse erro acontecer: validações, alertas, registos e prazos.
• Conheço o peso do regime laboral. Horários, contratos, escalas, férias, subsídios. Já trabalhei num contexto em que cada detalhe conta - e isso vê-se quando construo ferramentas de gestão de pessoas ou de operações.
• Escrevo para ser mantido por outra pessoa. Nomes claros, documentação e revisão de código.
• Descubro o requisito real. A maior parte dos projetos falha no âmbito, não no código.
• Percebo o que faz uma página converter. Passei anos do outro lado, em contacto direto com clientes, atendimento e venda.

Como construo

Não tenho dogma de frameworks: escolho pelo problema e pelo contexto. Uma boa biblioteca pode ser a decisão certa; e há projetos em que a dependência a mais se paga em velocidade e em manutenção - por isso o mais leve que resolve é o que costuma ganhar.

• Backend: Node.js com Express e Fastify, APIs REST.
• Dados: MySQL e MariaDB - modelação, índices e migrações aditivas que não obrigam a parar o que está em produção.
• Frontend: HTML semântico, CSS com design tokens e JavaScript em módulos. Bibliotecas quando o projeto o justifica: GSAP e VFX-JS para movimento e efeitos visuais, e Bootstrap em painéis de administração.
• Segurança e conformidade: CSRF, cookies assinados, JWT com refresh, RBAC, limites de tentativas e RGPD.
• Integrações: SMS, email transacional, pagamentos e exportação de documentos (PDF e Excel).
• Performance: imagens AVIF/WebP, compressão Brotli, carregamento diferido e medição com Lighthouse.
• Entrega: PWA com service worker, deploy controlado e backup automático da base de dados.

O método

• Requisitos escritos antes do código. Se o âmbito não está claro, o projeto já está atrasado antes de começar.
• Decisões registadas. As escolhas que custam a reverter ficam escritas com o porquê, para quem vier depois não ter de adivinhar.
• Testes como gate. Unitários com Vitest e Jest para a lógica, ponta a ponta com Playwright para os fluxos que ninguém pode quebrar. Acessibilidade auditada com axe. Se o teste falha, não entrego.

Como aprendi

Não me canso de aprender, e aprendo sempre da mesma maneira: construindo. Quando quero perceber como uma coisa funciona, faço um projeto pessoal - experimento uma tecnologia nova, testo uma abordagem diferente, vejo onde falha. Só paro quando a percebo por dentro.

É o que faço com uma ferramenta que nunca usei e com um problema que nunca vi: leio, testo, meço e só depois decido.

O que isto muda quando trabalhas comigo

• Digo-te o que não faço. Prefiro perder um projeto a entregar um em que não acredito.
• Orçamento por âmbito fechado. Se o âmbito mudar, falamos antes de fazer.
• Meço o que entrego e explico-te os números.