E-commerce sob medida vs Shopify vs headless em 2026: guia

Para a maioria das lojas online europeias, o SaaS (Shopify, BigCommerce) é o padrão certo em 2026: entra no ar em semanas, tem custo total previsível e tira pagamentos e compliance quase inteiramente da sua mesa. O desenvolvimento de e-commerce sob medida só compensa quando o negócio em si não cabe num template — precificação complexa, configuradores de produto, lógica de contrato B2B, produtos regulados ou fulfilment fora do padrão. O headless fica entre os dois e vale a pena quando a vitrine é o diferencial e você tem um time de front-end para cuidar dela.

O restante deste guia traz a tabela comparativa, os trade-offs honestos de ir para headless, o checklist de migração e de conformidade na UE e uma lista de decisão por faixa de receita.

As quatro formas de construir uma loja online

SaaS. Shopify, BigCommerce e Wix hospedam tudo: vitrine, catálogo, checkout, pagamentos, atualizações. Você paga uma assinatura mais um percentual por transação (o Shopify cobra extra quando você não usa o Shopify Payments, o que pesa nos países onde ele não está disponível). A customização acontece por temas, apps e, no Shopify, pelas Functions e pela extensibilidade do checkout. Shopify Plus e BigCommerce Enterprise adicionam recursos B2B, limites de API maiores e multi-loja.

Open-source, auto-hospedado. WooCommerce (WordPress), Magento Open Source / Adobe Commerce e PrestaShop entregam o código-fonte e a conta de hospedagem. O WooCommerce é barato para começar e serve bem para catálogos pequenos, mas escala por meio de plugins de qualidade irregular. O Adobe Commerce é o monólito mais completo para B2B e multi-loja, e também o mais caro de operar: exige desenvolvedores experientes, infraestrutura ajustada e disciplina séria de atualização. O PrestaShop segue popular na França, Espanha e Itália para catálogos de porte médio.

Headless / composable. Um motor de comércio exposto por API — Medusa (Node, open-source), Saleor (Python/GraphQL), commercetools (SaaS, enterprise) ou o Shopify com a Storefront API e o framework Hydrogen — mais uma vitrine que você constrói com Next.js, Remix/Hydrogen, Nuxt ou um app mobile. O conteúdo geralmente vem de um CMS separado, a busca do Algolia ou Meilisearch, e é o seu time que conecta as peças.

Totalmente sob medida. Seu próprio modelo de domínio para produtos, preços, carrinho, pedidos e fulfilment, normalmente construído sobre um framework como Laravel, NestJS, Django ou Spring, com um PSP para pagamentos. Nada vem de graça; tudo é exatamente o que o negócio precisa.

Tabela comparativa: SaaS vs open-source vs headless vs sob medida

Critério	SaaS (Shopify, BigCommerce, Wix)	Open-source auto-hospedado (WooCommerce, Adobe Commerce, PrestaShop)	Headless / composable (Medusa, Saleor, commercetools, Hydrogen)	Totalmente sob medida
Modelo de custo total	Assinatura + % por transação + apps; pouco investimento inicial, cresce com a receita	Hospedagem + desenvolvedores + extensões; Adobe Commerce adiciona licença atrelada ao GMV	Motor (grátis ou licenciado) + construção da vitrine + hospedagem + integração	Custo de construção inicial, depois manutenção, hospedagem, plantão
Teto de customização	Limites de tema e app; restrições de checkout aliviadas pelas Functions no Plus	Alto em código, mas as atualizações do core brigam com customização pesada	Alto na vitrine; motor extensível por plugins ou serviços	Ilimitado
Controle de performance e SEO	Bons padrões, pouco controle sobre renderização, URLs parcialmente fixas (/products/, /collections/)	Controle total, mas monólitos PHP precisam de cache para performar	Controle total de renderização, URLs, Core Web Vitals	Controle total
Recursos B2B	Básicos nos planos padrão; sólidos no Plus / B2B Edition	Adobe Commerce forte; WooCommerce via plugins	commercetools e Saleor fortes; Medusa em crescimento	O que você modelar
Integrações (ERP, PIM, WMS)	Grandes ecossistemas de apps; sync profundo com ERP costuma exigir middleware	Conectores maduros para SAP, Dynamics, Odoo	API-first, você escreve ou compra os conectores	Você escreve tudo
Propriedade e lock-in	Dados exportáveis, lógica e apps não	Você é dono do código e dos dados	Você é dono da vitrine e dos dados; o motor pode ser SaaS	Propriedade total
Carga operacional	Quase zero	Alta: patches, escala, escopo PCI	Média a alta: dois ou mais deployables	Alta
Tempo até o lançamento	Dias a semanas	Semanas a meses	Meses	Meses a um ano

