CMS headless separa o gerenciamento de conteúdo da apresentação — o cliente edita texto e imagem num painel, mas o front-end pode ser qualquer coisa: um site, um app, ou os dois consumindo a mesma API de conteúdo. Recomendo essa abordagem cada vez mais, mesmo vindo de anos trabalhando com WordPress e Magento tradicionais.
O problema que resolve
CMS tradicional acopla conteúdo e apresentação — se o cliente quer um app mobile consumindo o mesmo conteúdo do site, geralmente precisa duplicar o gerenciamento ou fazer um hack de integração. Headless resolve isso de origem: o conteúdo vive numa API, e qualquer front-end consome do mesmo lugar.
Quando ainda escolho CMS tradicional
Pra site institucional simples, sem plano de expandir pra múltiplas plataformas, o CMS tradicional continua mais rápido de entregar e mais barato de manter — não faz sentido pagar o custo de arquitetura headless pra um problema que não existe ainda.
Como decido com o cliente
Pergunto se existe plano real de ter mais de uma "vitrine" pro mesmo conteúdo nos próximos anos. Se sim, headless paga o investimento inicial maior. Se não, sigo com o que já funciona — o mesmo critério de custo-benefício que aplico em qualquer decisão de escopo de projeto.
