Construtor de sites ou desenvolvimento sob medida: como decidir sem torcida

Existe uma discussão improdutiva entre quem vende desenvolvimento e quem vende plataforma pronta. Um lado diz que ferramenta pronta não ranqueia. O outro diz que código próprio é desperdício. As duas afirmações estão erradas, e quem paga o preço por elas é o dono do negócio.

Um construtor de sites resolve muito bem uma classe específica de problema, e trava de forma previsível em outra. Saber de qual lado da linha o seu projeto está é uma decisão de dez minutos, desde que você olhe para as variáveis certas em vez de para argumentos de venda.

Este texto separa os dois casos. Onde o construtor de sites é a escolha correta, onde ele cobra caro em silêncio, e quais sinais indicam que chegou a hora de trocar.

O que um construtor de sites realmente entrega

Wix, Squarespace e WordPress com editor visual resolvem, em horas, coisas que levariam dias em um projeto do zero: hospedagem configurada, certificado HTTPS, responsividade, formulários, backup, painel de edição que qualquer pessoa aprende a usar.

Isso não é pouco. Para um negócio que precisa de presença digital, catálogo simples e um formulário de contato, é exatamente a ferramenta adequada. Gastar em desenvolvimento próprio nesse cenário é comprar capacidade que não será usada.

Os fundamentos de SEO também estão lá. Editar título, descrição, URL, gerar sitemap, marcar noindex em páginas internas — as plataformas maduras fazem tudo isso. Quem diz que site em construtor de sites "não aparece no Google" está descrevendo um site sem conteúdo, não uma limitação da ferramenta.

Quando o construtor de sites é claramente a escolha certa

Quatro condições, quando todas verdadeiras, tornam a decisão fácil: menos de vinte páginas, nenhuma integração com sistema interno, conteúdo que muda pouco e ninguém no time com perfil técnico. Nesse cenário, um projeto sob medida entrega mais capacidade do que o negócio consegue aproveitar.

Vale acrescentar uma quinta: prazo. Uma ferramenta pronta coloca um site decente no ar em dias. Se existe uma data comercial inegociável, essa velocidade tem valor real e pode justificar a escolha mesmo em casos limítrofes.

Onde o construtor de sites começa a cobrar caro

Os limites não aparecem no primeiro mês. Aparecem no segundo ano, e quase sempre em quatro frentes.

Peso da página. Editores visuais geram HTML genérico o suficiente para funcionar em qualquer combinação de blocos. Essa generalidade tem custo: mais marcação, mais CSS e mais JavaScript do que a página precisa. Você pode compensar parte disso com imagens leves e menos animação, mas não pode reescrever o que a ferramenta gera.

Scripts de terceiros acumulados. Cada app instalado adiciona código no carregamento. Em WordPress, é comum um site chegar a vinte plugins ativos sem que ninguém tenha decidido isso conscientemente.

Estruturas de conteúdo. Quando o site precisa de tipos de conteúdo relacionados entre si — produtos ligados a aplicações, ligados a segmentos, ligados a materiais técnicos — a modelagem em ferramenta visual vira gambiarra. É possível, mas cada nova relação custa mais do que a anterior.

Integrações. Conectar com ERP, CRM ou sistema de estoque próprio geralmente exige um conector pago, um serviço intermediário ou código customizado dentro da plataforma. Os três reintroduzem a complexidade que a ferramenta prometia eliminar.

Custo total de propriedade: a conta que quase ninguém faz

A comparação honesta não é mensalidade contra valor de projeto. É custo total em vinte e quatro meses, e é nessa conta que o construtor de sites deixa de parecer tão barato quanto a assinatura sugere.

Do lado da plataforma, some: mensalidade do plano, tema premium, plugins e apps pagos, eventual serviço de integração, horas de agência para ajustes que o painel não faz, e horas da sua equipe contornando limitações. Esse último item é o mais caro e o único que nunca aparece em planilha.

Do lado do desenvolvimento próprio, some: o projeto inicial, hospedagem, manutenção e evolução. O valor de entrada é maior e o custo mensal é menor, com uma curva que cruza a da plataforma em algum ponto entre o primeiro e o terceiro ano, dependendo de quanto o site é exigido.