A linha que decide a maioria dos projetos é teto de customização versus carga operacional. Cada passo para a direita compra controle e custa uma capacidade de operação que você precisa ter em equipe.

Quando o desenvolvimento de e-commerce sob medida se justifica

Sob medida se justifica quando a lógica central da loja não pode ser expressa no modelo de dados de uma plataforma sem gambiarras constantes. Os casos recorrentes:

• Precificação complexa. Faixas de volume por grupo de clientes, preços de contrato negociados por conta, tabelas de preço por moeda e país, sobretaxas dinâmicas (metais, frete, energia). O SaaS resolve alguns desses casos; combinados, eles empurram você para apps que não conversam entre si.
• Configuradores e produtos sob encomenda. Móveis, janelas, peças industriais, vestuário personalizado. Um configurador precisa de motor de regras, cálculo de preço em tempo real e, muitas vezes, pré-visualização 3D — veja nosso guia sobre aplicações web 3D com WebGL e Three.js. O item do carrinho é uma especificação, não um SKU.
• Comércio B2B. Contas de empresa com compradores e aprovadores, ordens de compra, prazo de 30 dias, cotações que viram pedidos, catálogos punchout, estoque por armazém vindo do ERP. Um modelo multi-vendedor eleva ainda mais a barra; nosso guia de desenvolvimento de marketplace B2B cobre esse caso em profundidade.
• Produtos regulados. Medicamentos, dispositivos médicos, álcool, tabaco, químicos, acessórios de armas. Verificação de idade ou licença, restrições de venda por país, rastreio de lote e série, documentação obrigatória junto ao pedido.
• Fulfilment fora do padrão. Assinaturas com cadências mistas, aluguéis, reservas atreladas a estoque, envios fracionados de vários fornecedores, retirada em centenas de lojas com estoque local, ou produtos despachados do armazém de um parceiro em seu nome.

Se nenhum desses casos se aplica, a customização que você quer provavelmente é cosmética, e um tema mais alguns apps resolvem. Um teste útil: escreva os cinco fluxos que tornam seu negócio diferente e tente modelá-los numa loja de teste. Se você precisar de mais de dois apps que tenham de concordar entre si sobre um único pedido, está caminhando para sob medida ou headless.

Headless commerce: os trade-offs que ninguém coloca no pitch

O headless costuma ser vendido como "o melhor dos dois mundos". Pode ser, com estes custos ditos com clareza:

Agora você opera uma aplicação de vitrine. Um front-end em Next.js ou Hydrogen é um produto com seus próprios deploys, monitoramento, error budgets e atualizações de dependências. Carrinho, redirecionamentos de checkout, busca, exibição de promoções e tratamento de 404 viram bugs seus. O Shopify Hydrogen na hospedagem Oxygen reduz a parte de hospedagem; não reduz o código que é seu.

Dois sistemas, um pedido. O preço mostrado pela vitrine precisa bater com o que o motor cobra. O estoque precisa estar fresco o bastante no checkout. O conteúdo no CMS não pode referenciar produtos que não existem mais. Cada costura precisa de um contrato, uma política de cache e testes.

Os apps param de funcionar. A maior parte do ecossistema de apps do Shopify injeta código em temas Liquid. Com uma vitrine headless, você reimplementa avaliações, upsells, guias de tamanho e banners de consentimento, ou escolhe apps que expõem uma API.

