O método da casa

A primeira semana de qualquer projeto não tem código. A gente conversa pra entender qual é a dor real, quem sente, com que frequência, e o que já foi tentado pra resolver. Esse diagnóstico é o que separa software que resolve de software que existe.

Pergunta favorita da casa: "se a gente não construir nada, qual é o pior cenário?" Se a resposta é "fica como tá", o problema talvez não justifique investimento de software. Se a resposta é "perco cliente todo mês" ou "preciso contratar mais gente", aí faz sentido.

O entregável dessa fase é um documento curto: problema, quem sente, custo de não resolver, e três a cinco hipóteses de solução com tradeoff explícito. Ele vira a base de tudo que vem depois.

Stack é decisão técnica com consequência financeira. A casa escolhe pelo critério de manutenção: o que dá pra debugar no domingo às 3 da manhã quando algo quebrar, e o que continua existindo daqui a três anos.

Não tem framework favorito. Tem framework certo pra cada problema. Site institucional não precisa de RSC. Sistema interno com cinco usuários não precisa de Kubernetes. App com áudio sensível não pode rodar transcrição em servidor externo.

Toda escolha técnica tem alternativa considerada e motivo de descarte. Quando o cliente perguntar "por que não usaram X", a resposta é específica, não "porque era mais bonito".

Documentação na Sennin Code não é manual de uso, é registro de decisão. Cada ADR (Architectural Decision Record) responde: o que decidimos, qual era o contexto, quais alternativas consideramos, e por que essa.

O cliente recebe acesso ao repositório com tudo registrado. Quando trocar de fornecedor (acontece), o próximo dev entende as escolhas em uma tarde, não em três semanas de engenharia reversa.

Esse é o pedaço da metodologia que parece exagero pra quem não passou pela situação de herdar código mal documentado. Quem já passou sabe que isso vale ouro.