Pela equipa da Kiwop · Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada · Publicado a 7 de maio de 2026 · Última atualização: 7 de maio de 2026
TL;DR — Magento headless faz sentido em menos casos do que a indústria vende. Se o teu GMV é <€2M, a tua equipa tem menos de 3 devs ou o teu catálogo é relativamente padrão, o mais provável é que percas dinheiro e meses valiosos. A alternativa real para 80% dos Magento clássicos é Hyvä Themes mais otimização de infraestrutura, ou headless parcial apenas para apps móveis ou portais B2B específicos.
Há anos que recebemos o mesmo pedido de clientes com Magento clássico: "Precisamos de migrar para headless porque é o que os grandes fazem." A conversa costuma seguir o mesmo guião. O e-commerce manager vem de uma conferência, viu uma demo espetacular de PWA Studio ou Next.js com GraphQL, e chegou à conclusão de que o site lento é culpa da arquitetura monolítica.
Em 70% dos casos, quando auditamos o stack real, a causa da lentidão é outra: Varnish mal configurado, imagens sem compressão, extensões que carregam 400KB de JavaScript no critical rendering path, ou simplesmente um hosting inadequado para o tráfego. O headless não resolve nenhum desses problemas. Encarece-os.
Este artigo não é anti-headless. É anti-headless-por-moda. Há casos onde uma arquitetura desacoplada para Magento ou Adobe Commerce tem sentido de negócio claro e ROI demonstrável. Mas esses casos são minoria. O que vamos fazer aqui é dar-te os critérios reais para saber se estás nessa minoria ou nos outros 80%.
O que é Magento headless (e o que NÃO é)
Antes dos cenários, é necessário alinhar terminologia. O termo "headless" usa-se com tanta amplitude no ecossistema Magento que perdeu precisão.
Headless não é o mesmo que React puro
Na aceção mais comum, Magento headless significa separar o frontend do backend: o motor de comércio (catálogo, preços, inventário, checkout, ERP) vive no Magento/Adobe Commerce, enquanto a interface de utilizador se constrói num framework JavaScript independente — Next.js, Nuxt.js, Remix ou similar — que consome os dados através da API GraphQL do Adobe Commerce. O frontend é implementado de forma independente, tem o seu próprio pipeline de build e a sua própria camada de cache.
O resultado é uma arquitetura de dois repositórios, duas equipas potenciais, duas superfícies de monitorização e dois sistemas de atualização que devem permanecer sincronizados em cada mudança de contrato da API.
PWA Studio: a aposta oficial da Adobe
A Adobe lançou PWA Studio em 2018 como o framework oficial para construir frontends PWA sobre Magento 2. Está construído sobre React, usa Peregrine (hooks de lógica) e Venia UI (componentes de interface). Em teoria, é a rota canónica para headless com Magento.
Na prática, a adoção foi moderada. O repositório público no GitHub regista a versão 14.5.0 como a mais recente (publicada em fevereiro de 2026), com 2.700 commits na rama develop e 5 pull requests abertos. É um projeto ativo, mas o ecossistema de extensões do marketplace de Magento não está preparado para PWA Studio: a enorme maioria das extensões de terceiros foi desenhada para o frontend Luma e não oferece um equivalente PWA nativo. Migrar para PWA Studio implica reescrever ou substituir cada extensão que uses.
Frontend custom (Next.js, Nuxt) com GraphQL
A alternativa é prescindir do PWA Studio e construir o frontend diretamente sobre um framework moderno usando a GraphQL API do Adobe Commerce. Mais flexibilidade arquitetónica, menos opinião da Adobe — e mais trabalho próprio. Os projetos que auditámos com esta arquitetura dedicam entre 30% e 40% do tempo de desenvolvimento a reinventar funcionalidade que o Magento já tinha resolvida: paginação de catálogo, filtros de facetas, gestão de moradas de envio, promoções complexas. Não porque seja difícil, mas porque tem de se fazer do zero no frontend.
Por que a linha entre "headless" e "composable commerce" se difundiu
O termo composable commerce acrescenta outra camada de confusão. Composable significa que cada capacidade do stack (pesquisa, pagamentos, CMS, PIM, checkout) é um serviço independente e substituível. Headless é uma pré-condição para ser composable, mas headless não implica composable. Um Magento com frontend Next.js pode ser perfeitamente headless mas continuar a ser monolítico no backend se continuar a depender do Magento para pesquisa, checkout, gestão de conteúdo e regras de preços simultaneamente.
Esta distinção importa porque o custo de uma arquitetura verdadeiramente composable é substancialmente maior do que o de "headless com Next.js". Se alguém te vende "composable" a preço de "headless simples", há um mal-entendido nalgum ponto da conversa.
Os 5 cenários onde NÃO deves migrar
A indústria fala muito de quando headless é a solução. Nós, depois de dezenas de auditorias e vários projetos de migração, vamos contar-te quando não o é.
1. GMV inferior a €2M anuais
O custo real de uma migração headless para um Magento mid-market — discovery, arquitetura, desenvolvimento do frontend, hardening do GraphQL, migração e cutover — oscila entre €105.000 e €210.000 num projeto bem feito. Os detalhes estão discriminados abaixo.
Com um GMV de €2M anuais e uma margem operativa de e-commerce típica entre 10% e 20%, o teu lucro anual está no intervalo de €200.000-€400.000. Dedicar entre 25% e 100% do lucro de um ano inteiro a uma migração arquitetónica que não gera receitas diretas é uma aposta que raramente se recupera no horizonte temporal que os acionistas ou sócios aceitam.
A matemática não mente: para que o investimento faça sentido, o impacto na conversão ou na eficiência operativa deve ser mensurável e antecipável. Com um GMV inferior a €2M, esses números quase nunca fecham. O headless não duplica as tuas vendas. Uma melhor experiência de utilizador pode mover a conversão, mas há formas muito mais baratas de o conseguir.
2. Equipa técnica de 1-2 developers
Headless não só multiplica o custo do projeto inicial: multiplica o custo operativo permanente.
Um Magento clássico com frontend Luma ou Hyvä requer um developer que entenda PHP/Magento, administração do servidor e CSS. Um Magento headless requer simultaneamente: um developer backend que mantém o core do Magento e resolve problemas com a API GraphQL; um developer frontend que mantém o framework JavaScript, o pipeline de build e a camada de cache do CDN; e, idealmente, um perfil DevOps que gere os dois sistemas de deploy, os dois ambientes de staging, a monitorização separada do frontend e do backend, e as atualizações de segurança de dois stacks em paralelo.
Com uma equipa de 1 ou 2 developers, um desses três papéis fica descoberto por defeito. E o primeiro que se descuida — normalmente o backend porque o frontend é o "visível" — acumula dívida técnica, desfasamentos de versão no Magento e, eventualmente, vulnerabilidades de segurança.
Um sistema que ninguém consegue manter bem não é uma arquitetura moderna. É um problema à espera de explodir.
3. Catálogo simples sem customização complexa de negócio
Se o teu Magento tem um catálogo relativamente padrão — produtos simples ou configuráveis, poucas regras de preço complexas, sem lógica de B2B avançada — a fratura entre "o que já funciona no Luma" e "o que é preciso reescrever no novo frontend" é enorme.
O ecossistema de extensões do Magento contém milhares de soluções testadas para search, filtros de catálogo, reviews, comparadores, wishlists, programas de fidelização, multi-currency e dezenas de funcionalidades que os compradores esperam. Quando migras para headless, perdes acesso nativo a esse ecossistema. Cada extensão tem de oferecer um endpoint GraphQL ou uma alternativa API — e a maioria não o faz, porque 90% das instalações de Magento continuam a ser Luma.
Segundo dados do BuiltWith, o Magento conta com mais de 89.000 sites ativos. A esmagadora maioria usa o stack clássico. Os fornecedores de extensões desenvolvem primeiro para esse stack. Se mudas para headless, tornas-te o cliente de nicho que precisa de trabalho custom para cada integração.
4. SEO orgânico forte que não podes arriscar
Este é o cenário que mais subestimámos quando começámos no setor.
As migrações headless mal executadas são devastadoras para o SEO. O motivo não é que o headless seja inerentemente mau para o SEO — um Next.js bem configurado com server-side rendering pode ser perfeitamente indexável — mas sim que a execução é extremamente sensível aos detalhes: redirects 301 corretos, preservação de metadados, canonicals, hreflang, structured data, preload de imagens LCP, cache de páginas de categoria, paginação com rel=canonical correta.
Vimos e-commerces com tráfego orgânico consolidado perder entre 30% e 40% durante os primeiros 3-6 meses de uma migração headless onde se subestimou a complexidade SEO. Recuperar isso leva meses adicionais. O custo em vendas perdidas durante esse período costuma superar o custo do projeto de migração em si.
Se o teu canal orgânico gera mais de 30% das tuas vendas, precisas de um plano de migração SEO tão detalhado e bem orçamentado como o plano de migração técnica. Se esse plano não está no orçamento, o projeto não devia começar.
5. Não tens 6+ meses nem €100K+ de runway
O timeline honesto de uma migração headless para um Magento de tamanho médio é o seguinte: discovery e definição de arquitetura (1 mês), design de sistema de componentes e contrato de API (1 mês), desenvolvimento do frontend (3-4 meses), QA exaustivo e otimização de performance (1 mês), migração de dados, redirecionamentos e cutover (1 mês). Total: entre 7 e 9 meses desde o kick-off até ao dia em que o novo frontend está em produção e o antigo está desativado.
Durante esses meses, o Magento clássico continua em produção, a receber encomendas e a requerer manutenção. Dois sistemas em paralelo, duas equipas, duas prioridades a competir. Se há uma campanha de vendas importante no meio do projeto, o novo frontend pausa. Se há uma vulnerabilidade de segurança no Magento, ambos os sistemas precisam de patch. Se o projeto se atrasa (e atrasará), o runway esgota-se antes do cutover.
Sem pelo menos 6 meses de margem operativa e um orçamento de €100K+ reservado especificamente para a migração — não para "IT em geral" — a probabilidade de o projeto ser concluído com sucesso é baixa. Os projetos que começam com runway ajustado terminam invariavelmente com um frontend headless a meias que coexiste com o Magento clássico de forma permanente, a pagar o custo de manutenção dos dois sem o benefício de nenhum.
Custos reais (números, não estimativas de agência)
O mercado tende a apresentar os custos de migração headless em intervalos tão amplos que são inúteis para tomar decisões. Vamos ser concretos com os dados que gerimos em projetos reais.
Discriminação de uma migração real (cliente Kiwop, anonimizado)
Cliente B2C com GMV de €3,8M anuais, catálogo de 2.400 produtos configuráveis, 15 extensões ativas, tráfego orgânico forte (40% da receita). Arquitetura decidida: Next.js 14 com App Router + API GraphQL do Adobe Commerce + Algolia para search. A alternativa headless avaliada e descartada foi PWA Studio pelo custo das extensões.
O projeto durou 8 meses. A melhoria de LCP foi de 4,1s para 1,8s. A conversão melhorou 14% nos 3 meses após o cutover. O SEO orgânico perdeu 18% de impressões no mês 1, recuperou o nível base no mês 4 e superou o baseline no mês 7. Para este cliente, com o seu GMV e a sua equipa técnica de 5 pessoas, o investimento fez sentido. O que pagámos não foi o headless: foi a recuperação do SEO pós-migração.
Custo oculto: a manutenção dual permanente
O que o orçamento inicial não capta é o custo permanente de operar dois sistemas.
Um Magento clássico bem operado custa entre €500 e €1.500 por mês em engenharia de manutenção (atualizações de segurança, patches de extensões, otimizações de desempenho, monitorização). Um Magento headless soma a esse custo a manutenção do frontend: dependências de Node.js e React, atualizações de framework, gestão do CDN, monitorização de erros de hidratação, alertas de regressão de Core Web Vitals em cada deploy.
O custo operativo total de um Magento headless mid-market raramente desce abaixo de €2.500-4.000 por mês quando incluis engenharia real. Face aos €1.000-1.500 de um Magento clássico bem otimizado. A diferença é €18.000-30.000 anuais adicionais que saem da margem do negócio indefinidamente.
O custo da sobre-engenharia: dois repos, dois pipelines, duas monitorizações
Cada vez que um developer da equipa introduz uma mudança no frontend, precisa de verificar que o contrato GraphQL não mudou. Cada vez que o Magento atualiza a sua API — algo que acontece a cada minor release — há que auditar se o frontend se parte. Cada campanha de marketing que introduz um novo tipo de desconto ou uma regra de preços especial requer coordenar as mudanças em backend e frontend separadamente.
Os e-commerces têm calendários muito stressantes: Black Friday, Natal, saldos de época. Uma arquitetura headless é uma arquitetura que requer coordenação dupla em cada sprint de campanha. Se a tua equipa já sofre com um sistema, não o resolves acrescentando outro.
Quando SIM faz sentido migrar para headless
Demos os cinco cenários onde não migrar. Para ser justo, há casos onde headless é a resposta correta.
Multi-canal real com um único backend. Se precisas de servir a mesma lógica de catálogo, preços e inventário para um site, uma app iOS, uma app Android, um quiosque de loja física e um portal B2B para distribuidores, um backend Magento com API GraphQL como fonte de dados única tem sentido arquitetónico claro. Um frontend por canal, um backend que os alimenta a todos. O custo de manutenção distribui-se entre múltiplas superfícies que antes requeriam backends separados.
Performance crítica que o stack clássico não consegue resolver. Se o teu Magento tem um LCP consistentemente superior a 3 segundos e esgotaste as otimizações de Varnish, Redis, compressão de imagens e eliminação de JavaScript bloqueante, e se o teu negócio tem evidência de que cada décima de segundo de LCP impacta a conversão de forma mensurável, o investimento em headless pode justificar-se. Mas primeiro é preciso ter esgotado as alternativas. A maioria dos Magento com LCP mau já os levamos abaixo de 2 segundos sem tocar na arquitetura.
GMV superior a €5M com equipa técnica de mais de 5 developers. A diluição do custo de investimento e manutenção sobre um volume maior muda a matemática. Uma equipa de 5+ devs consegue organizar papéis especializados sem deixar lacunas. Um GMV de €5M+ gera a margem para absorver o custo operativo adicional e justificar o upside de performance e flexibilidade.
Composable real, não Magento como monolito disfarçado. Se a estratégia é substituir o Magento como sistema de pesquisa (por Algolia ou Elastic), como CMS de conteúdo (por Contentful ou Sanity), como sistema de pagamentos (por Stripe ou Adyen direto) e como checkout (por um headless checkout especializado), ficando o Magento apenas como OMS e motor de preços, então headless é a consequência lógica dessa estratégia composable. Mas essa estratégia tem o seu próprio custo e complexidade — muito além de um projeto de frontend.
As alternativas que funcionam para 80% dos Magento clássicos
Se não estás nos cenários do "SIM", estas são as alternativas que têm ROI real.
Alternativa 1: Hyvä Themes — o "headless leve" que não o é
Hyvä Themes é a alternativa mais pragmática e, na nossa experiência, a mais subaproveitada. É um tema de frontend para Magento 2 que substitui o stack Luma (KnockoutJS + RequireJS + jQuery, que carrega mais de 200 recursos JS/CSS e supera 1,5MB de assets) por um stack moderno baseado em Tailwind CSS e Alpine.js, que carrega apenas dois recursos com um peso total de aproximadamente 0,2MB.
O resultado em Core Web Vitals é significativo. Segundo a documentação de benchmarks do Hyvä, o tema está desenhado para passar Core Web Vitals desde o primeiro deploy em configurações padrão, com reduções de peso de JavaScript de mais de 85% face ao Luma. Em produção, mais de 7.000 lojas já o usam, incluindo marcas como Audio-Technica e Nestlé.
O que Hyvä não é: não é headless. O frontend continua a fazer parte do monolito Magento, a correr no mesmo processo PHP. Não tens um repositório separado. Não tens um pipeline de deploy separado. Não precisas de um developer React. O que tens é um frontend consideravelmente mais rápido e fácil de manter, com acesso completo ao ecossistema de extensões do Magento.
Custo e timeline: um projeto de migração de Luma para Hyvä para um Magento mid-market padrão está no intervalo de €15.000-30.000 e completa-se em 4-8 semanas. Dez vezes mais barato do que headless, sem as complexidades operativas e com o SEO intacto.
A única limitação do Hyvä é que requer que as extensões de terceiros que uses tenham compatibilidade com Hyvä. O ecossistema de compatibilidade cresceu muito nos últimos anos, mas continua a ser uma verificação necessária antes de iniciar o projeto.
Alternativa 2: Magento clássico otimizado a fundo
Antes de falar de mudanças de arquitetura, faz o trabalho que a maioria dos Magento não fez corretamente: otimização de infraestrutura e rendering.
O stack de otimização que resolve 80% dos problemas de performance em Magento clássico:
- Varnish corretamente configurado para cache de página completa, com purge granular por tag. Sem Varnish ou com Varnish mal configurado, o Magento não consegue ser rápido.
- Redis para cache de sessões e de bloco. O Magento tem dois caches internos além do de página completa; sem Redis em ambos, o TTFB sofre.
- Otimização de imagens com ImageMagick, compressão de WebP ou AVIF e lazy loading correto. A maioria dos Magento com LCP mau tem imagens sem compressão ou sem o atributo
loading="lazy"nas imagens fora do viewport inicial. - Eliminação de JavaScript bloqueante no critical path. A extensão média do Magento acrescenta entre 20KB e 80KB de JavaScript que bloqueia o rendering. Uma auditoria de cobertura de JS no Chrome DevTools costuma revelar entre 60% e 80% de código não utilizado na primeira carga.
- CDN com edge caching para assets estáticos. Cloudflare no plano gratuito já resolve boa parte do problema para visitantes internacionais.
Com este stack bem configurado, é habitual levar o Magento de um LCP de 4-5 segundos para menos de 2 segundos sem tocar no código da aplicação. O custo: entre €5.000 e €15.000 em trabalho de engenharia, mais o custo mensal do servidor adequado.
Alternativa 3: headless parcial apenas para apps móveis ou portais B2B
Se tens um caso de uso específico onde headless faz sentido — uma app móvel nativa, um portal de compra para distribuidores B2B com lógica de preços própria — podes implementar headless exatamente aí, sem migrar o site principal.
O backend Magento expõe a sua API GraphQL para a app móvel ou para o portal B2B. O site principal continua a ser Magento clássico (idealmente com Hyvä) e não introduz complexidade de manutenção adicional. Obtens o benefício do headless onde realmente acrescenta valor, sem pagar o custo na parte onde o stack clássico funciona bem.
Este padrão tem uma vantagem SEO direta: o site principal, que concentra 90% do tráfego orgânico, não se toca. O risco de regressão é mínimo.
Alternativa 4: migrar para Shopify Plus (sim, a sério)
Esta sugestão incomoda muita gente no ecossistema Magento, mas é a resposta honesta para um segmento específico de clientes: e-commerces com GMV entre €500K e €2M, catálogo padrão sem customizações críticas de negócio, e sem equipa técnica própria.
Shopify Plus tem um custo mensal entre €2.300 e €4.000 dependendo do volume, mas elimina praticamente todo o custo de manutenção de infraestrutura, atualizações de segurança, gestão de servidor e dívida técnica acumulada. O ecossistema de apps do Shopify cobre a maioria das funcionalidades que as extensões do Magento resolvem. O checkout do Shopify converte melhor do que qualquer checkout custom por design.
A migração técnica de Magento para Shopify tem o seu próprio custo e complexidade, especialmente na parte de catálogo, historial de encomendas e SEO. Mas se a alternativa é gastar €150K num headless Magento para um negócio de €1M de GMV, o Shopify pode sair mais barato no custo total de propriedade a 3 anos.
A nossa recomendação: fazer a análise de TCO (Total Cost of Ownership) a 3 anos antes de decidir entre manter o Magento, fazer headless ou migrar de plataforma.
Checklist de decisão: headless sim ou não?
Antes de comprometer orçamento e meses de trabalho, passa por estas perguntas. São as mesmas que fazemos nas nossas auditorias iniciais.
Se tens 5 ou mais indicadores "contra headless", o projeto precisa de ser repensado antes de arrancar. Se tens 6 ou mais indicadores "para headless", a conversa sobre arquitetura faz sentido.
Caso real: quando dissemos NÃO a um cliente (e como acabou)
Um cliente B2B do setor industrial contactou-nos para migrar o seu Magento 2 para headless. GMV: €1,2M anuais. Equipa técnica: 1 developer interno com perfil Magento. Razão declarada para o headless: "o site é lento e a concorrência tem PWA".
Fizemos a auditoria antes de aceitar o projeto — é uma prática que na Kiwop aplicamos sempre em projetos de desenvolvimento Magento quando há mudança de arquitetura em jogo. Os resultados:
- LCP médio: 4,8s. Causa principal: Varnish desativado (estava instalado mas o cache de página completa estava sem funcionar há 8 meses por um conflito de extensão não resolvido). Causa secundária: 14 extensões a carregar JS no critical path sem defer.
- CLS: 0,31. Causa: imagens do slider principal sem dimensões declaradas.
- O catálogo tinha 340 produtos com configurações de preço padrão. Zero lógica custom de B2B.
A nossa recomendação: migrar para Hyvä Themes, ativar e configurar corretamente o Varnish, implementar lazy loading em imagens e diferir o JavaScript das extensões. Sem headless.
Resultado: Core Web Vitals passing em 3 semanas. LCP: 1,6s. CLS: 0,02. Tráfego orgânico sem impacto. Custo total: €22.000 face aos €135.000 orçamentados para o headless. O developer interno da sua equipa conseguiu manter o sistema sem formação adicional.
A conversa difícil foi dizer ao cliente que o headless que queria não era a solução. A conversa fácil foi mostrar-lhe os resultados três semanas depois.
Perguntas frequentes
O Magento clássico está obsoleto?
Não. A Adobe continua a publicar versões de Adobe Commerce e Magento Open Source com suporte ativo. A versão 2.4.x é a rama atual, com atualizações de segurança e compatibilidade regulares. O ecossistema de extensões continua ativo. O que está obsoleto é o frontend Luma em termos de performance — mas isso resolve-se com Hyvä Themes, não necessariamente com headless.
A Adobe vai forçar headless no futuro?
A Adobe posicionou o headless como direção estratégica do Adobe Commerce, especialmente para clientes enterprise. Mas "direção estratégica" não significa abandono do stack clássico a curto prazo. O PWA Studio continua a receber atualizações (v14.5.0 em fevereiro de 2026). A Adobe mantém suporte oficial para instalações monolíticas. Para a maioria dos merchants, a pressão para headless virá do mercado — não da Adobe a desativar o stack clássico.
O Hyvä Themes é production-ready?
Sim. Com mais de 7.000 lojas em produção, incluindo implementações de grandes marcas, Hyvä é um projeto maduro. O ecossistema de extensões compatíveis cresceu significativamente. Antes de qualquer projeto Hyvä, há que verificar a compatibilidade das extensões específicas que usas — o site oficial e o marketplace de compatibilidade do Hyvä são a referência.
Posso fazer "headless parcial"?
Sim, e é frequentemente a melhor solução. Manter o frontend web no Magento clássico (ou Hyvä) e construir apenas a app móvel ou o portal B2B contra a API GraphQL é uma estratégia válida que te dá o benefício do headless onde acrescenta valor real sem os custos operativos de migrar o site principal.
Quanto tempo demora uma migração headless bem feita?
Para um Magento mid-market (€1M-5M GMV, 1.000-10.000 SKUs, 10-20 extensões ativas), o timeline realista é 7-9 meses desde o kick-off até ao cutover em produção. Projetos que prometem concluir-se em 3-4 meses ou têm âmbito muito limitado ou vão ter problemas em QA e migração. O timeline longo não é um defeito do projeto: é a consequência de fazer as coisas bem.
E se quiser migrar de Magento para Shopify diretamente?
É uma opção legítima para um segmento específico. A migração técnica inclui catálogo, historial de encomendas, contas de cliente e redirecionamentos SEO — há ferramentas especializadas para isso. O custo de migração costuma ser menor do que um projeto headless em Magento. A limitação é a personalização: o Shopify tem limites na extensibilidade do checkout e em lógica de negócio muito específica. Se o teu negócio tem regras de preço B2B complexas, bundles muito customizados ou integrações ERP proprietárias, o Shopify pode ficar aquém. Se não, pode ser a opção mais sensata.
Se estás a avaliar uma mudança de plataforma, também vale a pena considerar PrestaShop para negócios no intervalo de €200K-1M de GMV, onde o TCO pode ser ainda menor do que o Shopify Plus com um stack mais flexível.
Conclusão: a moda não deve decidir a tua arquitetura
As migrações para Magento headless falhadas têm algo em comum: começaram com a solução em mente antes de entender o problema. Alguém viu uma demo, leu um caso de sucesso de um e-commerce de €50M e assumiu que a mesma arquitetura escalava para baixo. Não escala.
A arquitetura correta é a que resolve o problema específico do teu negócio ao custo que consegues absorver com a equipa que tens. Para a maioria dos Magento clássicos, isso significa Hyvä Themes mais otimização de infraestrutura, não um projeto de 8 meses e €150K que duplica a complexidade operativa permanente.
Headless faz sentido quando: tens multi-canal real, GMV >€5M, equipa >5 devs, esgotaste as otimizações clássicas e tens o runway para fazê-lo bem.
Não faz sentido quando: qualquer uma dessas condições falta.
Na Kiwop — Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada para clientes globais na Europa e EUA — fazemos auditorias técnicas prévias a qualquer decisão arquitetónica em e-commerce. Se o teu Magento tem problemas de desempenho, antes de assumir que a solução é headless, deixa-nos analisá-lo. O diagnóstico correto custa uma fração do projeto errado.
Consulta os nossos serviços de desenvolvimento Magento, comercio composable, desenvolvimento de PWA e desenvolvimento web — ou escreve-nos diretamente e avaliamos juntos se headless é a opção certa para o teu caso.
