Software em Produção em Dias: Arquitetura e Salvaguardas

"Entregue em dias" costuma provocar uma de duas reações. Quem não é técnico ouve "barato e provavelmente com problemas". Quem é técnico ouve "sem testes, sem staging, boa sorte". As duas reações são merecidas — a maioria do trabalho rápido é desleixado, porque a velocidade foi comprada à custa de eliminar os passos que protegem o cliente.

Há outra forma de ser rápido: manter todos os controlos de qualidade e comprimir tudo o resto. É isso que faz um processo acelerado por IA nas mãos de um engenheiro sénior. Este artigo explica a divisão — o que se acelera, o que nunca se acelera — para que consiga avaliar qualquer fornecedor rápido, incluindo nós.

Porque é que "rápido" ganhou má fama

Os prazos das agências tradicionais são longos por razões estruturais: passagens de testemunho entre gestor de conta, designer e programador; trabalho em fila atrás de outros clientes; programadores juniores a produzir código que um sénior depois reescreve. Um site de PME orçamentado em Lisboa entre €3.000 e €6.000 com prazo de 8 a 12 semanas pode conter 2 a 3 semanas de trabalho real. O resto é coordenação.

Os fornecedores "rápidos e baratos" atacam o lado errado da equação. Mantêm os juniores e cortam a revisão, os testes e o ambiente de staging. Recebe o site numa semana e passa o ano seguinte a pagá-lo — em erros, num layout móvel que ninguém verificou, numa reconstrução ao fim de catorze meses.

O caminho certo é o inverso: cortar a coordenação, manter a engenharia.

O que a IA acelera de facto

As ferramentas de IA para código são excelentes numa classe específica de trabalho — os 70% previsíveis e repetitivos de qualquer projeto:

Trabalho	Tempo tradicional	Acelerado	Porque é seguro acelerar
Estrutura do projeto (configuração, rotas, deploy)	1–2 dias	Menos de uma hora	É o mesmo padrão comprovado, projeto após projeto
Primeiras versões de páginas e componentes	1–2 semanas	1–2 dias	Os rascunhos são sempre revistos e reescritos
Base da suíte de testes	2–4 dias	Horas	As verificações continuam a ser escritas e validadas por um humano
Modelos de dados e endpoints (CRUD)	3–5 dias	Horas	Altamente convencional; a revisão foca-se nos desvios
Variantes de texto, validação de formulários, casos-limite	Dias	Horas	Barato de gerar, barato de verificar

Repare no padrão: tudo nesta lista é revisto depois ou suficientemente determinístico para a revisão ser trivial. A IA gera volume; um engenheiro sénior decide o que entra em produção.

O que nunca se salta

Esta é a lista que separa rápido de desleixado. Se um fornecedor que promete dias não responder "sim, sempre" a cada linha, procure outro.

• Código com tipos. Todos os projetos são entregues em TypeScript com verificação estrita. Os erros de tipo são apanhados na compilação, não pelos seus clientes. O código gerado por IA passa pelo mesmo compilador que o código escrito à mão — sem exceções.
• Testes automáticos nos percursos que geram receita. Não é teatro de cobertura a 100% — são testes dirigidos ao checkout, aos formulários de contacto, ao login, a tudo onde uma falha silenciosa custa dinheiro. Correm automaticamente a cada alteração.
• Ambiente de staging. Nada vai de um portátil para produção. Cada alteração é publicada primeiro num endereço privado de staging, é verificada à mão, e só depois é promovida. Com alojamento moderno isto demora minutos — não há desculpa de prazo para o saltar.
• Verificação real em telemóvel. Mais de 60% do tráfego web em Portugal é móvel. "Deve funcionar no telemóvel" não é uma verificação. Dispositivos reais ou emulação rigorosa, antes do lançamento.
• Desempenho medido. Não é "parece rápido" — é medido. Pontuações Lighthouse, Core Web Vitals, peso da página em kilobytes. Um processo de construção veloz não vale nada se o site entregue demora seis segundos a carregar em 4G.
• Revisão sénior de cada linha. Mais sobre isto abaixo, porque é aqui que tudo se decide.

