A maioria das auditorias de MVP produz um documento. Uma útil produz decisões: o que está a arder, o que pode esperar e quanto custa corrigir.
Uma auditoria técnica de MVP responde a uma pergunta: esta base de código aguenta os próximos doze meses do negócio e, se não, o que exatamente tem de mudar? Todo o resto — preferências de ferramentas, discussões de estilo, escolha de framework — é ruído.
Esta é a checklist que percorremos nas primeiras 48 horas. Está deliberadamente ordenada pelo custo do erro: o que está no topo pode matar uma empresa, o que está em baixo custa velocidade.
1. Integridade do dinheiro e dos dados (maior custo de falha)
Se o produto movimenta dinheiro ou guarda dados regulados, isto vem primeiro. Falhas aqui não são incidentes — são passivos. Procuramos:
- Se os saldos derivam de um livro-razão append-only ou são guardados como um número mutável que o código pode sobrescrever
- Idempotência em cada rota de pagamento e webhook — um pedido repetido pode cobrar ou creditar duas vezes?
- Usar decimais exatos ou unidades inteiras com regras por moeda.
- Fronteiras transacionais: uma falha parcial pode deixar dinheiro duplicado ou em lado nenhum?
- Reconciliação: existe um processo que detete uma discrepância, ou saberiam por um cliente?
2. Segurança e controlo de acesso
- Autorização verificada no servidor em cada pedido, ou assumida porque a interface esconde o botão
- Segredos em variáveis de ambiente e num gestor de segredos, não no histórico do repositório
- PII e dados de cartão: o que é guardado, onde, e se deveria sequer ser guardado
- Vulnerabilidades de dependências realmente alcançáveis, não apenas um número vermelho num relatório
- Isolamento multi-tenant: um pedido forjado consegue ler dados de outro cliente?
3. Arquitetura e limites de escala
Não procuramos elegância. Procuramos a parede concreta contra a qual o sistema vai bater, e a que distância está.
- Os pontos únicos de falha — a base de dados, a fila, o serviço que todos chamam
- Padrões de consulta corretos com 1 000 linhas e fatais com 1 000 000 (N+1, índices em falta, varrimentos sem limite)
- Se é possível fazer deploy sem downtime, e se alguém alguma vez tentou
- Acoplamento que impede entregar uma funcionalidade sem tocar em cinco módulos
- Se a arquitetura corresponde ao tamanho da equipa — microsserviços com quatro engenheiros são um problema de escala, não uma solução
4. Entrega e operações
As bases de código não se degradam sozinhas; é o processo que decide a que velocidade. O que medimos:
| Sinal | Saudável | Sinal de alarme |
|---|---|---|
| Frequência de deploy | A pedido, várias vezes por semana | Mensal, cerimonial, temida |
| Tempo de entrega de uma alteração pequena | Horas a um dia | Semanas |
| Rollback | Um comando, ensaiado | Teórico |
| Cobertura de testes onde importa | Rotas de dinheiro e auth cobertas | Percentagem alta, rotas críticas sem testes |
| Observabilidade | Detetam antes dos clientes | Os clientes são a vossa monitorização |
5. Dívida técnica: triada, não listada
Todas as bases de código têm dívida. Listá-la é inútil. O que importa é a classificação em três baldes:
- Bloqueante — impede o roadmap ou põe dinheiro/dados em risco. Corrigir agora.
- Cumulativa — torna cada alteração futura mais lenta. Planear deliberadamente.
- Cosmética — ofende o gosto, não custa nada. Deixar em paz.
O objetivo de uma auditoria não é encontrar tudo o que está mal. É encontrar as poucas coisas suficientemente más para importarem, e ser preciso sobre quanto custam.
O que devem receber no fim
- Uma lista priorizada de constatações com severidade e impacto de negócio — não um catálogo
- Para cada constatação: a correção, uma estimativa realista de esforço e o que acontece se não fizerem nada
- Um roadmap sequenciado: este trimestre, o próximo, mais tarde
- Evidência — a consulta, o endpoint, a linha exata — para a vossa equipa poder verificar em vez de acreditar
Transformar a revisão inicial em trabalho verificável
Uma revisão limitada descreve cobertura, não ausência total de defeitos. Cada constatação precisa de verificação independente.
- Associar percurso afetado, evidência e condições de reprodução.
- Separar defeitos observados, riscos possíveis e áreas inacessíveis.
- Atribuir responsável e teste de regressão a cada correção.
Perguntas frequentes
Quanto tempo demora uma auditoria técnica de MVP?
Uma auditoria focada a uma base de código típica em fase seed demora 3 a 10 dias úteis, consoante o tamanho e a parte do sistema que movimenta dinheiro. As primeiras 48 horas cobrem as áreas de maior risco — fluxos de dinheiro, segurança e limites de escala — o que costuma bastar para saber se existe um problema sério.
Precisam de acesso aos nossos sistemas de produção?
Não. Acesso de leitura ao repositório, a arquitetura tal como está em produção e uma sessão com um engenheiro chegam para a avaliação. Acesso a produção só é necessário se também nos pedirem ajuda com incidentes em curso.
Qual a diferença entre code review e auditoria técnica?
Um code review avalia uma alteração. Uma auditoria avalia o sistema face ao plano de negócio: se aguenta o roadmap, sobrevive à escala, passa uma due diligence de investidor e não perde dinheiro. Cobre arquitetura, integridade de dados, segurança e processo de entrega — não apenas código.
Uma auditoria vai dizer-nos para reescrever tudo?
Quase nunca, e desconfiem de quem responde por defeito com uma reescrita. Reescritas são a opção mais cara e habitualmente a errada. Na maioria dos casos, um pequeno número de correções dirigidas elimina o risco real.
E se faltar acesso ao código ou à infraestrutura?
Marque as verificações como não confirmadas e explique a decisão pendente. Uma apresentação fornece contexto, mas não substitui evidência de execução.
Querem aplicar isto à vossa base de código?
Entregamos constatações priorizadas com estimativas de esforço — não um PDF de 50 páginas. Duas semanas, âmbito fechado.
Leitura complementar
Como consertar um MVP avariado (sem começar do zero)
Quase todos os fundadores com um MVP avariado perguntam se devem reescrevê-lo. Quase sempre a resposta é não — e a razão é aritmética, não sentimento.
Dívida técnica em startups: quanta é demasiada?
Todas as startups têm dívida técnica, e a maior parte foi a decisão certa. A pergunta não é como eliminá-la — é que partes cobram juros que já não consegue pagar.