Os custos mudam de lugar, não desaparecem. Você economiza nos limites de tema e ganha em performance e controle de SEO, mas paga por um time de front-end e pelo trabalho de integração que um monólito resolvia internamente. O commercetools tem preço de enterprise; Medusa e Saleor são gratuitos para usar, não para operar.

Onde o headless ganha com clareza: várias vitrines (web, app, quiosques, marketplaces) sobre um único motor, vitrines com conteúdo editorial pesado, sites em que Core Web Vitals movem receita e empresas cujo diferencial competitivo é a própria experiência de compra.

Um exemplo mínimo da costura que você assume, usando a store API do Medusa a partir de uma vitrine renderizada no servidor:

// Vitrine (server component do Next.js) buscando um produto no Medusa
const res = await fetch(`${process.env.MEDUSA_URL}/store/products/${handle}`, {
  headers: { "x-publishable-api-key": process.env.MEDUSA_PUBLISHABLE_KEY! },
  next: { revalidate: 60 }, // preço desatualizado por até 60s — aceite ou encurte
});
const { product } = await res.json();

Esse valor de revalidate é uma decisão de negócio sobre quão desatualizado um preço pode estar, e agora ela é sua.

Migrar de plataforma sem perder receita

Migrações falham em três frentes: URLs, sinais de SEO e dados.

URLs. Exporte toda URL indexada do Search Console e dos logs do servidor. Mapeie cada uma para o novo endereço e publique um 301 para cada mudança. Os caminhos variam por plataforma: o Shopify usa /products/slug e /collections/slug, o WooCommerce /product/slug, projetos sob medida o que você decidir. Mantenha a estrutura antiga quando puder; um redirect é um custo pago a cada rastreamento.

# Arquivo de redirects no estilo Cloudflare / Netlify
/collections/office-chairs   /pt/categoria/cadeiras-de-escritorio/   301
/products/ergo-chair-x1      /pt/p/ergo-chair-x1/                    301

Sinais de SEO. Preserve títulos, meta descriptions, tags canonical, hreflang entre versões de idioma, dados estruturados de produto (Product, Offer, AggregateRating) e links internos. Regenere o sitemap no dia do lançamento e envie-o. Espere algumas semanas de ruído no ranking; uma queda que persiste por mais tempo normalmente indica URLs abandonadas ou páginas mais lentas.

Dados. Produtos e variantes migram limpos. Clientes, histórico de pedidos, vales-presente, crédito em loja e métodos de pagamento salvos, não. Os tokens de cartão ficam no PSP; se você mantiver o mesmo PSP (Stripe, Adyen, Mollie), em geral consegue manter os tokens, senão os clientes digitam o cartão de novo. Assinaturas são a migração mais difícil e merecem um ensaio próprio. Trate a movimentação de dados como qualquer migração de dados em produção: ensaie numa cópia, meça e mantenha um caminho de rollback.

Faça a virada de uma vez, depois de um ensaio completo em uma cópia de staging com dados reais. Migrações página por página deixam você operando duas plataformas e dividem os sinais de SEO entre elas.

Pagamentos e conformidade na Europa

PSD2 e SCA. Pagamentos com cartão no EEE exigem autenticação forte do cliente, entregue via 3-D Secure 2. Seu PSP cuida do desafio e das isenções (baixo valor, baixo risco, beneficiários confiáveis, transações iniciadas pelo lojista para assinaturas). Seu checkout precisa sobreviver ao redirect ou ao desafio na própria página sem perder o estado do carrinho, e precisa tratar o resultado assíncrono via webhooks, em vez de confiar no retorno do navegador.

PCI DSS. Use hosted fields, um redirect ou um checkout hospedado pelo PSP para que os dados do cartão nunca toquem seus servidores. Isso mantém você no nível mais leve de autoavaliação. Uma plataforma sob medida que renderiza o próprio formulário de cartão com o JavaScript do PSP continua ok; uma que envia números de cartão para o próprio backend, não.

