Escalar além do CMS do Webflow: uma arquitetura híbrida

O CMS do Webflow tem um limite de 10.000 itens. Para a maioria dos sites, é mais que suficiente. Mas quando um cliente perguntou se conseguia trazer a plataforma de dados financeiros para o Webflow, tinha 10.000+ registos de empresas, dados relacionais complexos e precisava de filtragem avançada. O CMS nunca ia funcionar.

Foi assim que construí um produto de dados baseado em base de dados que vive dentro de um site Webflow, usando Webflow Cloud, Astro e Neon Postgres.

O que vai aprender:

• Como o Webflow Cloud permite correr uma app full-stack como subpasta de um site Webflow existente
• Quando ignorar o CMS do Webflow e usar uma base de dados real
• Como construir páginas de SEO programático a partir de queries à base de dados
• Porque tentei o DevLink e o abandonei

O problema

A Dialectica é uma empresa de serviços de informação. O seu produto, Origin, é uma plataforma de deal intelligence usada por profissionais de PE, VC e estratégia corporativa. Queriam uma versão pública: uma fatia gratuita e pesquisável da sua base de dados de empresas, acessível em dialectica.io/origin.

Os requisitos:

• 10.000+ registos de empresas (começando com ~930, a crescer)
• Dados complexos: empresas, indústrias, financeiros, investidores, concorrentes, membros de equipa
• Filtragem avançada: indústria, localização, tipo de propriedade, intervalo de receita, crescimento YoY
• Masking de dados: mostrar o suficiente para atrair, esconder o suficiente para converter
• SEO programático: cada empresa e indústria precisa da sua própria página indexável
• Tem de viver como subpasta do site de marketing Webflow existente

O CMS do Webflow limita a 10.000 itens. Mesmo nesse limite, não se consegue fazer queries relacionais, filtros de intervalo ou masking dinâmico. Isto precisava de desenvolvimento web personalizado, não de configuração de CMS.

Porquê Webflow Cloud

O Webflow Cloud saiu de beta exatamente na altura certa. Faz algo que nenhuma outra funcionalidade do Webflow faz: permite fazer deploy de uma aplicação full-stack, construída com qualquer framework, como subpasta de um site Webflow existente.

Por baixo, corre em Cloudflare Workers. Liga-se um repositório GitHub, faz-se push de código e o Webflow Cloud faz deploy para o edge. O resultado: dialectica.io é um site Webflow. dialectica.io/origin é uma app Astro. Mesmo domínio, mesma navegação, stack completamente diferente por baixo.

Para a Dialectica, isto era crítico. Não queriam um subdomínio separado. Não queriam reconstruir o site de marketing. Queriam que o Origin parecesse parte do mesmo site. O Webflow Cloud tornou isso possível sem hacks de proxy ou truques de DNS.

O stack

Astro para o frontend. Server-side rendering em Cloudflare Workers, com React islands para componentes interativos. Escolhi Astro porque não envia JavaScript por defeito e só hidrata o que precisa de interatividade. Para um site pesado em dados com centenas de páginas, isso importa.

Neon para a base de dados. Postgres serverless com driver HTTP que funciona nativamente em Cloudflare Workers. Sem workarounds de WebSocket, sem dores de cabeça com connection pooling. Começámos com Supabase mas mudámos para Neon porque os backups de base de dados antes de migrações de dados eram mais simples.

Python para migração de dados. A Dialectica não expõe uma API. Exportam ficheiros JSON com dados de empresas, e eu corro um script Python que limpa, estrutura e importa tudo para o Neon. Processo em duas passagens: dados core da empresa primeiro, depois relações (indústrias, investidores, financeiros, concorrentes).

React para componentes interativos. O sistema de filtros usa primitivas Radix UI: filtros combobox para indústria, localização e tipo de propriedade, mais range sliders de dupla pega para receita e crescimento YoY. Estes disparam custom events que o router de View Transitions do Astro apanha para navegar com novos parâmetros de URL. A filtragem parece instantânea, mas cada query vai à base de dados no edge.

A experiência DevLink

Tentei usar o Webflow DevLink para sincronizar componentes do site existente da Dialectica para o Astro. A ideia era reutilizar o header, footer e componentes de cards diretamente.

Não funcionou. O problema principal era a navegação. O header tem JavaScript personalizado para transições de submenus que o developer original construiu. O DevLink sincroniza o componente visual mas não o código personalizado associado. O mesmo problema com vários outros componentes: dependiam de código personalizado do Webflow que não viaja com as exportações DevLink.

Poderia ter reconstruído o código personalizado para funcionar com os componentes DevLink, mas nesse ponto estaria a recriar a maior parte da lógica de qualquer forma. Optei por componentes Astro estilizados com Tailwind CSS. Mais rápido de construir, mais fácil de manter, e tinha controlo total sobre markup e comportamento.

