Toda escolha técnica boa começa com uma pergunta desconfortável: quais são as restrições reais? Enquanto você não responde isso, qualquer comparativo é teatro. Você acaba copiando a stack de uma big tech e herdando os problemas dela sem herdar nem a escala nem o time que aguenta o tranco.
Cargo cult custa caro
Cargo cult é quando aviões de madeira aparecem porque alguém viu que aeroportos de verdade tinham pistas. Em tecnologia é a mesma coisa: adotar Kubernetes, microserviços ou aquele banco NoSQL da moda porque uma empresa famosa usa, sem perguntar por que ela usa.
O problema não é a ferramenta. É importar a solução sem importar o problema. A Netflix tem motivos concretos para a arquitetura dela. Você, com três devs e 200 usuários, provavelmente não tem os mesmos. Copiar o ritual não traz o resultado.
Comece pelas restrições, não pelo cardápio
A maioria das discussões de escolha técnica começa errada: pelas opções. "React ou Vue?", "Postgres ou Mongo?". Isso é abrir o cardápio antes de saber se você tem fome, dinheiro ou alergia.
Inverta. Escreva primeiro as restrições reais:
- Time: o que a equipe já domina? Contratar quem sabe X é fácil na sua região?
- Prazo: dá pra aprender algo novo agora ou o deadline é semana que vem?
- Operação: quem vai manter isso às 3h da manhã?
- Dados e SLA: qual o custo de perder ou atrasar um registro?
Com as restrições na mesa, metade das opções se elimina sozinha. O cardápio encolhe, e aí sim a conversa fica curta.
Trade-off é conta, não opinião
Não existe tecnologia sem preço. Existe preço que você enxerga e preço que te pega depois. Escolha errada não é a que tem defeitos; é a cujos defeitos você descobriu tarde.
Para cada finalista, escreva o que ela cobra: curva de aprendizado, custo de operação, maturidade do ecossistema, tamanho da comunidade, lock-in. Uma tabela feia num arquivo de texto já vale mais que uma hora de debate no Slack, porque força cada opinião a virar linha comparável.
E cuidado com o viés do brilho: a ferramenta nova sempre parece resolver tudo porque você só viu a demo, nunca a produção às sextas-feiras.
Prefira o chato e comprovado
Em dúvida técnica, aposte no chato. Tecnologia chata é aquela que já apanhou bastante: tem documentação madura, tem gente no mercado que sabe usar, tem os bugs mapeados no Stack Overflow desde 2018.
Postgres é chato. Um monólito bem organizado é chato. Uma fila simples é chata. E chato, aqui, é elogio: significa previsível. Você gasta seu orçamento de inovação onde ele gera vantagem de negócio, não reinventando persistência de dados.
A regra prática: tenha no máximo uma ou duas apostas ousadas por projeto. O resto deve ser tão sem graça que ninguém precise pensar nele.
Quanto custa voltar atrás
O fator mais ignorado numa decisão é o custo de desfazê-la. Existem escolhas de porta-dupla — você entra, testa, e se não gostar volta sem sequela. E existem escolhas de porta-única: atravessou, colou, e sair custa uma migração de meses.
Trocar de biblioteca de gráficos é porta-dupla; decida rápido, não perca sono. Escolher o banco de dados principal, o modelo de dados ou o provedor de cloud com todo o ecossistema acoplado é porta-única; ali vale medir três vezes.
Quanto mais irreversível a decisão, mais rigor ela merece — e mais vale pagar para manter a saída aberta (uma camada de abstração, um formato de dados portável). Quanto mais reversível, mais barato é só decidir e seguir.
Decida e escreva: o ADR
Decisão que não foi registrada não existe — vira lenda oral que ninguém lembra o porquê seis meses depois. Escreva um ADR (Architecture Decision Record): um arquivo curto no próprio repositório com contexto, opções consideradas, a decisão e as consequências esperadas.
Não precisa ser bonito. Precisa responder à pergunta que alguém fará no futuro: "por que diabos escolhemos isso?". Com o ADR, a resposta é um commit, não uma reunião.
Escolher bem não é acertar sempre. É decidir com as restrições claras, os trade-offs anotados, o custo de reversão pesado — e deixar registrado. Assim, quando o contexto mudar (e vai), você revisa uma decisão, não arqueologia. Prefira o chato, escreva o porquê, e siga construindo.