IVA e o balcão único (OSS). Desde o pacote de IVA do e-commerce da UE, vendas B2C transfronteiriças acima do limite comum da UE são tributadas pela alíquota do país do comprador e declaradas pelo OSS em uma única declaração. Sua plataforma precisa cobrar a alíquota certa por destino e categoria de produto, guardar evidências da localização do cliente e emitir relatórios por país. Shopify e BigCommerce já trazem isso; projetos open-source e sob medida normalmente integram um serviço fiscal ou mantêm tabelas de alíquotas com um responsável definido. Para B2B, valide números de IVA pelo VIES e aplique o reverse charge.

GDPR. Consentimento para marketing e cookies não essenciais, base legal para o processamento de pedidos, prazos de retenção para pedidos versus dados de marketing, contratos de processamento de dados com cada operador (PSP, e-mail, analytics, hospedagem) e a capacidade de exportar ou apagar um cliente. O SaaS dá ferramentas; as obrigações continuam com você, como controlador. Nosso guia de GDPR para empresas europeias cobre o lado de engenharia, e o guia de desenvolvimento de sistemas de pagamento aprofunda a integração com o PSP.

Acessibilidade. O European Accessibility Act se aplica a serviços de e-commerce desde 2025. Vitrines sob medida e headless precisam cumpri-lo no próprio código; temas SaaS levam você até parte do caminho, e não mais que isso.

Checklist de decisão por faixa de receita e complexidade

Use a receita online anual como primeiro filtro e a complexidade como segundo.

Abaixo de cerca de € 1 milhão de receita online

• Shopify ou BigCommerce. WooCommerce se o site já é fortemente baseado em WordPress e o catálogo é pequeno.
• Não construa. Cada euro deve ir para produto, tráfego e conversão.
• Exceção: um produto regulado ou um configurador que nenhum app suporta; nesse caso, um pequeno módulo sob medida atrás de uma vitrine SaaS, não uma plataforma inteira.

€ 1 milhão–€ 10 milhões

• Fique no SaaS (considere Shopify Plus ou BigCommerce Enterprise), a menos que dois ou mais dos casos de "sob medida se justifica" se apliquem.
• Headless faz sentido se você tem um time de front-end interno e a experiência da vitrine é o diferencial competitivo.
• Adobe Commerce ou um motor headless se preço por contrato B2B e estoque vindo do ERP são centrais.

€ 10 milhões–€ 50 milhões

• Qualquer opção cabe no orçamento; a questão é onde você quer ser dono do risco.
• Headless sobre Shopify Plus, commercetools ou Saleor quando você precisa de várias vitrines ou mercados.
• Sob medida quando a lógica de preço, fulfilment ou compliance é o negócio, e você já opera software em produção.

Acima de € 50 milhões ou modelos de marketplace

• Composable ou sob medida é a norma; plataformas SaaS esbarram em limites de API, restrições de checkout e tetos de taxa por transação.
• Orce um time de plataforma, não um projeto. Leia nosso post sobre quanto custa software sob medida na Europa antes de se comprometer.

Em qualquer faixa, faça estas perguntas:

1. Quais cinco fluxos tornam nosso negócio diferente, e uma loja de teste consegue modelá-los?
2. Quem conserta o checkout às 3 da manhã na Black Friday?
3. Qual é o custo de saída de cada opção em três anos?
4. Vendemos para empresas com contratos ou para consumidores com cartão?
5. Quantas vitrines, países e moedas vamos operar em dois anos?
6. O ERP é dono do estoque e dos preços, ou a loja é?

Recomendação

Comece pelo SaaS e prove a necessidade de qualquer outra coisa. Vá para headless só quando a própria vitrine é onde você compete e você consegue montar equipe para operá-la. Escolha totalmente sob medida quando o checklist acima devolver pelo menos duas razões estruturais — precificação complexa, configuradores, lógica de contrato B2B, produtos regulados ou fulfilment fora do padrão — e a receita justificar um time de engenharia permanente. Na Arvucore, geralmente recomendamos um motor headless em vez de construir do zero, mesmo no caso sob medida: modele sua precificação e seu fulfilment como serviços próprios e deixe Medusa, Saleor ou commercetools cuidarem de carrinho, pedidos e do encanamento que você reescreveria de outra forma.