O stack que ninguém atualiza não avisa antes de cobrar

Revisei produtos rodando em versões que morreram anos atrás, e o padrão se repete: ninguém decide congelar o stack, ele congela sozinho porque manutenção não cabe em orçamento nenhum. A conta chega inteira num dia ruim, e quem cuida disso semana a semana quase nunca deixa ela chegar.

Faz uns dois meses sentei com o CTO de um SaaS de agendamento para clínicas. Produto de pé, faturando, uns quarenta mil agendamentos por mês. Ele queria me mostrar um bug bobo no lembrete de consulta, um SMS que saía com a data trocada, e no meio da conversa percebeu que não conseguia nem rodar o projeto na própria máquina sem apanhar.

O clone limpo não subia. Era Node 14, que parou de receber suporte lá em 2023, e uma biblioteca de datas três versões maiores atrás do que o resto do mundo usa. Levou dois dias até o projeto compilar de novo. O tal lembrete errado, que era pra sair no mesmo dia, esperou nove.

O que me chamou atenção não foi o atraso. Foi que ninguém, em momento nenhum, tinha decidido deixar aquilo para trás. Cada sprint teve um bom motivo pra adiar a atualização. Somados, os bons motivos viraram um produto que ninguém consegue mexer sem medo.

Uma dependência que ninguém atualiza é como cano velho atrás da parede: funciona até o dia em que você precisa abrir tudo.

Congelar é uma omissão, não uma decisão

Quase nunca existe a reunião em que alguém diz "vamos parar de atualizar o stack". Seria fácil se existisse, dava pra discordar. O que existe é uma sequência de sprints em que subir a versão de uma dependência perde, toda vez, para uma tela nova que o cliente pediu. A tela aparece na demo. A atualização não aparece em lugar nenhum, até o dia em que trava tudo.

E aqui entra um incentivo que vale nomear. Um fornecedor pago para entregar feature, e só, não tem razão nenhuma para gastar meia sprint subindo uma biblioteca que o cliente nunca vai ver. Se ele só encosta no código quando algo quebra, manutenção preventiva é literalmente trabalho que ninguém vai elogiar. O bodyshop disfarçado de squad vive disso: cobra pela presença e não responde por manutenção nenhuma.

Vou ser justa, porque nem tudo é cálculo frio. Boa parte é só o óbvio: atualizar dependência é chato, dá um trabalho ingrato, e nunca é o item mais urgente da semana. O problema é a ausência de qualquer decisão, repetida umas cinquenta vezes seguidas. E o que congela junto com a versão não é só o código: é o time que você consegue contratar pra mexer nele e a lista de brechas de segurança que você ainda pode fechar.

A conta some do orçamento e reaparece na pior hora

O jeito mais caro de descobrir que o stack congelou é por um aviso de segurança. Vi acontecer com uma empresa que precisou fechar uma vulnerabilidade conhecida numa dependência, coisa que deveria ser um "sobe a versão e pronto". Só que subir aquela versão puxava outra, que puxava outra, uma reação em cadeia de três anos de atualização adiada. Foi perto de R$ 38 mil de retrabalho ao longo de quase três semanas.

E esse número eu arredondei para cima de propósito, admito: uma parte era refatoração que fariam de qualquer jeito. Mas mesmo cortando um terço, continua caro demais para um problema que ninguém escolheu ter, que apareceu justo na semana em que o time tinha outra entrega pra fechar.

O custo de manter nunca aparece na fatura do mês. Ele espera acumular e cobra de uma vez.

Tem ainda uma conta que quase ninguém soma: a de contratação. Runtime morto afugenta dev bom. Ninguém sênior quer passar o dia dando manutenção em versão que saiu de suporte, e quem conhece aquele stack antigo a fundo está justamente indo embora, levando o conhecimento na cabeça. Você não fica só com um produto difícil de manter. Fica com um produto difícil de contratar pra manter, que é bem pior.

Vinte minutos para saber se o seu stack congelou

Não precisa de auditoria formal para sentir o cheiro. Dá pra fazer um raio-x rápido você mesmo, ou pedir para quem cuida do seu código responder na sua frente. São quatro perguntas.

1. O seu runtime ainda tem suporte?

Abra o endoflife.date e procure a versão de Node, Python, Ruby ou PHP que roda em produção. Se a data de fim de suporte já passou, você não está "quase atrasado". Já está rodando algo que ninguém mais conserta lá fora.

2. Quantos majors atrás estão as suas cinco principais dependências?

Pegue as cinco bibliotecas que aparecem em todo lugar do código. Se alguma está duas versões maiores ou mais atrás da atual, existe um muro se formando ali, e ele só engorda enquanto ninguém olha.

3. Quando foi o último PR que só subiu dependência?

Procure no histórico do git o último commit que teve como único objetivo atualizar biblioteca. Se você precisa rolar meses para achar, upkeep não é rotina na sua casa. É emergência esperando a hora de acontecer.

4. Um clone limpo builda em quanto tempo?

Clone o projeto numa pasta nova, siga o README à risca e cronometre. Se passar de uma tarde, o ambiente já virou conhecimento tribal, e conhecimento tribal é a coisa mais frágil que um produto pode ter. Dois dias, como no SaaS do começo, é um grito.

Esse raio-x de quatro perguntas é mais ou menos o que a gente roda logo na primeira leitura de um cliente, no Diagnostic Sprint, antes de escrever qualquer linha. Coloca na mesa em duas semanas o que costuma virar crise em seis meses, e quem quiser ver de perto pode começar pelo diagnóstico de duas semanas.

Um time que fica não deixa congelar

A diferença de um squad que vai manter o que escreve não está em talento maior, está em ficar. Quem sabe que vai conviver com a base daqui a um ano trata atualização como tarefa de rotina: um pouco a cada sprint, uma dependência de cada vez, nunca a migração heroica de fim de semana que vira lenda no time. Na Revin isso é regra da casa, não favor: dependência entra no mesmo fluxo do resto do trabalho, com o mesmo cuidado de uma feature.

O CTO do agendamento me perguntou, meio sem graça, se o caso dele era grave. Falei que não, e é verdade: grave é quando trava e vira notícia. O dele ainda estava no estágio silencioso, aquele em que dá pra resolver sem drama, contanto que alguém assuma a rotina. Os nossos cases contam essa história melhor do que eu, porque mostram o antes e o depois.

Se você leu até aqui e não sabe de cabeça em qual versão o seu produto roda, essa é a deixa para os vinte minutos das quatro perguntas. E se a resposta assustar, marca uma conversa com a gente para olhar junto, que acompanhado costuma sair bem mais barato do que sozinho.