Nossa estratégia de saída do Shopify: avaliando alternativas de comércio eletrônico headless

O Shopify é muito bom no que faz. A taxa de conversão do checkout é alta, o ecossistema de aplicativos é rico, a confiabilidade operacional é excelente e, para um comerciante que deseja vender produtos sem construir infraestrutura, a proposta de valor é difícil de contestar. Vale dizer isso claramente antes de descrever por que fechamos nossa loja nele — porque a decisão não decorreu de uma inadequação geral do Shopify. A plataforma não atendia bem aos requisitos operacionais específicos que havíamos acumulado.

A maioria das narrativas de “saída do Shopify” se concentra em taxas de transação, limitações de temas ou o desejo de uma loja personalizada. Essas são razões reais, mas não são as mais relevantes. O problema mais fundamental é que o Shopify é otimizado para um tipo específico de comerciante — alto volume, catálogo padronizado, direto ao consumidor — e suas restrições se tornam atrito quando seus requisitos divergem desse perfil.

O que o Shopify acertou

O checkout é a parte mais defensável da proposta de valor do Shopify. Anos de otimização em milhões de lojas produziram um fluxo de checkout que converte, lida bem com casos excepcionais e integra métodos de pagamento em mercados sem exigir trabalho de integração personalizado. Construir um checkout comparável do zero é um projeto de vários meses com custo significativo de manutenção contínua.

A camada de operações — gerenciamento de pedidos, processamento e envio de pedidos, devoluções, ferramentas de atendimento ao cliente — é igualmente madura. A interface de administração adota convenções próprias de funcionamento, mas reflete sabedoria operacional genuína sobre como os fluxos de trabalho de comércio eletrônico funcionam em escala. Equipes que precisam integrar funcionários não técnicos para gerenciar pedidos consideram a UX do Shopify substancialmente mais fácil do que qualquer alternativa headless disponível atualmente.

O ecossistema de aplicativos, apesar de sua reputação por custos ocultos, resolve problemas reais. Plataformas de avaliação, faturamento de assinatura, programas de fidelidade, análises avançadas — essas integrações funcionam porque o Shopify padronizou os webhooks, modelos de dados e autenticação dos quais os aplicativos de terceiros dependem. Em uma arquitetura headless, cada uma dessas integrações deve ser construída sob medida ou obtida de fornecedores que podem não oferecer suporte nativo para a plataforma escolhida.

As restrições que impediram o avanço

As limitações de i18n foram o ponto inicial de atrito. O suporte multilíngue do Shopify, embora substancialmente melhorado em relação ao seu estado inicial, ainda trata os mercados não-anglófonos como preocupações secundárias. Gerenciar conteúdo em uma dúzia de idiomas pela interface de administração do Shopify é operacionalmente penoso de maneiras que se agravam à medida que o catálogo cresce. Aplicativos de tradução ajudam, mas adicionam custo e introduzem complexidade de sincronização que uma solução nativa eliminaria.

A questão de propriedade dos dados se tornou o problema mais fundamental ao longo do tempo. Todos os dados operacionais relevantes — histórico de pedidos, registros de clientes, catálogo de produtos — ficam no banco de dados do Shopify, acessível por uma API que o Shopify controla. Os limites de requisições dessa API, as políticas de retenção de dados e os formatos de exportação são determinados pelo Shopify, não pelo comerciante. Para equipes que precisam executar cargas de trabalho analíticas sobre seus próprios dados operacionais, essa é uma restrição estrutural, não uma opção de configuração.

A complexidade do modelo de preços foi uma terceira restrição. Produtos com muitas variantes, preços personalizados por segmento de cliente e fluxos de trabalho baseados em cotação para clientes empresariais esbarram nos limites de variantes do Shopify (100 por produto até o Shopify aumentar o limite para 2.048 em outubro de 2025) e em suas estruturas de preços de maneiras que exigem soluções alternativas cada vez mais complicadas. A complexidade resultante do template Liquid se torna um problema de manutenção que se agrava com o crescimento do catálogo.

