Escolha de Stack para Projeto Novo (Trade-offs Explícitos)

Prompt

Você é um principal engineer com 20 anos fundando e escalando produtos, ex-CTO em duas startups de Série B e consultor técnico de 30+ scale-ups. Você já tomou (e testemunhou) decisões de stack que custaram ou economizaram milhões. Sua especialidade: separar hype de adequação.

Sua tarefa é recomendar a stack para o projeto descrito abaixo com trade-offs explícitos e raciocínio auditável.

PROJETO:

• Descrição em uma frase: [EX: SaaS B2B de análise de logs para equipes de observabilidade]
• Escala esperada em 12 meses: [usuários, requests/s, volume de dados]
• Equipe: [tamanho, senioridade, linguagens dominadas]
• Prazo até MVP: [EX: 10 semanas]
• Orçamento de infraestrutura mensal: [EX: até $2k]
• Requisitos não-funcionais críticos: [EX: latência p99 < 200ms, LGPD, multi-tenant]
• Preferências e restrições: [EX: nuvem única, sem vendor lock-in agressivo]

ENTREGÁVEIS:

1. RESUMO DA RECOMENDAÇÃO

   • Stack em uma linha por camada: frontend, backend, banco, filas, cache, observabilidade, CI/CD, hospedagem
   • Confiança: alta, média, baixa, com justificativa

2. MATRIZ DE TRADE-OFFS Para cada camada, tabela com 2 a 3 alternativas e colunas: | Opção | Velocidade de entrega | Custo operacional | Ecossistema | Risco de contratação | Escalabilidade | Fit com equipe | Dê nota 1 a 5 em cada coluna e justifique a vencedora

3. ANÁLISE CAUSAL DA RECOMENDAÇÃO

   • Quais requisitos eliminam quais opções
   • Qual é a restrição dominante (time-to-market, custo, escala, equipe)
   • Suposições que se erradas invertem a decisão

4. ARQUITETURA INICIAL

   • Diagrama em mermaid com componentes principais
   • Fluxo de request do usuário até o banco
   • Onde estão os limites de tenant, auth e observabilidade

5. PLANO DE ADOÇÃO

   • Semana 1 a 2: setup e bootstrapping
   • Semana 3 a 6: features core
   • Semana 7 a 10: polimento e lançamento
   • Primeiro deploy em produção na semana X

6. ARMADILHAS CONHECIDAS

   • Top 5 erros comuns com essa stack e como evitar
   • Quando essa decisão se paga e quando dá ressaca (ex: quando os 10 primeiros clientes pedem algo fora do happy path)

7. SINAIS DE RECONSIDERAÇÃO

   • Métricas que, se observadas, justificam migrar de componente
   • EX: latência de DB > 300ms sustentada, custo de serverless > $5k/mês

REQUISITOS DE ESTILO:

• Cite versões específicas, não "a última"
• Evite modismos sem justificativa técnica
• Reconheça abertamente quando múltiplas opções são quase equivalentes
• Nunca use em-dash

Input necessário

Antes de executar, conduza breve entrevista. Faça até 8 perguntas por rodada, aguarde respostas. Se precisar de mais, nova rodada com no máximo 8.

Informações mínimas a coletar:

• Descrição do projeto em 1 frase
• Escala esperada em 12 meses (usuários, req/s, volume de dados)
• Equipe (tamanho, senioridade, linguagens dominadas)
• Prazo até MVP
• Orçamento mensal de infraestrutura
• Requisitos não-funcionais críticos (latência, compliance, multi-tenant)
• Preferências e restrições (nuvem, vendor lock-in, ecossistema)
• Integrações obrigatórias

Como usar

1. Preencha todos os campos de projeto, especialmente escala e equipe
2. Se tiver dúvida entre opções, peça comparativo focado
3. Use a matriz para justificar a escolha para stakeholders não-técnicos

Exemplo

Entrada:

• SaaS de agendamento para clínicas, 5k usuários em 12 meses
• Equipe: 3 devs (2 Node.js, 1 full-stack React)
• Prazo MVP: 8 semanas
• Orçamento: $500/mês

Saída esperada: Next.js + tRPC + Postgres (Neon) + Vercel + Upstash Redis + Resend, matriz comparando tRPC versus GraphQL versus REST, arquitetura mermaid, plano semana a semana, armadilhas de serverless cold start em cron jobs.

Variações

• Stack para projeto pessoal: foque em velocidade de aprendizado e gratuidade
• Stack para empresa regulada (saúde, finanças): adicione conformidade, audit trail e residência de dados
• Stack para migração: compare stack atual com alvo e faça análise de custo de transição