Eu estava em um evento de aceleração quando meu celular tocou. Era um dos nossos engenheiros, com aquela voz que você reconhece na hora: algo deu muito errado.
"Deletei o banco de dados. Estava rodando local, mudei pro banco de produção pra testar com dados reais, esqueci de voltar pro banco local e deletei."
Silêncio.
A Joga tinha cerca de um ano de dados. E naquele momento, tudo parecia ter ido embora.
A história tem um final menos trágico do que poderia. Tínhamos backups. Perdemos algumas horas de informações, e conseguimos recuperar parte delas por outros meios. O prejuízo foi controlado.
Mas esse episódio me fez pensar em algo que já ocupava minha cabeça há um tempo: e se isso tivesse acontecido durante uma due diligence? E se um potencial comprador estivesse olhando nossa operação naquele exato momento?
E se alguém bater na porta amanhã?
Não sei dizer se compradores realmente olham tecnologia e processos com lupa, ou se estão mais interessados na base de clientes, no mercado, no time. Provavelmente depende do caso.
O que sei é que essa sempre foi uma preocupação minha. Eu operava a Joga como se alguém pudesse bater na porta a qualquer momento querendo entender como tudo funcionava. Não porque eu estava planejando vender, mas porque achava que empresas bem organizadas são mais fáceis de operar, de escalar, e de manter funcionando quando as coisas inevitavelmente dão errado.
E quando as coisas dão errado, como naquela ligação, a diferença entre desastre e inconveniente está nos cuidados que você tomou antes.
O lado do código
Meu raciocínio sempre foi: se eu saísse amanhã, quanto tempo levaria para outra pessoa entender o que construímos?
Por isso eu insistia em código organizado e fácil de entender. Arquitetura clara, nomes que fazem sentido. Não por perfeccionismo, mas porque eu sabia que um dia alguém ia precisar mexer naquilo sem poder me perguntar o que eu estava pensando quando escrevi.
Testes unitários mostravam os casos de uso, os edge cases, as regras de negócio que alguém teve que pensar em algum momento. Mais do que pegar bugs, eles explicavam o sistema.
Monitoramento e alertas entravam na mesma lógica. Saber que algo quebrou antes do cliente reclamar era o mínimo. Ter visibilidade da saúde do sistema em tempo real me deixava dormir mais tranquilo.
E backups, como aprendi naquela ligação, não são opcionais. Mas backup que você nunca testou restaurar é só uma ilusão de segurança. Por sorte, o nosso funcionava.
O lado da operação
Tecnologia era metade da minha paranoia. A outra metade era como a empresa operava no dia a dia.
Eu pensava assim: se o nosso melhor vendedor sai amanhã, quanto tempo leva para o próximo atingir o mesmo nível? Se o líder de suporte fica doente, o time sabe exatamente o que fazer em cada situação?
Por isso eu queria playbooks para tudo. Onboarding de clientes, atendimento, processo de vendas, problemas técnicos. Tudo documentado de forma que qualquer pessoa competente conseguisse executar.
Meu medo era que o conhecimento morasse só na cabeça das pessoas. Porque conhecimento na cabeça das pessoas vai embora junto com elas.
Olhando para trás
Olhando para trás, algumas coisas poderiam ter sido melhores. Tínhamos backup, mas poderíamos ter tido processos mais rígidos para acesso ao banco de produção. Tínhamos conhecimento, mas nem todo ele estava documentado como eu gostaria.
A preparação para uma eventual venda, se é que isso pesa tanto assim, não é algo que você faz nos seis meses antes de começar a conversar. É algo que você constrói desde o início, como parte da cultura de como a empresa opera.
Por outro lado, se tentar cobrir 100% dos detalhes, com certeza irá perder velocidade para evoluir o negócio e o produto. A busca contínua pelo equilíbrio é o desafio do dia a dia.
No final das contas o principal aprendizado é de dar velocidade enquanto está no processo de descoberta e validação (testando uma nova funcionalidade, novos processos, etc.), e dar maturidade quando entrar no processo de replicação.
Agora quero ouvir o outro lado
O Henrique Tormena é meu parceiro nesse projeto e vive o dia a dia do M&A pelo lado do comprador. Algumas perguntas ficam martelando na minha cabeça, e quero jogar para ele:
Na prática, o quanto a qualidade técnica realmente pesa na decisão de compra? Ou isso é mais coisa da minha cabeça de engenheiro?
Quando você olha uma startup para adquirir, o que te faz desistir rápido? Existe algum red flag técnico ou operacional que é deal breaker imediato?
Empresas compradoras realmente fazem due diligence técnica profunda? Ou é mais uma verificação superficial de que nada está pegando fogo?
Se a tecnologia está uma bagunça mas o negócio é bom, isso vira desconto no preço ou vira motivo para não comprar?
E sobre processos: o comprador espera encontrar tudo documentado, ou assume que vai ter que reconstruir a operação de qualquer jeito?
Vou passar essa bola pro Tormena.
Se gostou, compartilhe com alguém que possa aproveitar também.
thedeallab #11