Há uma pergunta que vale a pena fazer antes de contratar qualquer desenvolvimento web em 2026: isto precisa mesmo de ser construído, ou já consigo fazê-lo sozinho numa tarde?

A pergunta ficou mais relevante ontem. No DevDay de 29 de setembro de 2026, a OpenAI atualizou o ChatGPT Sites, a funcionalidade que permite descrever aquilo que se pretende e obter um website ou uma aplicação web leve a funcionar. Não uma imagem de como poderia ficar. Um site real, com URL, que se pode editar por conversa, publicar, ligar a um domínio próprio e, nas novas versões, manter atualizado automaticamente.

Isto não é uma ameaça a quem desenvolve software. É uma ferramenta nova que, usada no sítio certo, poupa dinheiro a quem a usa e tempo a quem constrói. O que vale a pena é saber exatamente onde está a fronteira.

O que o ChatGPT Sites já faz

Segundo a documentação da OpenAI, o Sites cria, pré-visualiza, publica e partilha websites interativos e aplicações leves. Dashboards, calendários, ferramentas de acompanhamento, portais internos, relatórios e protótipos estão dentro do âmbito. O processo é conversacional: descreve-se o que se quer, o sistema constrói uma primeira versão, e as alterações pedem-se em linguagem natural.

Está disponível nos planos Plus, Pro, Business e Enterprise, este último com ativação pelo administrador. Não está disponível nos planos Free e Go. Os domínios próprios são suportados quando a opção existe na conta, com uma condição importante: é necessário já ser dono do domínio e conseguir alterar os registos DNS.

As novidades de ontem são duas e ambas contam. A primeira é a possibilidade de acrescentar plugins suportados aos Sites, e de cada pessoa da equipa usar a mesma aplicação com os seus próprios dados e permissões. A segunda é que as Automations ficaram mais fáceis de acrescentar e gerir, para que um Site mantenha informação partilhada atualizada sozinho, incluindo através de eventos vindos de aplicações ligadas.

Traduzido: um Site deixou de ser necessariamente uma página estática que alguém atualiza à mão. Pode ser um objeto que se atualiza a si próprio. Isso aproxima-o muito mais de uma aplicação interna do que de um construtor de páginas.

Onde isto é genuinamente uma boa ideia

Vamos ser diretos, porque esta parte interessa a quem lê e não custa nada dizer.

Se precisa de um protótipo para testar uma ideia antes de gastar dinheiro a sério, use uma ferramenta destas. Se precisa de uma landing page para um evento, uma campanha ou uma apresentação que vive três semanas, use uma ferramenta destas. Se quer um pequeno painel interno para a equipa acompanhar projetos, ou transformar uma folha de cálculo numa coisa que se consulta sem pedir ficheiros a ninguém, use uma ferramenta destas.

Nenhuma empresa devia pagar milhares de euros para validar uma hipótese que se valida numa tarde. Na prática, isto reduz o custo de experimentar, e reduzir o custo de experimentar é uma das melhores coisas que pode acontecer a um negócio pequeno. Quem experimenta mais, acerta mais vezes.

Também vale a pena dizer o que isto pressiona. Empresas que cobram como projeto aquilo que é instalar um template, trocar o logótipo, mudar quatro cores e acrescentar um formulário vão ter cada vez menos argumentos. Essa pressão é saudável, e obriga quem desenvolve a demonstrar por que está realmente a cobrar: estratégia, conversão, integrações, arquitetura, medição, não horas de produção.

Onde a conversa muda

A parte que estas ferramentas resolvem é a produção de interface. Acontece que, num website empresarial, a interface é a menor parte do trabalho.

Pense numa loja online a funcionar. O cliente vê páginas de produto e um carrinho. Por trás existe catálogo, stock, faturação, pagamentos, transportadoras, gestão de encomendas, feeds para o Google, consentimento de cookies, emails transacionais, CRM, analytics e, quase sempre, um sistema de gestão que a empresa já usava antes de ter loja. Chamamos-lhe website. É um sistema.

O mesmo acontece num portal de reservas, numa área de cliente, numa plataforma de formação ou num site que gera orçamentos a partir de regras próprias. A pergunta deixa de ser "consegue construir esta página?" e passa a ser "esta coisa consegue viver dentro da operação da empresa?".

E há uma camada que nenhuma ferramenta decide por si: quem é o cliente, que informação ele precisa antes de comprar, qual é a ação que queremos que faça, como medimos essa ação, onde entram os contactos, como se liga isso à faturação. A inteligência artificial ajuda a implementar respostas com uma rapidez que não existia. Não escolhe as respostas certas para o seu negócio, porque não conhece o seu negócio.

