O problema
Persiana é produto sob medida: o preço sai de uma fórmula com largura, altura, tecido e tipo de acionamento. Plataforma de e-commerce trabalha com variantes fixas cadastradas — não com fórmula. Na prática, o cliente pedia orçamento por WhatsApp e alguém calculava na mão.
O que construí
- Configurador na própria página do produto, dentro do template Twig da loja.
- Worker de precificação que recebe a configuração, aplica a regra de negócio e devolve o preço.
- Criação de variante via API REST, para que o item configurado exista de verdade no carrinho e siga o fluxo normal de checkout da plataforma, em vez de virar um pedido especial fora do sistema.
- Frete calculado com as dimensões da peça montada, não do produto genérico.
Decisões técnicas
Não fugir do checkout da plataforma. A tentação era montar um carrinho paralelo. Isso teria quebrado cupom, frete, relatório e integração fiscal — tudo que a loja já fazia. Criar a variante sob demanda foi mais trabalho no começo e menos problema para sempre.
A regra de negócio virou documento antes de virar código. Toda mudança na fórmula de preço entrava primeiro na documentação e só depois no Worker. Sem isso não há como saber se um preço estranho é bug ou é a regra — e com produto sob medida, essa dúvida aparece toda semana.
Como verifiquei
Comparação do preço devolvido pelo Worker com o cálculo manual do cliente numa bateria de combinações de medida e tecido, incluindo os extremos da tabela; e conferência de que a variante criada chega ao carrinho com o preço e as dimensões certos, até o fim do checkout.