Projete um catálogo de produtos com variantes e kits usando regras claras de SKU, lógica de inventário e padrões de UI que evitam combinações inválidas e overselling.
Um catálogo parece simples quando cada produto é um item com um preço e um número de estoque. Adicione cor, tamanho, duração de assinatura ou embalagem específica por região e essa simplicidade se quebra. Uma única tabela “Products” não responde mais perguntas básicas: qual é exatamente a coisa que estamos vendendo e como devemos rastreá-la?
Os compradores também esperam que os detalhes estejam corretos. Eles querem escolher opções, ver o preço certo imediatamente e saber se a escolha exata pode ser enviada hoje. Se a página diz “Em estoque” mas o tamanho selecionado não existe mais, a confiança cai rápido. Se o preço só muda no checkout, surgem tickets de suporte e devoluções.
Bundles adicionam uma segunda camada de complexidade porque se parecem com produtos, mas se comportam como regras. Um “Starter Kit” pode incluir uma garrafa, uma bomba e um conjunto de filtros. A disponibilidade depende das peças, e seus custos e relatórios ainda precisam fazer sentido.
Sinais de que seu catálogo está começando a rachar:
A correção é em grande parte disciplina: um modelo de dados consistente e padrões de UI que tornam a escolha de opções e a disponibilidade óbvias para clientes e para sua equipe.
Quando as pessoas dizem “variantes”, costumam misturar algumas ideias diferentes. Deixar as palavras claras desde o início facilita muito as decisões posteriores (schema, UI, inventário).
A maioria das equipes usa estas definições:
IDs também ficam confusos na prática. Um ID interno é o que o banco de dados usa. Um SKU é seu código operacional (usado em picking, reposição e relatórios). Um barcode (UPC/EAN) é o que os leitores escaneiam. Um SKU pode ter múltiplos barcodes (regiões diferentes) e alguns itens não têm barcode.
Uma boa regra para decidir se algo deve ser uma variante vendável: se puder ter preço, estoque, peso ou regras de envio diferentes, trate como vendável. A mesma camiseta nos tamanhos M e XL geralmente precisa de contagens de estoque separadas, então devem ser SKUs distintos.
Antes de escolher um esquema, comece pelas perguntas que o negócio precisa responder todo dia. Quando alguém olha um item, você consegue dizer com confiança: está disponível agora, quanto custa, como será enviado e quais regras fiscais se aplicam?
Uma forma útil de pensar é decidir onde cada “fato” vive. Coloque fatos compartilhados no produto e fatos que mudam na variante (SKU). Se misturar, você acabará consertando o mesmo bug em dois lugares.
Perguntas que geralmente definem campos a nível de produto vs nível de variante:
Mantenha uma única fonte da verdade. Por exemplo, não armazene “price” no produto e na variante a menos que os papéis sejam claros (por exemplo, produto tem MSRP, variante tem preço de venda).
Planeje para mudanças. Talvez você adicione uma nova opção depois (como “Length”), aposente uma variante ou una SKUs após mudanças de fornecedor. Isso é mais simples quando variantes são registros de primeira classe, não apenas rótulos.
Se você está construindo no AppMaster, nomes claros de entidades no Data Designer tornam isso mais fácil de manter conforme os requisitos mudam.
Um esquema limpo mantém o catálogo compreensível quando um produto simples vira dezenas de combinações vendáveis. O objetivo é modelar escolhas (o que os compradores selecionam) separadamente dos itens vendáveis (o que você realmente estoca e envia).
Um conjunto confiável de entidades:
A unicidade da variante é onde muitos catálogos erram. A abordagem mais segura é normalizada: garanta um OptionValue por Option para cada Variant e previna combinações duplicadas. Se também quiser velocidade, armazene uma “variant key” computada como color=red|size=m (ou um hash dela) na Variant e aplique unicidade por Product.
Mantenha campos que mudam por combinação na Variant, não no Product: SKU, barcode, price, compare-at price, cost, weight, dimensions, status (active/discontinued) e imagens (ou uma imagem principal ou um pequeno conjunto de imagens).
Para atributos customizados (como “material” ou “instruções de cuidado”), evite adicionar novas colunas para sempre. Um campo JSONB no Product ou na Variant funciona bem em PostgreSQL, combinado com uma pequena camada de validação na sua aplicação.
Um SKU é um identificador de uma unidade vendável que você promete manter estável. Deve responder a uma pergunta: “Qual item exato vendemos?” Não deve carregar seu nome de marketing, texto completo de opção, estação ou uma história inteira. Se sobrecarregá-lo, fica difícil mudar algo depois sem quebrar relatórios.
Decida cedo se SKUs são atribuídos manualmente ou gerados. SKUs manuais são mais seguros quando você já tem um ERP, códigos de barras ou SKUs de fornecedor que precisam bater. SKUs gerados são melhores quando há muitas variantes e você precisa de consistência, mas somente se as regras não mudarem no meio do ano. Um meio-termo comum é um SKU base fixo que você controla, mais um sufixo curto gerado para atributos da variante.
Regras que permanecem legíveis e sobrevivem ao crescimento:
SKUs descontinuados não devem ser deletados. Marque como inativos, mantenha o histórico de preços e deixe-os selecionáveis em pedidos passados, reembolsos e relatórios. Se você substituir um SKU, armazene uma referência “replaced by” para que o suporte possa rastrear o que aconteceu.
Regras de validação evitam danos lentos ao longo do tempo: aplique unicidade de SKU entre todos os itens vendáveis, permita apenas letras, números e hífens, defina um comprimento máximo claro (frequentemente 20–32 chars) e reserve prefixos para casos especiais (como “BND-” para bundles). No AppMaster, essas checagens cabem como constraints de dados e um Business Process que bloqueia salvamentos quando uma regra é violada.
Inventário fica confuso quando o mesmo “produto” pode significar muitas unidades vendáveis diferentes. Antes de escrever regras, escolha sua unidade de inventário: você rastreia em nível de produto, variante ou ambos?
Se os clientes escolhem tamanho ou cor, o estoque por variante é geralmente mais seguro. Uma camiseta pode estar “em estoque” no geral, mas a variante Small-Blue pode estar esgotada. Estoque por produto funciona para itens onde variantes não mudam o que você guarda fisicamente (por exemplo, uma licença digital com diferentes planos de cobrança). Algumas equipes mantêm ambos: nível de produto para relatórios, nível de variante para venda.
Prevenir overselling é menos sobre uma flag mágica e mais sobre estados claros. A maioria dos catálogos precisa de reservas (segurar unidades temporariamente para carrinhos ou pedidos não pagos), backorders (permitir venda com datas claras de envio), buffers de estoque (quantidade oculta para cobrir atrasos de sincronização) e atualizações atômicas (reduzir estoque na mesma operação que confirma o pedido).
Casos de borda são onde vem o “estoque misterioso”. Devoluções devem adicionar estoque somente após inspeção, não quando uma etiqueta de devolução é criada. Itens danificados devem ir para um status ou localização separados para não aparecerem como vendáveis. Ajustes de estoque precisam de trilha de auditoria (quem mudou o quê e por quê), especialmente se múltiplos canais atualizam inventário.
Bundles e kits adicionam uma regra-chave: não decremente um registro “bundle” se o bundle for apenas um agrupamento. Decremente os itens componentes. Um multipack de 3 deve reduzir três unidades do mesmo SKU; um kit deve reduzir uma unidade de cada componente.
Exemplo: um “Starter Kit” inclui 1 garrafa e 2 filtros. Se você tem 10 garrafas e 15 filtros, a disponibilidade do kit é 7 porque os filtros são o limitador. A matemática baseada em componentes mantém relatórios, reembolsos e reabastecimento consistentes.
No AppMaster, isso mapeia limpo para tabelas de variante no Data Designer e lógica de reserva/decremento no Business Process Editor, para que todo checkout siga as mesmas regras.
Bundles são onde catálogos frequentemente viram casos especiais. A abordagem mais simples é modelar bundles como itens vendáveis normais e anexar uma lista clara de componentes.
Uma estrutura limpa é: Product (item vendável) mais BundleLines. Cada BundleLine aponta para um component SKU (ou um produto componente mais uma variante requerida) e armazena uma quantidade. Pedidos ainda mostram “um item”, mas você pode expandi-lo em partes quando precisar de custo, inventário e detalhe de fulfillment.
A maioria das configurações de bundle se encaixa em uma destas:
Preço é onde times acidentalmente quebram relatórios. Decida antecipadamente o que aparece na linha do pedido e o que alimenta relatórios de margem e inventário. Abordagens comuns são preço fixo do bundle, soma das peças ou soma com desconto com regras por componente (por exemplo, “escolha 3 itens, o mais barato com 50% off”).
Inventário deve ser igualmente rigoroso: um kit está disponível somente se cada componente requerido estiver disponível na quantidade necessária. Para relatórios, armazene duas visões da venda:
No AppMaster, isso se encaixa naturalmente: uma tabela Bundle mais linhas BundleLine, com Business Processes que expandem componentes no checkout e gravam tanto a venda do bundle quanto o consumo dos componentes em uma única transação.
Uma boa UI de opções mantém as pessoas avançando. Uma UI ruim faz com que adivinhem, encontrem erros e saiam. A chave é guiar os compradores para uma variante real e comprável cedo, mostrando claramente o que suas escolhas alteram.
Um padrão confiável é apresentar as opções (Size, Color, Material) e então calcular e mostrar apenas as escolhas que ainda fazem sentido.
Em vez de deixar o cliente escolher qualquer combinação e falhar ao adicionar ao carrinho, desative combinações impossíveis assim que o usuário fizer uma escolha. Por exemplo, quando alguém escolhe Color = Black, tamanhos que não existem em Black devem ficar desabilitados (não removidos), para que o cliente entenda o que está indisponível.
À medida que a seleção muda, atualize as partes que mais importam: preço (incluindo preço em promoção e quaisquer descontos de bundle), imagens principais (casar com a cor ou estilo selecionado), status de estoque (estoque da variante exata, não estoque genérico do produto), estimativa de entrega (se variar por variante) e, opcionalmente, o SKU ou “Item code” para suporte.
Mantenha a interface calma. Mostre alguns grupos de opção por vez, evite dropdowns enormes quando swatches ou botões funcionam melhor, e deixe a seleção atual óbvia.
No admin, as pessoas precisam de velocidade, não de cartões bonitinhos. Uma grade de variantes funciona bem: cada linha é um SKU, cada coluna é uma opção ou uma regra (preço, barcode, peso, estoque, ativo/inativo). Adicione ações em massa para tarefas comuns como atualização de preços, alternar disponibilidade ou atribuir imagens.
Se você construir isso no AppMaster, uma configuração prática é uma grade ligada à sua tabela Variant com filtros (valor da opção, status ativo, estoque baixo), mais uma ação de atualização em massa que valida regras antes de salvar.
Um fluxo de seleção deve parecer simples, mas precisa de regras estritas por baixo. O objetivo é sempre saber qual SKU exato o comprador está configurando e se ele pode ser comprado agora.
Carregue mais do que nome e imagens do produto. Você precisa do conjunto completo de valores de opção (Size, Color) e da lista de combinações de variantes válidas que existem como SKUs.
Um fluxo confiável:
Um pequeno detalhe de UI que evita frustração: desative valores de opção impossíveis assim que escolhas anteriores são feitas. Se Size=M existe apenas em Black, mostre outras cores como indisponíveis quando M for selecionado.
Para bundles, “em estoque” não é um único número. Depende dos componentes. A regra usual é:
bundle_available = mínimo entre os componentes de floor(component_stock / component_qty_per_bundle)
Exemplo: um “Starter Kit” precisa de 1 garrafa e 2 filtros. Se você tem 10 garrafas e 9 filtros, a disponibilidade do kit é min(floor(10/1)=10, floor(9/2)=4) = 4 kits.
Mensagens de erro devem ser concretas. Prefira “Apenas 4 kits disponíveis (os filtros limitam este bundle)” a “Fora de estoque.” No AppMaster, esse tipo de checagem é simples de expressar em um Business Process: compute a variant correspondente primeiro, depois calcule os limites do bundle e retorne um status claro para a UI exibir.
Catálogos quebram quando você modela para “tudo que poderia existir” em vez de “o que realmente vai ser vendido”. A maneira mais rápida de se enredar é gerar todas as combinações de opção possíveis antecipadamente e depois tentar manter limpo conforme o catálogo cresce.
Criar variantes que nunca serão estocadas é a armadilha clássica. Se você tem 4 cores x 6 tamanhos x 3 materiais, são 72 variantes. Se só 10 serão vendidas, as outras 62 records criam bagunça, convidam erros e deixam relatórios lentos.
Preço é outra fonte silenciosa de bugs. Problemas começam quando o mesmo preço existe em vários lugares (produto, variante, tabela de preços, tabela de promo) sem uma única fonte da verdade. Uma regra simples ajuda: armazene o preço base uma vez e guarde overrides somente onde realmente necessário (por exemplo, uma variante tem preço diferente).
Bundles e kits falham no inventário quando você decrementa tanto o bundle quanto seus componentes. Se você vende um “Starter Kit” que inclui 1 garrafa e 2 filtros, subtrair 1 kit e também subtrair 1 garrafa e 2 filtros faz o estoque zerar cedo demais. Mantenha o bundle como item vendável, mas compute disponibilidade e decrements a partir dos componentes.
Ferramentas de admin podem causar danos se permitirem dados inválidos. Adicione guarda-costas cedo:
Finalmente, planeje mudanças. Adicionar uma nova opção depois (como “Width” para sapatos) é uma migração, não um checkbox. Decida o que acontece com variantes existentes, como defaults são definidos e como pedidos antigos mantêm seu SKU e snapshot de opções.
Antes de lançar, faça uma passada nas coisas que quebram na vida real: encontrar SKUs, atualizar estoque e bloquear compras impossíveis.
Certifique-se de que todo SKU vendável seja fácil de achar. A busca deve encontrá-lo por nome, código SKU, barcode/GTIN e atributos-chave (como tamanho ou cor). Se você usa escaneamento no armazém, teste algumas leituras físicas e confirme que caem no SKU exato, não apenas no produto pai.
Seja rigoroso sobre onde mudanças de estoque acontecem. Escolha uma fonte da verdade (sua lógica de movimentação de inventário) e garanta que todo evento a use: pedidos, cancelamentos, reembolsos, ajustes manuais e montagem de bundles. Se estoque puder ser editado em duas telas ou dois workflows, derivações são garantidas.
Checks de lançamento que valem a pena rodar:
Se você está construindo no AppMaster, mantenha regras de atualização de estoque em um único Business Process e chame-o de todos os caminhos. Esse hábito único previne a maioria dos bugs de inventário.
Imagine uma loja de vestuário que ainda precisa de um catálogo sério.
Você vende uma camiseta com duas opções: Size (S, M, L) e Color (Black, White). Cada combinação comprável é sua própria variante com seu SKU, preço (se necessário) e inventário.
No esquema, mantenha um registro Product para “Classic T-shirt”, dois registros Option (Size, Color) e várias records de Variant. Cada Variant armazena seus valores de opção selecionados (por exemplo: Size=M, Color=Black) e o SKU (por exemplo: TSH-CL-M-BLK). O inventário é rastreado no nível da Variant, não do Product.
Na UI, restrinja escolhas e previna becos sem saída. Um padrão limpo é: mostre todas as Colors primeiro, então mostre apenas Sizes que existem para a Color escolhida (ou o contrário). Se “White + L” não existe, não permita a seleção ou mostre como desabilitado com uma nota clara.
Agora adicione um bundle: “Gift Set” que inclui:
A disponibilidade do bundle é limitada pelo componente mais escasso. Se o estoque do Sticker pack é 5, você não pode vender mais que 5 bundles, mesmo se as camisetas tiverem muito estoque. Se o bundle exige uma variante específica de camiseta (por exemplo, Black M), então o estoque do bundle é min(StickerPackStock, BlackMStock).
Próximos passos práticos no AppMaster:
Se quiser prototipar rápido de ponta a ponta, AppMaster (appmaster.io) é desenhado para criar apps completos com lógica de negócio real — exatamente o que seleção de variantes e regras de inventário de bundles exigem.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
