ESTUDO DE CASO / ENGENHARIA DE PLATAFORMA + CRESCIMENTO
Uma plataforma de conteúdo para cliente, com o motor orgânico por cima
Uma empresa brasileira de contabilidade digital, online desde 2018, precisava de uma plataforma em que seus editores conseguissem publicar e de um motivo para os buscadores a encontrarem. Construí a plataforma e conduzi SEO, estratégia de conteúdo e produção de conteúdo por cima dela, sozinho.
Product engineer solo, responsável por SEO e conteúdo (cliente)
Período
2025 a janeiro de 2026
Contexto e escopo
Uma empresa brasileira de contabilidade digital, online desde 2018, tinha quase nenhum tráfego orgânico não-marca. O site não sustentava os formatos de conteúdo que uma categoria competitiva exige, e o editor não conseguia publicar uma página rica sem trabalho de engenharia.
O trabalho cobriu as duas metades do problema em um só lugar. Construí a plataforma em PayloadCMS e Next.js 15 com um page builder próprio, e depois conduzi a consultoria de SEO, a estratégia de conteúdo e a produção de conteúdo por cima dela. Sozinho, como solopreneur, com um estagiário ou freelancer ajudando no conteúdo.
Este é o registro que mostra a combinação de forma direta: a plataforma é a razão de o conteúdo poder ser produzido em volume, e o conteúdo é a razão de a plataforma ter movido os números.
O problema
O tráfego orgânico não-marca estava na casa das dezenas de visitas por mês, e quase todo o tráfego existente era de marca.
Os editores não conseguiam compor os formatos de página que a categoria exigia sem um desenvolvedor a cada vez.
O modelo de conteúdo e a estrutura de SEO não eram a mesma coisa, então cada tipo de página era uma decisão nova.
Um conjunto de palavras-chave acima de quarenta mil termos era bagunça, não plano.
A produção de conteúdo era um gargalo, não só a publicação.
As necessidades de múltiplos idiomas (pt, en, es) estavam chegando, e o site não foi construído para elas.
Mapa do sistema
SuperfícieMódulos compostos
Hotéis
Busca
Resultado
Detalhe do hotel
Reserva
Pacotes
Montagem
Preço
Detalhe do pacote
Checkout
Transfers
Trajeto
Opções
Agendamento
Confirmação
Passeios e ingressos
Catálogo
Disponibilidade
Compra
Confirmação
VISÃO CONCEITUAL / ESCOPO PÚBLICO
Restrições
Um trabalho solo, então plataforma, SEO e conteúdo precisavam dividir a mesma agenda e o mesmo responsável.
Uma data de go-live em janeiro de 2026, com conteúdo real já no plano.
O stack do cliente vivia na AWS, então a plataforma precisava se encaixar nele em vez de substituí-lo.
Performance no lançamento importava, porque a categoria é competitiva em experiência de página.
Os detalhes do cliente permanecem privados, então o registro é escrito a partir do escopo do trabalho e dos resultados medidos.
O que construí
Uma plataforma de conteúdo em PayloadCMS 3, Next.js 15 e React 19, com 18 collections e cerca de 25 blocos modulares em um page builder próprio.
Uma biblioteca de componentes grande e cheia de variações, para que um bloco renderizasse muitos layouts sem código novo.
Uma camada de resiliência de blocos, para que um bloco quebrado ou vazio degradasse de forma limpa em vez de derrubar a página.
Controle de acesso por papel, preview ao vivo e localização em pt, en e es.
Trabalho de cloud e mídia em AWS S3 e CloudFront, com Mux para vídeo, e uma migração posterior para Amplify.
SEO tratado como problema de engenharia: arquitetura de informação, dados estruturados, links internos e estrutura programática de páginas.
Um programa de palavras-chave que reduziu mais de quarenta mil termos a 40 alvos principais e 400 complementares.
Um motor de conteúdo produzindo cerca de 30 artigos densos por mês, na faixa de 2.000 a 5.000 palavras.
Decisões e trade-offs
01
Construir a plataforma antes de escalar o conteúdo
O custo da escolha: Um primeiro mês mais lento, compensado todo mês depois, porque publicar deixou de esperar pela engenharia.
02
Escolher um page builder em vez de templates por página
O custo da escolha: Mais trabalho nos contratos de bloco no início, o que barateou cada tipo de página nova.
03
Priorizar 40 termos principais e 400 complementares em vez do conjunto completo
O custo da escolha: Deixar deliberadamente uma cauda longa de fora e concentrar o conteúdo nos termos que podiam mover.
04
Medir orgânico não-marca em vez do orgânico total
O custo da escolha: Um número mais difícil e menos lisonjeiro, e o que mostra se o trabalho causou algo.
Resultado
O orgânico não-marca saiu de 50 a 200 visitas por mês para 10.000 por mês em seis meses, e para mais de 20.000 por mês em nove meses. A plataforma foi ao ar com PageSpeed entre 82 e 92, e essa performance é parte da razão de o conteúdo ter ranqueado. Scripts de marketing adicionados depois do lançamento derrubaram a nota; carregá-los corretamente é a vitória mais rápida disponível no site.
50 a 200visitas orgânicas não-marca por mês antes do trabalho
10 mil/mêsorgânico não-marca aos seis meses
20 mil+/mêsorgânico não-marca aos nove meses
82 a 92PageSpeed no lançamento, antes de scripts de terceiros
Stack
PayloadCMS 3, Next.js 15, React 19 e TypeScript.
MongoDB na AWS, com S3, CloudFront e Amplify para entrega, e Mux para vídeo.
GA4 e Google Tag Manager para medição, além de ferramenta de palavras-chave de terceiros.
Próximos passos
Carregar os scripts de terceiros adicionados depois para que o PageSpeed volte à faixa do lançamento.
Ampliar o page builder para cobrir mais padrões de conteúdo sem blocos específicos.
Empacotar a plataforma e o playbook de conteúdo como um trabalho de cliente reutilizável.