Spryker ou CWS Platform: o que entra no custo total depois da assinatura?
A licença é a primeira linha da proposta. Manter a versão em dia, o modelo de contratação e o suporte formam o resto da conta.
Nota editorial: comparativo entre Spryker e a CWS Platform escrito para quem responde como CFO. Todo fato sobre Spryker vem da documentação pública dele, com o endereço ao lado.
A proposta de uma plataforma de comércio B2B chega ao financeiro com um número na primeira página: a licença. O custo total aparece depois, espalhado em linhas que não estavam na proposta: as horas do time ou do parceiro para manter a versão em dia, o modelo de contratação que traz ou não as ferramentas de atualização, o tempo que a operação fica esperando quando um chamado demora.
Para o CFO, a pergunta não é quanto custa a licença no primeiro ano. É quanto custa manter a plataforma funcionando e atualizada no terceiro, e quais dessas linhas o contrato deixa com a empresa.
Este comparativo olha para Spryker e CWS Platform só por esse ângulo: como a versão avança, o que vem junto com a contratação e o que a documentação diz sobre suporte. Não é um ranking de funcionalidades. Se você quer antes a moldura geral, o post sobre os três modelos de plataforma de comércio B2B separa as arquiteturas sem falar de um fornecedor só.
O que o Spryker resolve bem
O Spryker tem uma ferramenta própria para reduzir o trabalho manual de atualização. O Spryker Code Upgrader combina a ferramenta de atualização com pipelines de CI no Spryker CI, com uma pipeline dedicada por projeto, e o agendamento da checagem é configurável.
O funcionamento está descrito em How Spryker Code Upgrader works: a ferramenta compara os arquivos composer.json e composer.lock do branch conectado com o código mais recente lançado pela Spryker, agrupa os módulos e as bibliotecas de terceiros conforme o modelo de release e aplica as atualizações por grupos. As versões de segurança entram primeiro, e o resultado é commitado num branch padronizado, com abertura de pull request pela API do provedor de código.
Para o financeiro, isso tem valor concreto: a atualização de rotina chega como uma mudança revisável, e não como um projeto que alguém precisa lembrar de abrir. Para uma empresa com time de engenharia que mantém o próprio projeto, é uma forma organizada de transformar manutenção de versão em fluxo contínuo.
Onde a arquitetura diverge
A divergência que interessa ao CFO está no que fica fora da automação e no que depende da contratação. Pelo mecanismo documentado, versões major não são aplicadas de forma automatizada: o Upgrader as ignora e inclui no pull request links de documentação com instruções manuais. A mesma documentação registra que projetos anteriores ao release 2022.04 não são compatíveis com esse fluxo incremental (When and why to use manual upgrade).
A documentação do próprio fornecedor registra dois pontos que entram na conta de três anos:
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: o Code Upgrader é fornecido com o PaaS+ nas regiões da UE e dos EUA ("The Upgrader is shipped with PaaS+ in the EU and US regions.", https://docs.spryker.com/docs/ca/devscu/spryker-code-upgrader.html).
- limitação registrada na documentação do fornecedor em 07/09/2026: a Spryker não garante e não pode garantir tempo de resolução dos chamados ("we do not and cannot guarantee resolution times for the issues you open with us", https://docs.spryker.com/docs/about/all/support/understanding-slas.html).
O primeiro ponto liga a ferramenta de atualização a um modelo de contratação e a regiões. Para o CFO, a pergunta para a proposta fica objetiva: o escopo cotado inclui o PaaS+, numa dessas regiões? Se não incluir, a atualização volta a ser trabalho planejado à parte, e esse trabalho precisa de uma linha no orçamento.
O segundo ponto muda a forma de calcular o risco operacional. Quando o tempo de resolução não é garantido, o custo de um incidente longo, em horas internas e em pedidos que esperam, fica com a empresa. Não é um defeito de quem escreveu a regra: é uma escolha contratual declarada, e cabe ao financeiro precificá-la.
Na CWS Platform, todos os clientes rodam a mesma versão da plataforma. A política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace), no princípio de configuração em vez de código, e a cobrança é de licença de plataforma e licença de integração, sem percentual sobre vendas ou GMV.
| decisão | Spryker, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| Como a versão avança | Code Upgrader abre pull request com atualizações por grupos, segurança primeiro; versões major ficam fora da automação, com instruções manuais | Todos os clientes rodam a mesma versão |
| O que condiciona a atualização assistida | Code Upgrader fornecido com o PaaS+ nas regiões da UE e dos EUA; projetos anteriores ao release 2022.04 fora do fluxo incremental | Mesma versão para todos os clientes, com a regra comercial em parâmetros |
| Como a cobrança se relaciona com o volume | Ponto a confirmar na proposta | Licença de plataforma e licença de integração, sem percentual sobre vendas ou GMV |
A decisão financeira é saber quais linhas do custo de manter a plataforma ficam com a empresa e quais estão cobertas pelo modelo contratado.
O que muda na operação, pela lente de CFO
A conta de três anos tem três blocos que costumam ser subestimados na fase de proposta.
O primeiro é a manutenção de versão. Atualização de rotina por pull request ainda pede alguém para revisar e testar; versão major com instrução manual pede projeto. O CFO não precisa entender o código, mas precisa saber quantas horas por ano a empresa ou o parceiro vão dedicar a isso.
O segundo é o modelo de contratação. Quando uma ferramenta de atualização vem com um modelo específico e em regiões específicas, a proposta mais barata pode ser a que deixa essa ferramenta de fora. Comparar propostas sem igualar o escopo é comparar números que não medem a mesma coisa.
O terceiro é o custo do incidente. Sem tempo de resolução garantido, a empresa precisa decidir quanto tolera de pedido parado e quem paga as horas internas enquanto o chamado está aberto.
Três perguntas levam esse raciocínio para qualquer avaliação: qual modelo de contratação inclui a ferramenta de atualização e em que regiões; quantas versões major o fornecedor prevê no período do contrato e quem executa a migração; e o que o contrato garante sobre prazo de resolução de chamados.
Na CWS Platform, todos os clientes rodam a mesma versão, e tabelas de preço, regras e contratos são configurados na plataforma ou recebidos do ERP e do CRM por API, com casas decimais customizáveis, no princípio de configuração em vez de código.
Quando escolher o Spryker
O Spryker atende bem a cenários em que a empresa quer manter o projeto com time próprio e tem estrutura para isso:
Time de engenharia que revisa atualizações. Escolha essa arquitetura quando a empresa tem um time que quer receber as atualizações de rotina como pull request e decidir quando aplicá-las, como descreve o Spryker Code Upgrader.
Contratação no modelo em que a ferramenta vem junto. Escolha essa arquitetura quando o escopo contratado já inclui o PaaS+ numa das regiões em que o Code Upgrader é fornecido, e o orçamento prevê as migrações major que ficam fora da automação.
Reposição em lote feita pelo comprador. Escolha essa arquitetura quando o comprador repõe itens colando listas de produtos e quantidades ou buscando por SKU, e os itens validados seguem para carrinho, lista de compras ou checkout, como no Quick Add to Cart.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando o financeiro quer uma licença sem percentual sobre o volume vendido e a regra comercial em parâmetros, com todos os clientes na mesma versão.
Licença sem percentual sobre vendas. Escolha essa arquitetura quando o orçamento de tecnologia não deve ficar atrelado a um percentual da receita do canal digital. A cobrança é de licença de plataforma e de licença de integração, sem percentual sobre vendas ou GMV.
Uma versão para todos os clientes. Escolha essa arquitetura quando a empresa quer operar sempre na versão corrente da plataforma. Todos os clientes rodam a mesma versão.
Regra comercial como configuração. Escolha essa arquitetura quando a política comercial muda com frequência. Tabelas, regras e contratos ficam em parâmetros do Commerce Rules Engine (CDL Workspace), o desconto do vendedor passa por alçadas com aprovação em níveis, o crédito do cliente é mantido na plataforma, e milhares de promoções podem rodar juntas.
Um só sistema para o ecossistema. Escolha essa arquitetura quando cliente, vendedor e operação precisam trabalhar no mesmo sistema. O CDL Workspace é um só sistema para todo o ecossistema, e um vendedor atende milhares de clientes na mesma interface que o cliente usa.
Por onde continuar
Se a sua decisão passa também pela integração com o ERP, o comparativo Spryker ou CWS Platform: por onde passa o preço por cliente na integração com o ERP? olha a mesma escolha pela lente do CTO.
Antes de assinar, vale conversar com um especialista da CWS Platform para montar a conta de três anos lado a lado, com o mesmo escopo nas duas propostas. A página Quando Vender Mais Não Significa Ganhar Mais trata da dor por trás deste cenário, sem falar de fornecedor nenhum.
Leia também
Marcas citadas neste artigo
Marcas e logotipos pertencem aos seus titulares. A citação não indica parceria nem endosso.
"Estavamos á quase 2 anos tentando implantar uma solução B2B, com a CWS, implantamos em 60 dias."
Quer ver isso na sua operação?
Operações B2B reais já rodam nisso.