Em outubro de 2024, uma catástrofe natural devastou as operações do nosso armazém em Alfafar, Valência. Perdemos inventário, equipamento e meses de impulso. Esta é a história de como reconstruímos a operação, melhorámos os sistemas por detrás do negócio e regressámos mais fortes.
Contexto: Uma Empresa em Crescimento Acelerado
Fundei a REUSALIA em abril de 2023, aos 25 anos. A ideia era simples: comprar paletes de liquidação da Amazon, processar e testar cada artigo e revendê-lo em marketplaces como o Wallapop e o eBay. O que não era simples era construir a tecnologia para fazer isto funcionar à escala.
No início de 2024, as coisas corriam bem. Tínhamos 2 funcionários, um catálogo crescente de milhares de SKUs, automação personalizada para cada parte do negócio — desde extratores do Wallapop com engenharia inversa até descrições de produtos geradas por IA — e estávamos a ficar sem espaço. Em abril de 2024, demos o salto: mudámo-nos para um armazém industrial em Alfafar, nos arredores de Valência, para dimensionar as operações como deve ser.
Parecia a decisão certa. Tínhamos mais espaço, melhor logística, margem para crescer. Durante seis meses, continuámos a construir. Mais inventário. Mais automação. Mais estrutura.
Então, a 29 de outubro, veio a água.
A DANA: 29 de Outubro de 2024
A DANA — Depresión Aislada en Niveles Altos — foi um fenómeno meteorológico catastrófico que atingiu a região de Valência com uma força sem precedentes. Alfafar foi uma das zonas mais afetadas. As ruas tornaram-se rios. Os carros foram arrastados. A destruição não se parecia com nada que alguém alguma vez tivesse visto.
O nosso armazém ficou inundado. O inventário que passámos meses a processar, testar e categorizar — destruído. Equipamento, prateleiras, ferramentas — arruinados. Os sistemas internos estavam a salvo (viviam na cloud), mas tudo o que era físico desapareceu. Meses de impulso operacional, varridos em horas.
O primeiro sentimento não foi pânico. Foi silêncio. Entramos num espaço onde construímos algo com as nossas mãos e está irreconhecível. Isso demora um momento a assimilar.
A Recuperação: Voluntários, Limpeza e Decisões
O que aconteceu a seguir foi a experiência de gestão mais intensa da minha vida — e nada teve a ver com código.
Nos dias que se seguiram à cheia, começou a chegar ajuda. Voluntários de toda a Espanha. E militares foram destacados para a nossa zona durante um curto período. Apareceram no nosso armazém prontos para trabalhar, mas a recuperação ainda precisava de prioridades: o que podia ser salvo, o que tinha de ser limpo primeiro e que equipamento era necessário a seguir.
Durante algumas semanas, o trabalho não foi de engenharia. Foi triagem operacional, coordenação e manter a cabeça fria enquanto o negócio estava fisicamente inutilizável:
- Triagem: O que pode ser salvo? O que é perda total? Que áreas limpamos primeiro para tornar acessíveis as restantes?
- Gestão de pessoas: Coordenar voluntários, amigos, funcionários e ajuda temporária sem transformar a situação num caos.
- Alocação de recursos: Ferramentas limitadas, material de limpeza limitado, tempo limitado antes de a janela de ajuda gratuita se fechar. É preciso aproveitar ao máximo cada hora.
- Gestão emocional: Alguns destes voluntários eram, eles próprios, vítimas das cheias. Os militares cumpriam ordens, mas precisavam de ordens claras. Os meus próprios funcionários estavam a digerir o choque de poderem perder os seus empregos.
Isto não se aprende numa sala de aulas nem numa retrospetiva de sprint. Aprende-se de pé, com lama pelos tornozelos, a tomar decisões com informação incompleta, enquanto se tenta preservar impulso suficiente para reconstruir.
O Rescaldo: Seguros, Orçamentos e Reinício Mental
Assim que a limpeza física ficou concluída, começou um tipo de trabalho diferente — e, de certa forma, mais difícil.
Seguros: Apresentar reclamações para uma pequena empresa após uma catástrofe natural é um pesadelo burocrático. Documentar perdas. Fotografar tudo. Negociar com peritos que viram centenas de reclamações nessa semana. Perceber o que está coberto, o que não está e quanto tempo demorarão os pagamentos.
Orçamentos: Durante semanas, tivemos receita zero e custos contínuos. Renda, salários (continuei a pagar à minha equipa), compromissos com fornecedores. Tive de criar projeções financeiras num cenário de enorme incerteza: Quando podemos recomeçar? Quanto custarão as reparações? Quanto inventário conseguimos recuperar?
Reinício mental: Talvez seja a parte mais subvalorizada. Quando passamos um ano e meio a construir algo e o vemos debaixo de água, temos de fazer uma escolha. Podemos desistir — ninguém nos censuraria. Ou podemos decidir que, se vamos reconstruir, vamos fazê-lo bem. Melhor do que antes.
Escolhi a segunda opção.
Reconstruir: Melhores Sistemas, Equipa Maior
Dois meses após a cheia, estávamos novamente operacionais. O mesmo armazém — reparámo-lo em vez de mudar de instalações, porque o senhorio colaborou e a localização servia a nossa logística. Mas tudo o resto era diferente.
Crescimento da Equipa: De 2 para 5
Antes da DANA, tínhamos 2 funcionários. Depois da reconstrução, passámos a 5. A crise fez-me perceber que estávamos demasiado esticados. Precisava de pessoas em quem pudesse confiar para gerir as operações enquanto eu me concentrava em construir a infraestrutura tecnológica como deve ser. As novas contratações foram em logística e operações de armazém — as áreas onde o trabalho manual estava a estrangular o nosso crescimento.
A Decisão de Migrar
Antes da cheia, todo o nosso negócio funcionava no Google Sheets. Inventário, encomendas, preços, tudo. Funcionava quando éramos pequenos, mas as fissuras começavam a notar-se: limites de taxa da API, problemas de concorrência, ausência de registo de auditoria, ausência de análise de dados real. Andava a pensar em migrar há meses, mas ia adiando — "o negócio não pode parar para um projeto de engenharia".
A cheia mudou essa equação. Tivemos de parar de qualquer forma. Quando recomeçámos, decidi que recomeçaríamos numa base de dados a sério. Isso levou à migração completa do Google Sheets para o PostgreSQL, à construção de um frontend de ERP personalizado em Retool e à reestruturação de todas as automações para usarem modelos de dados adequados. Escrevi sobre os detalhes técnicos noutro artigo.
Documentação e Processos
Antes da DANA, muito conhecimento estava na minha cabeça. Como as coisas funcionavam, porque é que certos scripts existiam, quais eram os casos limite. A reconstrução obrigou-me a documentar tudo. Não porque quisesse — porque tinha de o fazer. Com novos membros na equipa que precisavam de aprender os sistemas, e com a memória dolorosa de quão frágil tudo parecia quando era tudo manual, comprometi-me a pôr as coisas por escrito.
Hoje, cada processo tem documentação. Cada script tem um propósito documentado num registo central. Cada funcionário sabe onde encontrar o que precisa. Isto não nasceu de um livro de boas práticas — nasceu de ver o caos e decidir nunca mais voltar a ser tão vulnerável.
O Que a DANA Me Ensinou
Sou engenheiro. Penso em sistemas, fluxos de dados e otimização. Mas a DANA ensinou-me coisas que nenhum desafio técnico alguma vez poderia ensinar:
- Liderança é tomar decisões em tempo real sob incerteza. Quando as operações estão paralisadas e a informação é imperfeita, aprendemos que uma decisão rápida e suficientemente boa supera sempre uma decisão lenta e perfeita.
- A resiliência não tem a ver com evitar o fracasso — tem a ver com o que se constrói depois. A empresa que existe hoje é objetivamente melhor do que a que existia antes de outubro de 2024. Melhores sistemas, melhores processos, melhor equipa, melhor documentação. A cheia foi a pior coisa que nos aconteceu, mas o que construímos depois é a melhor versão da REUSALIA.
- A gestão de pessoas é o problema de engenharia mais difícil. Coordenar pessoas com diferentes competências, motivações e estados emocionais — enquanto se gere o nosso próprio — é várias ordens de grandeza mais difícil do que qualquer problema de sistemas distribuídos que alguma vez resolvi.
- A crise revela o que é frágil. Cada sistema que falhou durante a recuperação — fosse um processo de negócio que só eu compreendia, uma folha de cálculo incapaz de lidar com acesso concorrente, ou uma equipa demasiado pequena para absorver um choque — era um sistema que precisava de ser redesenhado. A cheia foi o teste de esforço definitivo.
- Não se constrói nada significativo sem risco. Mudar para o armazém foi a decisão certa. A cheia foi má sorte, não mau julgamento. Voltaria a fazer a mesma mudança. O que não voltaria a fazer era construir sobre fundações frágeis.
Onde Estamos Agora
Hoje, a REUSALIA opera com 5 funcionários. Operamos a partir do mesmo armazém em Alfafar — reparado, reorganizado e a funcionar melhor do que nunca. A nossa stack tecnológica é de nível de produção: uma base de dados PostgreSQL, um backend FastAPI, um ERP personalizado em Retool, extratores automatizados a correr a cada 15 minutos, enriquecimento de produtos por IA e sincronização de anúncios em múltiplos marketplaces.
Processamos milhares de SKUs, gerimos perto de 100 encomendas por dia distribuídas por mais de 12 contas Wallapop além do eBay, e temos total visibilidade sobre cada métrica que importa — desde os tempos de resposta nos chats até às taxas de rotação de inventário.
Nada disto existiria na sua forma atual sem a DANA. Não porque a cheia tenha sido uma coisa boa — não foi — mas porque obrigou ao tipo de introspeção e reconstrução radical que raramente temos a coragem de fazer quando as coisas estão "a funcionar bem".
Por vezes, a competência de engenharia mais importante não é escrever código. É saber que, quando tudo se desmorona, conseguimos juntar os pedaços, organizar o caos e construir algo melhor.