01 / 10

Durante anos, um website foi o bicho-papão em que ninguém queria tocar. Estava feito, estava no ar, e cada alteração pedia tempo, várias etapas e reprogramar tudo à mão. Hoje escrevo o contrário na página inicial deste site: um website deixou de ser estático. É um organismo vivo, que muda ao ritmo das tuas ideias.

Este artigo explica porquê. Primeiro em linguagem de todos os dias, depois com a engenharia e a teoria que estão por trás, para quem quiser confirmar que isto não é conversa de vendedor.

Porque é que um site era um bicho-papão

As ferramentas existiam. Já havia repositórios, cópias de segurança, históricos e controlo de versões. O que pesava era o custo de cada alteração, medido em tempo.

• Tudo era reprogramado à mão. Cada mudança, por pequena que fosse, era escrita linha a linha por alguém que conhecia aquele código.
• Cada alteração passava por várias etapas. Desenhar, desenvolver, testar, corrigir, voltar a testar. Cada etapa tinha a sua espera, e muitas vezes a sua pessoa.
• Mudar pouco custava quase o mesmo que mudar muito. As etapas eram as mesmas para trocar uma frase ou para criar uma página. É como chamar uma equipa de obras para mudar uma lâmpada.

Com esta conta, a decisão sensata era juntar pedidos e adiar. O site ficava como estava, cada vez mais longe do negócio.

O ciclo que nunca fechava

Quando a alteração era mesmo necessária, começava uma sequência que quem fez sites da forma antiga conhece bem. Pensar a ideia. Perceber as complicações e as tecnologias necessárias. Testar. Desenvolver. Voltar a testar. Retificar. Desenvolver outra vez. Redesenhar. E o ciclo recomeçava.

Cada volta pedia uma equipa dedicada e dias ou semanas de espera. Na engenharia de software isto tem nome: o custo da mudança. Barry Boehm mostrou, nos anos 80, que uma alteração fica mais cara quanto mais tarde é feita. Durante muito tempo aceitou-se isso como uma lei da natureza, e os projetos tentavam decidir tudo no início para não mexer depois.

O que mudou, em quatro peças

Hoje o caminho é curto: pedes, fica feito, está no ar. Assenta em quatro peças. As três primeiras já existiam e continuam a ser a rede de segurança. A quarta é a que mudou a conta.

1. Um histórico de tudo. O site vive num sistema de controlo de versões (o Git). Cada alteração fica guardada como um passo, com data e descrição. Funciona como o histórico de um documento partilhado, mas para o site inteiro: vê-se o que mudou e pode voltar-se a qualquer ponto.

2. O site é montado antes de ser publicado. As páginas são geradas de uma só vez, como ficheiros prontos, e só depois substituem as que estão no ar. Se alguma página falhar na montagem, a publicação pára e o site que os visitantes veem não é tocado. É a diferença entre ensaiar e improvisar em palco.

3. A publicação é automática. Os mesmos passos, pela mesma ordem, de todas as vezes, sem ninguém a enviar ficheiros à mão. Na engenharia chama-se entrega contínua. Neste site, uma alteração demora entre meia hora e uma hora a chegar ao ar, sem intervenção de ninguém.

4. IA na execução, uma pessoa na decisão. A IA lê o site inteiro e escreve o código da alteração em minutos. Era este o trabalho que pedia uma equipa dedicada a cada linha. O que muda, e se ficou bem, continua a ser decidido por mim e pelo cliente.

Foi a quarta peça que tirou o trabalho manual de cada alteração. O custo de mudar deixou de depender do tempo de uma equipa, e passou a estar ao alcance de um negócio pequeno.

A teoria: isto não é uma moda

Em 1980, Meir Lehman publicou as suas leis da evolução do software. A primeira, a da mudança contínua, diz que um sistema usado no mundo real tem de ser adaptado continuamente, ou torna-se cada vez menos útil. O mundo à volta muda, e um sistema parado fica para trás mesmo sem se estragar. Um site parado é o exemplo perfeito: os preços, os serviços e as fotografias do negócio mudaram, e ele não.

A segunda ideia vem da investigação sobre equipas de software reunida no livro Accelerate (Forsgren, Humble e Kim, 2018). As equipas que publicam alterações pequenas e frequentes têm também menos falhas e recuperam delas mais depressa. Velocidade e estabilidade andam juntas, ao contrário do que a intuição diz.

A razão percebe-se sem ser engenheiro. Uma alteração pequena tem poucas coisas que podem correr mal, e quando corre mal sabe-se logo onde. Uma alteração enorme, feita uma vez por ano, junta cem riscos numa só noite.

A prova é este site

Este site entrou no ar a 29 de setembro de 2026. Nos primeiros seis dias foi publicado 70 vezes. Cada publicação é uma alteração real: um texto afinado, uma galeria corrigida, uma secção nova, tipos de letra mais leves.

O melhor exemplo é a frase do título. A 4 de outubro entrou na página inicial uma secção sobre este tema. Na mesma noite vi-a no ar, tirei um bloco que estava a mais e reescrevi a frase final até chegar à que lá está. Na página Trabalhos, uma faixa de imagens começou no topo, com todos os projetos, e acabou no fim da página, mais pequena, só com os trabalhos que não têm página própria. Tudo numa noite.

Da forma antiga, cada uma destas voltas seria um pedido, uma espera e uma fatura.

O que «vivo» não quer dizer

• Não quer dizer instável. Cada alteração fica registada, é vista em computador e em telemóvel antes de ir para o ar, e pode ser desfeita.
• Não quer dizer mudar por mudar. O site muda quando o negócio precisa ou quando há uma ideia melhor.
• Não quer dizer que tudo é instantâneo. Boas fotografias, um bom texto e uma decisão bem pensada continuam a levar o tempo que levam. O que deixou de demorar foi a execução.

O que isto significa para um negócio

Um negócio muda todas as semanas: um preço, um serviço novo, uma campanha, uma fotografia melhor. Às vezes muda mais: um tema novo, um branding que mudou, uma página ou uma funcionalidade que passou a fazer falta, outra língua. As ideias são infinitas. Um site estático obriga a escolher entre pagar cada alteração como um projeto ou deixá-lo desatualizado. Um site vivo acompanha todas.

E como o código é teu e fica num repositório na tua conta, essa liberdade não depende de mim: podes continuar comigo, com a tua equipa ou com a tua própria ferramenta de IA.

Se tens um site em que ninguém se atreve a mexer, fala comigo.

Para quem quiser ir mais fundo

• Barry Boehm, Software Engineering Economics (1981): o custo de alterar um sistema ao longo do tempo.
• Meir Lehman, «Programs, Life Cycles, and Laws of Software Evolution», Proceedings of the IEEE (1980): a lei da mudança contínua.
• Jez Humble e David Farley, Continuous Delivery (2010): publicação automática, em passos pequenos.
• Nicole Forsgren, Jez Humble e Gene Kim, Accelerate (2018): a relação entre frequência de publicação e estabilidade.