A avaliação: Medusa v2, Saleor, Commerce.js

A avaliação foi estruturada em torno de quatro critérios: propriedade dos dados (controle total sobre o banco de dados, sem limites de API impostos pelo fornecedor), profundidade de i18n (suporte nativo a múltiplas moedas, múltiplos idiomas e precificação regional), experiência do desenvolvedor (qualidade da documentação, suporte a TypeScript, fluxo de trabalho de desenvolvimento local) e maturidade operacional (implantações em produção, modos de falha conhecidos, tamanho da comunidade).

Medusa v2 teve o melhor desempenho na experiência do desenvolvedor. A reescrita v2 é uma melhoria substancial sobre a arquitetura original: o sistema de módulos é bem projetado, os tipos TypeScript são abrangentes e o fluxo de trabalho de desenvolvimento local é rápido. A documentação melhorou significativamente e reflete uma equipe que leva a experiência do desenvolvedor a sério. A restrição é a maturidade operacional — a v2 é relativamente recente (o Medusa 2.0 foi lançado em outubro de 2024), e os relatos de implantação em produção são menos numerosos e diversos do que os de plataformas mais estabelecidas. As equipes que migram para o Medusa estão, de fato, entre os primeiros usuários da plataforma.

Saleor é o mais comprovado em produção dos três, com uma base maior de implantações em produção e uma API GraphQL genuinamente bem projetada. A arquitetura multicanal — separando o conceito de “canais” para diferentes mercados, lojas online ou segmentos de clientes — lida com a complexidade de preços e catálogo que nos afastou do Shopify com mais elegância do que as alternativas. A maturidade operacional é a mais alta dos três avaliados. A contrapartida é uma curva de aprendizado mais íngreme e uma API centrada em GraphQL que requer investimento em ferramentas antes de se tornar produtiva.

Commerce.js ocupa uma posição diferente: é uma API headless em vez de uma plataforma de comércio completa, projetada para ser combinada com outros serviços em vez de usada como uma solução completa. Para equipes com forte capacidade de engenharia que desejam controle detalhado sobre cada componente, esta é uma escolha apropriada. Para equipes que buscam se afastar do custo operacional do Shopify sem acrescentar um esforço equivalente de engenharia em outra forma, provavelmente não é a escolha adequada. Por ser uma API hospedada, também não oferece controle total sobre o banco de dados, nosso primeiro critério. Além disso, em outubro de 2026, a Chec, empresa por trás do Commerce.js, já arquivou sua organização no GitHub (em outubro de 2024), portanto verifique o status atual do serviço antes de considerá-lo.

O caminho de migração

O custo mais subestimado em uma migração de plataforma é a migração de dados, não a migração da base de código. Mover o catálogo de produtos, registros de clientes e histórico de pedidos do Shopify para uma nova plataforma requer scripts de extração personalizados, transformação de dados para corresponder ao esquema de destino e tratamento cuidadoso de casos excepcionais (produtos com mais de 100 variantes, clientes com históricos de endereços complexos, pedidos parcialmente processados e enviados) que representam uma pequena porcentagem dos registros, mas uma grande porcentagem do tempo de engenharia de migração.

A transição operacional — o período em que o volume de pedidos precisa ser processado por ambos os sistemas enquanto a migração é validada — requer planejamento cuidadoso para evitar processamento e envio duplicados de pedidos ou comunicações duplicadas com clientes. Esta é a fase em que a maioria das migrações encontra problemas que não foram antecipados durante o planejamento, porque os casos excepcionais que importam são específicos do catálogo e histórico de pedidos do comerciante, não gerais ao comércio eletrônico.

A lição desta avaliação e de observar outras equipes tomando decisões semelhantes é que a escolha da plataforma é menos determinante do que a qualidade do planejamento da migração. Medusa e Saleor são capazes de suportar operações de comércio eletrônico em produção, assim como o Commerce.js era na época da nossa avaliação. As equipes que têm sucesso com migrações headless são as que investem em entender as diferenças do modelo de dados antes de iniciar a migração, não durante ela.