Dois sites tecnicamente iguais, ambos rápidos, ambos bonitos no telemóvel, podem gerar trinta pedidos de contacto por mês e três. A diferença mora na ordem das páginas, na prova social, nas fotografias, no número de campos do formulário, na forma como o serviço é explicado. Essas decisões não vêm no prompt "faz-me um website moderno e profissional".

Os limites que a própria OpenAI documenta

Esta parte é útil porque não é opinião nossa, está escrita na documentação.

Algumas frameworks, redes privadas, bases de dados, serviços em background e modelos de alojamento podem não ser suportados. O Sites não suporta residência de dados nem residência de inferência no lançamento, o que é relevante para quem tem requisitos de localização de dados. Os Sites não devem processar dados de saúde protegidos nem dados de cartões de pagamento, exceto através de processadores externos. E quando existe comércio, a OpenAI é explícita: a responsabilidade pelas transações, encomendas, impostos, reembolsos e apoio ao cliente continua a ser do proprietário do site.

Nada disto torna a ferramenta má. Torna-a uma ferramenta, com um âmbito. A conclusão prática é banal e importante: não existe uma ferramenta adequada a todos os problemas.

De quem é o site

Há um ponto que vai ganhar peso nos próximos anos e que quase ninguém pergunta na altura certa.

Quando se constrói sobre uma plataforma fechada, herdam-se as regras dessa plataforma. Hoje existe uma funcionalidade, amanhã muda. Hoje o preço é um, amanhã é outro. Hoje uma integração funciona, amanhã deixa de constar da lista de suportadas. Para um protótipo, isso é irrelevante. Para o sistema que sustenta a operação, é uma decisão estratégica.

É por isso que, nos projetos que fazemos, o domínio, o código e os conteúdos pertencem ao cliente. Não porque esperamos que vá embora, mas exatamente pelo contrário: preferimos que fique porque o serviço compensa, não porque tecnicamente não consegue sair.

Ser encontrado é um problema separado

Há uma ideia perigosa a circular: se foi a IA que criou o site, então já deve estar otimizado para a IA.

Não funciona assim. Construir uma página e construir uma presença que é encontrada são dois trabalhos diferentes. O segundo envolve arquitetura de informação, conteúdo que responde a pesquisas reais, dados estruturados, ligações internas, indexação, performance, autoridade e, cada vez mais, a forma como os sistemas de IA compreendem quem é a empresa e o que faz. Já escrevemos sobre esse último ponto em como aparecer quando alguém pergunta a uma IA quem faz isto em Braga.

Um site que ninguém encontra continua a ser um site. Só não é um canal de aquisição.

Seis perguntas que resolvem a decisão

Antes de escolher o caminho, passe o projeto por estas perguntas. Processa pagamentos ou dados sensíveis? Precisa de contas de utilizador com permissões diferentes? Tem de falar com o software que a empresa já usa, como faturação, CRM ou ERP? Depende de SEO para trazer clientes? Tem lógica de negócio própria, do tipo que ninguém de fora adivinha? E o que acontece ao negócio se isto estiver indisponível durante um dia?

Se respondeu não a quase tudo, provavelmente consegue fazer sozinho, e faz bem. Se respondeu sim a duas ou três, está a falar de software, não de um site, e vale a pena tratá-lo como software. É a mesma lógica que aplicamos a automações com IA, que descrevemos em chatbot, copiloto ou agente: a tecnologia certa depende do custo de correr mal.

O futuro de quem desenvolve software passa provavelmente por escrever menos código e decidir melhor. Se uma ferramenta produz em dez minutos aquilo que levava três horas, não há mérito nenhum em cobrar as três horas. O valor desloca-se para perceber o problema, desenhar a arquitetura, integrar sistemas, medir resultados e, com alguma frequência, dizer ao cliente que determinado desenvolvimento não é necessário.

Como a Digito ajuda

O trabalho útil começa antes de existir código. Ouvimos o que o negócio precisa de fazer, dizemos com franqueza o que se resolve com uma ferramenta destas, e desenhamos e construímos o resto.

Na prática são três caminhos. Websites profissionais pensados para trazer clientes, com conteúdo, estrutura e medição, e não apenas com páginas. Aplicações web e mobile quando o que a empresa precisa tem contas, permissões, regras próprias e dados que não podem viver numa plataforma fechada. E software e integrações para ligar tudo isso ao que já existe na empresa, da faturação ao CRM, para que a informação não fique presa numa página.

Se está nesta decisão agora, e quer uma opinião honesta sobre o que compensa construir e o que não compensa, fale connosco em digitosolutions.com.

Fontes