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. O Skip, o Lovable, o Bolt. 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 todo sentido.
O problema não é a ferramenta. É quando ela é usada fora desse contexto.
Uma empresa que vai operar aquela plataforma por cinco anos, com uma equipe de conteúdo publicando diariamente, integrações com sistemas internos e exigência real de performance e segurança, está usando um 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 só carrega JavaScript nos elementos que precisam de interatividade. O resultado prático é significativo: em comparação com sites equivalentes construídos em Next.js, sites em Astro entregam páginas até 40% mais rápido e com 90% menos JavaScript enviado ao navegador. 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 critério de ranqueamento. Um site lento perde posição nos resultados de busca independente da qualidade do conteúdo. Segundo levantamento publicado em 2025, 60% dos sites Astro passam nos critérios de Core Web Vitals, contra 38% dos sites construídos em WordPress ou Gatsby.
Marcas como IKEA, NordVPN e Porsche já usam Astro em partes de suas operações digitais. A Cloudflare usa Astro para sua documentação técnica. O Google Firebase e o Trivago usam para seus blogs. São projetos com foco em conteúdo e exigência alta de performance.
Escolher um CMS de mercado — Sanity, Contentful, Storyblok, entre outros — 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 testes. À 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 triplicar o custo em dois anos sem mudar nada na 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 pela vm2 junto com o projeto do site — 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. E é 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, de SEO e de e-commerce — são exploradas em massa. Em 2024, pesquisadores de segurança identificaram mais de 7.000 vulnerabilidades ativas em plugins do WordPress. A maioria dos sites afetados tinha plugins que não eram atualizados há mais de seis meses.
O problema não é o WordPress em si. É a combinação de plugins de terceiros, versões desatualizadas e ausência de um processo de manutenção ativo. 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 uma postura diferente em relação à segurança: o núcleo da plataforma é rigoroso, com um time dedicado de segurança e um 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 pesada 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 é React no frontend e .NET Core no backend.
React é o framework de interface mais usado 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 um 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 + .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 um site de conteúdo ou uma 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 há 27 anos. Nesses projetos, a escolha de tecnologia é uma consequência — não um 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.
Referências: dados de performance Astro vs. Next.js, Smashing Magazine / BetterLink Blog (2025); Core Web Vitals comparison, BetterLink Blog (2025); headless CMS market size, Market Research Future (2025); WordPress vulnerability data, Wordfence Security Report (2024); empresas que usam Astro, Medium / Better Dev (2025).
UX não é sobre satisfação do usuário. É sobre decisão. E decisão é sobre negócio — especialmente no B2B, onde múltiplos perfis avaliam a mesma plataforma.
Responsivo e mobile first não são a mesma coisa. A diferença é de processo — e ela muda o que é construído, desde o wireframe até o deploy.
A maioria dos problemas que aparecem no final de um projeto foi plantada no início. Como a vm2 estrutura um projeto de plataforma digital — do diagnóstico ao monitoramento pós-lançamento.
