A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
A maioria das empresas chega num projeto de site ou plataforma digital com a tecnologia já decidida. O desenvolvedor conhece WordPress, então vai de WordPress. A equipe técnica trabalha com React, então vai de React. Ninguém perguntou o que a plataforma precisa fazer. Só escolheram o que já sabiam usar.
Esse é o erro mais caro da área. E é mais comum do que parece.
A escolha errada não quebra o projeto no primeiro dia. Ela aparece seis meses depois, quando o time de marketing descobre que publicar um artigo depende de um desenvolvedor. Ou quando o site, que deveria carregar rápido, demora dois segundos num celular com sinal ruim. Ou quando a empresa recebe um alerta: o servidor foi invadido via uma vulnerabilidade do plugin de formulário que ninguém atualizava há oito meses.
A pergunta certa não é “qual tecnologia usar”. É: o que esse projeto precisa fazer?
Nos últimos dois anos surgiram plataformas que geram aplicações web inteiras a partir de uma descrição em linguagem natural. Lovable, Bolt, v0 da Vercel, Replit Agent. Você descreve o que quer, a IA produz o código, o site está no ar em horas.
Essas ferramentas existem para um contexto específico e funcionam bem dentro dele: validar uma ideia rapidamente, montar um protótipo para mostrar a um investidor, ou criar algo funcional sem orçamento para desenvolvimento. Para um empreendedor individual testando uma hipótese, faz sentido.
O problema não é a ferramenta. É quando ela é usada fora desse contexto.
Uma empresa que vai operar aquela plataforma por cinco anos, com equipe de conteúdo publicando diariamente, integrações com sistemas internos e exigência real de performance e segurança, está usando martelo para apertar parafuso. O código gerado por IA é genérico por definição. Não foi pensado para o fluxo editorial daquela empresa, não tem governança de segurança, e acumula dívida técnica rápido. Quando o projeto cresce além do que a ferramenta aguenta, a migração custa mais do que teria custado começar certo.
Isso não é argumento contra essas ferramentas. É argumento para fazer a pergunta certa antes de escolher qualquer uma.
Sites corporativos, portais de imprensa, blogs, intranets editoriais e páginas de produto têm uma característica em comum: o conteúdo muda, mas a lógica do sistema não. A equipe de comunicação precisa publicar, editar e organizar textos e imagens. Não há transações, autenticações complexas ou regras de negócio rodando no navegador do usuário.
Para esse tipo de projeto, a tecnologia mais adequada hoje é o Astro, combinado com um CMS desenvolvido sob medida.
O Astro foi construído com uma premissa simples: não carregue JavaScript no navegador se não for necessário. A maioria dos frameworks modernos, inclusive o Next.js, envia o código da interface junto com cada página, mesmo quando essa interface é estática. O Astro usa o que chama de Islands Architecture: a página é HTML puro, e só os pontos que precisam de interatividade carregam JavaScript.
Os benchmarks que comparam Astro com Next.js em sites de conteúdo equivalente mostram diferenças significativas: aproximadamente 40% mais rápido no carregamento e até 90% menos JavaScript enviado ao navegador, segundo dados publicados pela própria equipe da Astro e corroborados por testes independentes da comunidade de desenvolvedores. Em mobile com conexão instável, essa diferença é percebida pelo usuário.
Velocidade não é só experiência. O Google usa Core Web Vitals como sinal de ranqueamento. Um site lento perde posição nos resultados de busca independente da qualidade do conteúdo.
A maturidade do Astro como escolha corporativa ficou ainda mais clara em janeiro de 2026, quando a Cloudflare anunciou a aquisição da Astro Technology Company, o time por trás do framework. No anúncio, a Cloudflare confirmou que IKEA, Porsche, OpenAI, Unilever, Visa e NBC News usam Astro em suas operações digitais. O Google usa Astro no blog do Firebase. The Guardian usa para seu site de engenharia. NordVPN, Trivago e Microsoft (no design system Fluent 2) também são usuários confirmados.
Escolher um CMS de mercado, como Contentful, Sanity ou Storyblok, resolve o problema imediato: a equipe de conteúdo tem onde publicar. Mas cria dependências que poucas empresas calculam na hora de contratar.
Primeiro, custo. Plataformas como Contentful cobram por usuário, por volume de chamadas de API e por ambiente de teste. À medida que o time cresce ou o volume de publicações aumenta, o custo escala. Empresas que começam com um plano razoável podem ver o custo dobrar em dois anos sem mudança de operação.
Segundo, flexibilidade. O CMS de mercado tem sua própria lógica de funcionamento. Fluxos editoriais, campos de conteúdo, permissões e aprovações seguem o modelo da plataforma. Quando o processo da empresa não se encaixa nesse modelo, o time adapta o processo, não o sistema.
Terceiro, dependência de fornecedor. Se a plataforma mudar sua política de preço, descontinuar uma funcionalidade ou encerrar o suporte a determinada integração, o cliente arca com o problema.
Um CMS proprietário desenvolvido junto com o projeto resolve cada um desses pontos. A interface é desenhada para o fluxo real da equipe de conteúdo da empresa, não para um fluxo genérico. Os campos, as categorias, os papéis de acesso e os fluxos de aprovação existem porque fazem sentido para aquela operação específica. O custo não escala com o número de usuários ou de publicações. E não há fornecedor para ficar dependente.
É mais trabalho no início. É o que evita retrabalho dois anos depois.
WordPress alimenta mais de 40% dos sites do mundo. Esse número diz menos sobre qualidade e mais sobre inércia: é barato para começar, tem temas prontos, e qualquer desenvolvedor júnior sabe mexer.
O problema aparece em escala e em segurança.
WordPress é o CMS mais atacado do mundo. A superfície de ataque é grande porque o ecossistema de plugins é aberto e mal controlado. Vulnerabilidades em plugins populares, incluindo os de formulário, SEO e e-commerce, são exploradas em massa. Segundo o relatório State of WordPress Security 2025 da Patchstack, publicado em março de 2025, foram registradas 7.966 novas vulnerabilidades no ecossistema WordPress em 2024, um aumento de 34% em relação a 2023. Dessas, 96% estavam em plugins, 4% em temas, e apenas 7 no Core. 43% podiam ser exploradas sem autenticação.
O problema não é o WordPress em si. É a combinação de plugins de terceiros, versões desatualizadas e ausência de processo ativo de manutenção. Para empresas que usam o site como canal de negócio, e não como brochura digital, esse risco não é aceitável.
Drupal tem postura diferente em relação à segurança: o núcleo da plataforma é rigoroso, com time dedicado e ciclo confiável de patches. Mas o custo de desenvolvimento e manutenção é alto, a curva de aprendizado para o time de conteúdo é íngreme, e a plataforma carrega uma arquitetura que não foi desenhada para performance moderna.
A decisão de migrar do WordPress ou do Drupal não precisa ser emergencial. Mas precisa estar no radar de qualquer empresa que leva a sério o canal digital.
Sites corporativos e portais de conteúdo têm lógica simples. Plataformas de produto têm lógica de negócio: autenticação, perfis de usuário, fluxos de compra, dashboards, integrações com ERP, CRM, sistemas de cobrança.
Para esse tipo de projeto, a escolha mais sólida hoje é React no frontend e .NET Core no backend.
React é o framework de interface mais adotado em aplicações de produto no mundo. Está na base de plataformas como Notion, Airbnb e Linear. O ecossistema é maduro, o mercado de desenvolvedores é amplo, e a arquitetura baseada em componentes funciona bem para interfaces com muitos estados e interações.
.NET Core complementa essa estrutura no lado do servidor. É a plataforma de backend mais adotada em ambientes corporativos brasileiros, especialmente em empresas médias e grandes com infraestrutura Microsoft. Tem performance comprovada em cargas altas, suporte de longo prazo da Microsoft, e modelo de segurança robusto para APIs expostas a usuários externos. Para plataformas B2B que precisam se integrar com sistemas legados, ERP ou serviços internos, .NET Core reduz a fricção técnica.
A combinação React e .NET Core não é a mais empolgante para apresentar numa conversa de tecnologia. É a que funciona em produção, durante anos, com times que mudam e requisitos que evoluem.
Nem todo projeto é claramente site de conteúdo ou plataforma de produto. Há casos intermediários: um portal de vendas com catálogo estático mas área logada para representantes. Uma intranet com gestão de conteúdo editorial e ferramentas de colaboração. Um e-commerce simples que pode crescer para algo mais complexo.
Para esses casos, Next.js costuma ser a escolha mais equilibrada. É um framework React com suporte nativo a renderização no servidor, rotas de API, geração estática e dinâmica na mesma aplicação. Oferece mais flexibilidade que o Astro para projetos com interatividade moderada, e menos overhead que uma arquitetura completa de produto para sistemas que não precisam de toda essa complexidade.
A decisão correta depende de entender para onde o projeto vai, não só onde ele está hoje.
A VM2 desenvolve plataformas digitais para empresas de médio e grande porte desde 1998. Nesses projetos, a escolha de tecnologia é consequência, não ponto de partida.
O processo começa entendendo o que a plataforma precisa fazer, quem vai operar, como o conteúdo é produzido e qual é a expectativa de evolução nos próximos dois a três anos. Só depois disso faz sentido falar de Astro, React, .NET, CMS proprietário ou qualquer outra tecnologia.
Isso parece óbvio. E ainda assim é raro.
Para empresas que já têm um site e estão avaliando se a tecnologia atual ainda faz sentido, ou para equipes iniciando um novo projeto digital, esse diagnóstico inicial é o que diferencia uma decisão informada de uma aposta no que o time sabe fazer.
Fontes consultadas: State of WordPress Security 2025, Patchstack (mar/2025); Web Almanac 2024, HTTP Archive (dez/2025); anúncio de aquisição da Astro Technology Company pela Cloudflare (jan/2026); showcase oficial astro.build/showcase; State of JS 2025.
Acessibilidade não é só obrigação legal. É a diferença entre uma plataforma que funciona para todos e uma que exclui parte do mercado silenciosamente.
36% das empresas gastam mais tempo resolvendo problemas de APIs do que desenvolvendo funcionalidades. O problema quase nunca é a API. É a documentação tratada como anexo, não como produto.
No B2B, o copy não vende para uma pessoa. Vende para um comitê. Entender quem lê cada parte da plataforma muda o que precisa ser escrito em cada ponto.
