Primeiro, um facto tranquilizador e verificável: uma aplicação gerada fixa as suas dependências à versão EXATA, Next, React, Prisma e as restantes são travadas ao número preciso, não a uma faixa (ex.: ^1.2.0 ou ~1.2.0). Por isso, reinstala-se identicamente daqui a dois anos e não se quebra sozinha. O que exige manutenção são três coisas distintas: as atualizações de segurança das bibliotecas, a hospedagem e as suas próprias evoluções de negócio. Enquanto a aplicação estiver a funcionar no URL incluído, as duas primeiras não lhe custam nada; no dia em que a hospedar pessoalmente ou alterar o seu código, ela torna-se um software como qualquer outro, e, como o código é Next.js e Prisma padrão, de sua propriedade, qualquer programador pode retomá-lo.
Uma aplicação que funciona não se degrada sozinha
A intuição sugere que o software «envelhece» e acaba por falhar por si só. Não é isso que acontece. O ficheiro `package.json` de uma aplicação gerada fixa cada dependência à sua versão EXATA, sem faixa, sem «última versão compatível»: apenas o número exato. Reinstalar a aplicação daqui a dois anos reconstrói exatamente a mesma árvore de bibliotecas do primeiro dia, e o código, por seu lado, não mudou um único byte.
O que se degrada é o ambiente à sua volta: o certificado que expira, o servidor que é migrado, a versão do Node que um fornecedor de hospedagem retira e, sobretudo, as atualizações de segurança que versões fixas deixam de receber. Trata-se de uma diferença de natureza face a «o software avariou», e muda completamente o que é preciso prever.
Três tipos de manutenção distintos, frequentemente confundidos
O primeiro é a SEGURANÇA das bibliotecas: uma vulnerabilidade detetada numa dependência requer uma atualização de versão. É o único tipo de manutenção com um relógio interno, e não depende da sua atividade.
O segundo é a HOSPEDAGEM: o domínio, o certificado, a base de dados, as cópias de segurança. Enquanto a aplicação for servida no URL incluído, essa responsabilidade cabe à plataforma, e é também a pergunta precisa a colocar, aqui como a qualquer fornecedor: qual é a política de cópias de segurança? No dia em que migrar a aplicação para o seu próprio servidor, esta responsabilidade passa para si.
O terceiro não é manutenção, mas TRABALHO: adicionar um campo, um estado, um ecrã porque o seu negócio evoluiu. Isso só ocorre se o solicitar, e é tratado à sua própria escala, é precisamente o tema do guia «evoluir a sua aplicação».
Quem pode fazê-lo e por que ninguém o retém
O código é Next.js e Prisma padrão, exportável como arquivo ZIP ou enviado para o GitHub, e pertence-lhe. Não há dialectos proprietários nem formatos que só o editor saiba interpretar: o programador que retoma o projeto trabalha com ferramentas que já conhece bem, e é isso que torna possível a transição sem a nossa intervenção. É exatamente o oposto de uma ferramenta fechada, onde «quem a manterá?» só tem uma resposta, o editor, enquanto existir.
A contrapartida é honesta: no dia em que alterar esse código pessoalmente, a versão em execução deixa de ser aquela que a plataforma sabe regenerar. Ganha liberdade total e assume também a responsabilidade pela manutenção. Muitas pequenas estruturas nunca dão este passo, e não precisam de o dar, mas a porta permanece aberta, e é isso que importa no dia em que decidir atravessá-la.
O que é realmente preciso provisionar
Num software desenvolvido à medida, a literatura do setor aponta para uma manutenção corretiva da ordem de 15 a 20 % do custo inicial por ano, e para o conjunto manutenção + evoluções correspondendo a cerca de metade do custo total de propriedade (TCO) ao longo de cinco anos. É a rubrica que quase ninguém orça, e é ela que transforma um projeto bem-sucedido num instrumento abandonado três anos depois.
O cálculo muda quando o custo inicial é reduzido e a hospedagem está incluída: não há nada a provisionar enquanto a aplicação funcionar tal como foi gerada. A despesa reaparece apenas em dois locais, se migrar a hospedagem para os seus próprios servidores ou se encomendar alterações ao código. Decidir com estes dois cenários em mente é mais sensato do que pagar um seguro contra uma avaria que, em versões fixas, simplesmente não ocorre.