A minha conclusão: o DevLink faz sentido quando os componentes Webflow são autónomos. Sem código personalizado, sem interações complexas. Para tudo o resto, construir componentes nativos do framework dá menos trabalho a longo prazo.

Data masking para freemium

Esta foi ideia da Dialectica e um dos desafios técnicos mais interessantes. Queriam mostrar dados suficientes para demonstrar valor, mas mascarar os detalhes para que os utilizadores precisassem de se registar para o produto completo.

Construí duas camadas:

Masking no servidor corre antes de quaisquer dados chegarem ao browser. Valores de receita como $565M tornam-se $5••M. Nomes de investidores são substituídos por caracteres. Datas ficam obscurecidas. O masking preserva o formato para que a página continue a parecer dados reais, mas os valores concretos estão escondidos. Scrapers e LLMs a ler o HTML só veem conteúdo mascarado.

Blur CSS adiciona uma camada visual por cima. O masking no servidor é a proteção real; o blur é o sinal visual que diz “estes dados estão bloqueados.”

Um formulário de captação de leads é acionado com base no engagement: scroll para além de 50-75% da página ou 45-60 segundos a ler. Os thresholds são aleatórios por sessão, com um cooldown de 24 horas via localStorage para que visitantes recorrentes não sejam bombardeados.

SEO programático à escala

Esta foi a parte que tornou o MVP valioso do ponto de vista de negócio. Cada registo de empresa gera a sua própria página com meta tags adequadas, dados estruturados JSON-LD e URLs canónicos. Cada indústria tem uma landing page. Depois gero páginas de combinação: indústria + localização (ex., /industry/enterprise-software/location/usa) e indústria + tipo de propriedade.

Cada página programática inclui a UI completa de filtros, para que os utilizadores possam continuar a explorar a partir de qualquer ponto de entrada. Um sitemap XML dinâmico lista cada URL. O resultado são centenas de páginas indexáveis, todas geradas a partir de queries à base de dados.

O Google indexou as páginas e alguns URLs do Origin já estão na primeira página. Para uma plataforma que não existia há seis meses, é a estratégia de SEO a funcionar como planeado.

A IA tornou isto possível

Vou ser direto: nunca tinha construído um site Astro antes deste projeto. Nunca tinha usado Webflow Cloud. Nunca tinha configurado uma base de dados Postgres serverless. E construí tudo sozinho, em part-time, em paralelo com o retainer de manutenção regular com o mesmo cliente.

A primeira versão foi lançada em menos de dois meses. Esse prazo só aconteceu porque usei Claude Code ao longo de todo o build. Ajudou-me a escrever lógica TypeScript para queries de base de dados compatíveis com edge, scripts Python para migração de dados, componentes React com Radix UI, e a depurar as peculiaridades de correr Postgres num ambiente Cloudflare Workers.

A IA não desenhou a arquitetura nem tomou as decisões de produto. Mas permitiu-me executar a uma velocidade e através de uma amplitude de tecnologias que teria sido impossível de outra forma. Para um developer solo que oferece serviços de desenvolvimento MVP, isso muda o que se pode prometer a um cliente.

O que faria diferente

Abandonar o DevLink mais cedo. Passei tempo a tentar que funcionasse quando os sinais eram claros. Se um site Webflow usa JavaScript personalizado significativo nos seus componentes, planear componentes nativos do framework desde o início.

Começar com Neon. A migração de Supabase para Neon não foi dolorosa, mas foi um passo desnecessário. O driver serverless do Neon e o workflow de backup são mais adequados para projetos Cloudflare Workers.

Construir uma interface de administração mais cedo. Neste momento, adicionar empresas significa correr um script Python. Funciona, mas um painel de administração simples tornaria as atualizações de dados mais fluidas. É o próximo passo no roadmap.

Principais conclusões

• O Webflow Cloud é arquitetura híbrida a sério. Manter o site de marketing em Webflow, correr uma app full-stack no mesmo domínio. Sem subdomínios, sem hacks de proxy.
• Ignorar o CMS quando os dados são complexos. O CMS do Webflow funciona para blogs e portfolios. Para dados relacionais com filtragem, ordenação e páginas dinâmicas, usar uma base de dados.
• O DevLink tem limites. Se os componentes Webflow dependem de código personalizado, vão ter de ser reconstruídos no framework. Orçamentar para isso.
• SEO programático precisa de uma base de dados. Não se consegue gerar centenas de páginas otimizadas a partir do CMS do Webflow. Server-side rendering a partir de uma base de dados real torna isso simples.
• A IA alarga o que um developer solo consegue entregar. Este projeto abrangeu Astro, React, Python, PostgreSQL e Cloudflare Workers. Ferramentas de IA tornaram possível trabalhar com todas sem ser especialista em cada uma.

Leia o caso de estudo completo da Dialectica para a visão geral do projeto e resultados de negócio.