As salvaguardas, em checklist

Se está a avaliar um fornecedor de criação de sites com entrega rápida, esta é a lista concreta:

1. Tipagem estrita imposta pela compilação — o projeto literalmente não consegue ser publicado com erros de tipo.
2. Integração contínua que corre os testes a cada alteração — não "corremos testes antes das grandes versões".
3. Endereço de staging que o cliente pode ver antes do lançamento — peça-o. Se hesitarem, já sabe tudo.
4. Análise automática de dependências e vulnerabilidades — a IA por vezes sugere pacotes desatualizados; a análise apanha-o.
5. Controlo de versões com histórico revisível — cada alteração rastreável, cada erro reversível em minutos.
6. Orçamento de desempenho verificado antes do lançamento — acorde um número (por exemplo, interativo em menos de 2,5 segundos num telemóvel médio) e confirme-o.
7. Plano de reversão — publicar deve ser reversível num comando. Se a noite de lançamento exige coragem, o processo está partido.
8. Um humano responsável por cada linha aprovada — a IA não tem reputação a perder. O engenheiro tem.

Nenhuma destas salvaguardas é lenta. A maioria corre em segundos e não custa nada depois da configuração inicial. É por isso que saltá-las é um sinal de alarme: quem salta verificações gratuitas está a dizer-lhe como pensa.

A revisão sénior é o verdadeiro gargalo — e é essa a ideia

A arquitetura honesta de um processo de dias-em-vez-de-meses é esta: a IA comprime o tempo de produção 5 a 10 vezes no trabalho repetitivo, e o gargalo muda de sítio. Deixa de ser escrever código. Passa a ser critério — um engenheiro sénior a ler cada linha gerada e a perguntar:

• Isto trata o caso de falha, ou só o caso feliz?
• É a solução simples, ou a solução vistosa?
• Quem mantiver isto daqui a dois anos vai perceber?
• Isto responde ao que o negócio do cliente precisa, ou ao que a instrução por acaso dizia?

Mais de dez anos de experiência em produção é o que torna essa revisão rápida e fiável. Um júnior a rever código de IA carimba-o; não consegue ver o que falta. Um sénior deteta o erro subtil em segundos, porque já lançou e corrigiu exatamente essa classe de erro antes.

É por isto que o processo funciona tanto em projetos pequenos como grandes. Um site institucional com formulário de contacto pode genuinamente demorar dias. Uma aplicação à medida com pagamentos, perfis e integrações demora mais — porque há mais decisões que exigem critério, não porque alguém escreve devagar. Um fornecedor que dê o mesmo prazo aos dois não está a rever nada.

O que isto significa para o seu orçamento

A economia decorre daqui. Quando a coordenação e o tempo de repetição desaparecem mas o rigor de engenharia fica, obtém qualidade sénior a prazos e preços que antes eram sinal de facilitismo — tanto em sites como em aplicações à medida, com os mesmos controlos que uma equipa de nível bancário exigiria. Para contexto, o mercado português em 2026 situa sites de PME entre €600 e €1.500 como valor percebido justo, e agências de Lisboa entre €3.000 e €6.000.

Nota prática: se é PME, o programa Vale Digitalização pode cofinanciar 75% do investimento em presença digital, até €20.000. As regras mudam — confirme as condições atuais em portugal2030.pt antes de decidir.

Rapidez e qualidade só estiveram em conflito quando a rapidez vinha de saltar passos. Salte antes a espera.

Se tem um projeto em que o prazo importa tanto como a qualidade, descreva-o em dois minutos e receba uma estimativa concreta — incluindo o que iríamos construir, testar e verificar antes de lhe apresentar uma data de lançamento.