Quando um site deixa de ser site e vira produto

O sinal não é técnico, é operacional

Nenhum site vira aplicação por decisão de arquitetura. Ele vira quando o trabalho manual em volta dele passa a custar mais que o próprio site.

O sintoma aparece antes no operacional: alguém copia dados do formulário para uma planilha, alguém responde o mesmo e-mail toda semana, alguém confere manualmente se o cliente pagou. Enquanto isso é raro, é aceitável. Quando vira rotina diária, o site já é um produto — só que sem software.

Os quatro sinais concretos

• Estado. Existe algo que muda de fase e alguém precisa saber em qual fase está. Pedido, proposta, matrícula, processo. Site não tem estado; aplicação tem.
• Regras que variam. O preço, o prazo ou a permissão dependem de quem é o cliente. Toda vez que a regra muda, alguém edita conteúdo à mão.
• Duas pessoas na mesma informação. Quando mais de uma pessoa precisa ver e alterar o mesmo registro, planilha compartilhada começa a perder dado.
• Repetição com padrão. A mesma sequência de passos, na mesma ordem, várias vezes por semana.

Um sinal isolado não justifica nada. Três ao mesmo tempo, sim.

O que não é sinal

Volume de acesso não é. Um site com muito tráfego e nenhuma regra continua sendo um site — resolve-se com cache, não com aplicação.

Vontade de modernizar também não é. Trocar a stack sem resolver um problema operacional entrega o mesmo trabalho manual num código diferente.

O erro caro: reconstruir tudo de uma vez

A reação comum é decidir refazer o site inteiro como aplicação. Quase sempre é a decisão errada, por dois motivos: o conteúdo continua sendo conteúdo e não ganha nada com a mudança, e a reconstrução total leva meses durante os quais o problema operacional continua igual.

O caminho mais barato costuma ser manter o site onde está e construir só o pedaço com regras — como aplicação separada, integrada por API.

Como começar pequeno e não errar

• Escreva o fluxo manual como ele acontece hoje, com os estados reais e quem faz o quê.
• Encontre o passo que consome mais tempo por semana. Só ele.
• Construa apenas esse passo, com dados de verdade, para quem já faz o trabalho.
• Meça se o tempo caiu. Se não caiu, o problema estava em outro lugar.

Depois repita. Um fluxo migrado por vez mantém o negócio funcionando enquanto o software cresce, e mostra cedo se a leitura do problema estava certa.