Não existe resposta universal para onde as curvas se cruzam. Existe a sua conta, com os seus números. Se você ainda está montando o orçamento, os fatores que mais mexem no preço de um projeto ajudam a preencher o lado direito da comparação.

E se eu já estiver preso a uma plataforma?

Não há necessidade de decidir agora. Duas medidas baratas mantêm as portas abertas: manter URLs limpas e estáveis desde já, e garantir que o conteúdo possa ser exportado em formato legível. Com essas duas coisas, trocar de plataforma no futuro vira um projeto de migração comum, e não um resgate.

Performance: onde está o teto de cada caminho

Aqui a diferença é estrutural, e vale explicar sem exagero.

Em um construtor de sites, você controla imagens, quantidade de blocos, fontes e apps instalados. Não controla a estratégia de renderização, o tamanho do runtime nem a ordem de carregamento dos recursos. Isso define um teto: dá para chegar a um site rápido, não dá para chegar a qualquer número que você queira.

Em desenvolvimento próprio, o teto é a competência do time. Você decide o que é renderizado no servidor, quanto JavaScript vai para o navegador e como cada recurso é priorizado. Segundo a documentação do Google, LCP abaixo de 2,5 segundos, INP abaixo de 200 milissegundos e CLS abaixo de 0,1 são os patamares considerados bons — e no código próprio esses números viram requisito testável, não torcida.

A pergunta prática é se o seu negócio precisa desse controle. Um escritório local que recebe cem visitas por dia dificilmente precisa. Um e-commerce ou um site que depende de busca orgânica em setor competitivo, sim — nesses casos, a camada técnica que decide se o site é bem rastreado depende de acesso que a plataforma não oferece.

Os cinco sinais de que chegou a hora de trocar

• Você paga mais de três apps ou plugins para funções que deveriam ser nativas.
• Alguém do time gasta horas por semana contornando limitações do editor.
• O site precisa conversar com um sistema interno e a ferramenta não tem conector.
• As Core Web Vitals continuam ruins depois de otimizar imagens e remover apps.
• O volume de conteúdo passou de cem páginas e a organização virou problema.

Um sinal isolado não justifica troca. Três ou mais indicam que a economia da mensalidade já foi consumida pelo esforço de contornar a ferramenta.

E o inverso: quando voltar para uma ferramenta pronta?

Acontece, e não é derrota. Empresas que construíram um sistema próprio e depois reduziram a operação às vezes carregam um projeto que ninguém mantém. Se o site virou cinco páginas estáticas e não há time técnico, migrar para um construtor de sites bem configurado reduz risco e custo mensal.

WordPress é o meio-termo?

Em parte, e vale entender por quê. WordPress com editor visual se comporta como plataforma pronta, com os mesmos limites de peso e generalidade. WordPress usado como CMS, com tema desenvolvido sob medida ou servindo conteúdo via API para um front-end próprio, se comporta como projeto customizado.

A diferença não está no nome da ferramenta, e sim em quanto código do seu projeto foi escrito para o seu caso. É por isso que "usamos WordPress" não responde a nada sozinho: pode significar qualquer coisa entre os dois extremos.

Como decidir em dez minutos

Responda quatro perguntas. Quantas páginas o site terá em dois anos? Ele precisa conversar com algum sistema interno? A busca orgânica é canal principal de aquisição ou complementar? Existe alguém no time capaz de operar um projeto próprio?

Se as respostas forem poucas páginas, nenhuma integração, canal complementar e ninguém técnico, use uma plataforma pronta sem culpa e invista o dinheiro economizado em conteúdo. Se forem muitas páginas, integração necessária, busca orgânica como canal principal e time técnico disponível, o desenvolvimento sob medida se paga.

Nos casos intermediários — a maioria — a decisão costuma cair para o lado da plataforma no primeiro momento e migrar depois, o que é legítimo desde que as URLs estejam preservadas. Vale ler antes como um projeto nasce já preparado para ranquear, porque boa parte dessas decisões independe da ferramenta escolhida.

Se você estiver nesse ponto e quiser uma leitura externa do seu caso, a página de desenvolvimento de sites com SEO mostra como estruturamos projetos próprios e quando recomendamos ficar onde está.