Calculadora de orçamentos com IA: mantenha a lógica de preços em um só lugar

Por que calculadoras de orçamento feitas com IA frequentemente mostram números errados

Uma calculadora de orçamentos é o formulário (ou tela estilo planilha) que transforma alguns inputs em um preço: assentos, uso, plano, taxas de setup, descontos, imposto e o total final. As pessoas confiam nela por um motivo: o número mostrado deve bater com o que será cobrado.

Calculadoras construídas com IA muitas vezes parecem corretas numa demo, mas as regras de preço acabam espalhadas. Uma tela aplica um desconto, outra recomputa totais e uma terceira “corrige” o arredondamento. Quando a mesma conta existe em vários lugares, basta uma edição esquecida para a calculadora sair de sincronia.

Os bugs normalmente são pequenos. O dano não é. Um erro de $20 vira problema de confiança. Também gera trocas constrangedoras: vendas promete um total, financeiro fatura outro, e o cliente se sente enganado mesmo quando foi um bug honesto.

Números errados geralmente entram por alguns padrões:

• Regras divididas entre UI, código do backend e configurações no banco
• Defaults ocultos (imposto ligado/desligado, moeda, taxas mínimas)
• Erros na ordem das operações (desconto antes do imposto vs depois do imposto)
• Diferenças de arredondamento entre itens e total final
• Regras antigas deixadas para trás após atualização de preços

Um cenário simples: um cliente escolhe Pro, adiciona 12 assentos e aplica 15% de desconto anual. O app mostra um total com desconto, mas o sistema de faturamento aplica o desconto a um subtotal diferente. Ambos “seguiram as regras” como implementadas. O cliente recebe a dor de cabeça.

A solução é direta: mantenha a lógica de preços em um só lugar e valide com exemplos reais e saídas esperadas.

Comece anotando entradas, saídas e regras

Antes de pedir a uma ferramenta de IA para construir uma calculadora, escreva a spec em palavras simples. Se pular isso, você frequentemente terá algo que parece certo, mas quebra em combinações reais de clientes.

Comece com as perguntas que a calculadora deve fazer. Mantenha-as amigáveis ao cliente: “Quantos assentos?”, “Cobrança mensal ou anual?”, “Precisa de onboarding?”, “Em qual país você está?” Se uma entrada for opcional, especifique o que acontece quando ela ficar em branco.

Em seguida, defina as saídas e o formato. Um orçamento não é só “um preço”. Decida o que a calculadora deve retornar sempre, por exemplo:

• Subtotal
• Linha de desconto
• Linha de imposto
• Total final

Decida também como o dinheiro é exibido (moeda, casas decimais e se mostra centavos).

Um orçamento precisa de uma definição clara de “válido”. Anote as regras que tendem a gerar disputas:

• Moeda: apenas uma moeda ou escolha baseada no país
• Impostos: incluídos no preço exibido ou adicionados no checkout
• Arredondamento: quando arredondar (por item vs total final) e para quantas casas
• Mínimos: menor quantidade permitida, piso de preço e quando rejeitar um input
• Datas de vigência: quando uma mudança de preço começa e como lidar com orçamentos antigos

Aqui vai um resumo simples de regras de preço que um fundador não técnico pode aprovar:

“Se o usuário selecionar 10 assentos com cobrança mensal, o preço é $29 por assento. Cobrança anual aplica 10% de desconto no subtotal. Onboarding é uma taxa única de $500. Imposto não está incluído. Total final é arredondado para 2 decimais.”

Mantenha a lógica de preços em um só lugar (fonte única de verdade)

A maneira mais rápida de obter orçamentos errados é copiar regras de preço em múltiplos lugares: uma fórmula na UI, outra no backend e um “conserto rápido” num webhook. Sua calculadora precisa ter um único lugar para as regras de preço, e todo o resto deve chamá-lo.

Escolha uma localização e mantenha: uma função de preço, um módulo ou um arquivo de configuração que a aplicação trate como autoridade. Se você já se pega editando dois arquivos para mudar um preço, já existe drift.

Separe a UI da precificação. A UI deve coletar inputs (plano, assentos, add-ons, país, cupom) e mostrar resultados. Não deve decidir como os descontos se empilham, como o imposto é aplicado ou como o arredondamento funciona. Essa separação torna mudanças mais seguras porque você não precisa vasculhar botões, telas e handlers para achar matemática escondida.

Um padrão limpo é: uma chamada entra, uma resposta sai. A UI envia um objeto completo de entrada, e a precificação retorna um resultado estruturado com um detalhamento legível.

// pricing.js
export function priceQuote(input) {
  // Rules live here. Update this, not the UI.
  // Note: coupons apply before tax; tax is on discounted subtotal.
  return {
    subtotal: 120,
    discount: 20,
    tax: 10,
    total: 110,
    breakdown: [
      "Base: $120",
      "Coupon: -$20",
      "Tax: $10"
    ]
  };
}

Adicione notas curtas ao lado das regras que as pessoas tendem a quebrar depois: limites de tiers, ordem de empilhamento e qualquer exceção estranha que exista por um motivo. Comentários não precisam ser longos — só precisam evitar reescritas acidentais.

Uma estrutura de preços simples e legível

A maioria dos bugs de orçamento aparece quando regras viram uma pilha de if espalhados. Mantenha as regras fáceis de escanear e a função de cálculo sem sofisticação.

Use nomes de variáveis que casem com a linguagem do negócio. Se alguém não consegue explicar o que discount_rate significa, vai usá-lo errado depois.

Um modelo de preços que você lê em 30 segundos

Aqui está uma forma simples que evita espalhar lógica por todo app:

const pricing = {
  base_price: 49,
  per_unit: 12,
  discount_rate: 0.10,
  discount_min_qty: 10,
  tax_rate: 0.07
};

function quote({ quantity }, pricing) {
  const subtotal = pricing.base_price + (quantity * pricing.per_unit);
  const discount = quantity >= pricing.discount_min_qty ? subtotal * pricing.discount_rate : 0;
  const taxable = subtotal - discount;
  const tax = taxable * pricing.tax_rate;
  const total = taxable + tax;

  return {
    total: Math.round(total * 100) / 100,
    breakdown: { subtotal, discount, taxable, tax }
  };
}

Dois hábitos mantêm isso estável:

• Arredonde apenas uma vez no final (não no meio do cálculo).
• Sempre retorne um detalhamento.

Esse detalhamento é como você percebe erros rapidamente, por exemplo: imposto sendo aplicado antes do desconto.

Passo a passo: construir a calculadora com ferramentas de IA sem bagunça

Calculadoras dão errado quando a UI e as regras de preço crescem juntas no mesmo arquivo. Separe-as desde o dia um e você pega erros mais cedo.

Uma sequência de build limpa

Comece fazendo a interface funcionar sem matemática real. Gere apenas o formulário e a exibição: inputs (plano, assentos, add-ons, país) e saídas (subtotal e total). Se você consegue digitar valores e vê-los refletidos na tela, tem uma base sólida.

Depois adicione uma única função de precificação e conecte tudo a ela. Mantenha simples: uma função recebe um objeto plano de inputs e retorna resultados planos. Não coloque cálculos em handlers de botões ou componentes de UI.

Uma ordem de build que se mantém organizada:

• Construa a UI primeiro, usando números placeholders.
• Crie uma função de precificação e chame-a da UI.
• Faça a função retornar um detalhamento completo: subtotal, desconto, imposto, total.
• Adicione validação básica para campos faltantes e valores negativos, com mensagens claras.
• Coloque as regras em um único arquivo de regras e trate-o como o único lugar onde preços podem mudar.

Quando a função retornar um detalhamento, a UI vira “burra” de forma boa: ela só renderiza as linhas. Revisões também ficam mais fáceis porque você pode comparar o detalhamento com um cálculo manual.

Adicione exemplos reais de entradas para detectar erros cedo

A forma mais rápida de perder bugs é testar com números inventados. Orçamentos reais têm combinações que você não vai pensar: um pedido pequeno com taxa mínima, um pedido que cruza um limite de tier, ou um desconto que deveria aplicar antes do imposto.

Colete de 10 a 20 exemplos reais de entradas a partir da planilha de preços, faturas passadas ou orçamentos que você já enviou. Misture tamanhos de pedido comuns com alguns que usaram descontos, add-ons ou termos especiais.

Antes de codar, escreva o total esperado ao lado de cada exemplo. Faça isso como uma checagem humana usando as mesmas regras que você disse para a calculadora. Se duas pessoas não concordam no total esperado, suas regras estão confusas, não sua matemática.

Aqui está um conjunto simples que você pode manter como uma tabela re-executável:

Mantenha essa tabela no projeto e reexecute-a após cada mudança. Falhas devem ser óbvias: esperado vs real, mais qual regra foi disparada (tier, desconto, imposto, arredondamento). Se a calculadora não explicar por que um número mudou, não é seguro publicar.

Verificações rápidas antes de liberar uma mudança de preço

Edições pequenas de preço quebram calculadoras com mais frequência do que se imagina. Renomear uma opção, adicionar um toggle de desconto ou “mais uma taxa” pode mudar a matemática silenciosamente.

Checklist de pré-lançamento de 10 minutos

Execute estas checagens sempre que tocar em preços, tiers, descontos, impostos ou layout do orçamento:

• Mude apenas o texto da UI (rótulos, texto de ajuda, símbolos de moeda) e confirme que os números não mudam.
• Calcule à mão 3–5 orçamentos e verifique se a calculadora bate exatamente.
• Confirme que regras de arredondamento são consistentes: arredonda cada item ou apenas o total final.
• Teste campos em branco, zeros e valores negativos. Campos em branco devem significar “não fornecido”, não NaN.
• Verifique que o detalhamento somado bate com o total final, sem taxas faltando ou descontos contados duas vezes.

Depois do checklist, faça um “smell test” com entradas realistas (por exemplo: 3 assentos, plano mensal, 10% de desconto, mais imposto). Se imposto ou desconto parecerem errados, você geralmente percebe imediatamente.

Mantenha um pequeno conjunto de “golden quotes”

Escolha alguns orçamentos representativos e anote seus totais esperados. Quando mudar preços, reexecute os mesmos orçamentos e compare.

Um conjunto prático: o menor pedido, um pedido típico e um pedido grande perto de um limite de tier. Adicione um com desconto e outro com imposto. Se qualquer total mudar inesperadamente, a lógica de preços mudou em algum lugar que você não queria.

Erros comuns que geram orçamentos errados

A maneira mais rápida de perder confiança é quando duas pessoas inserem os mesmos detalhes e obtêm dois totais diferentes.

Uma das maiores causas é duplicar regras de preço. Você adiciona 10% de desconto na tela de checkout, mas a prévia do admin usa uma fórmula antiga. Clientes veem um número e faturas mostram outro.

Outro problema comum é fazer impostos, descontos e arredondamento em ordens diferentes em pontos distintos. Uma pequena mudança de sequência pode deslocar totais, especialmente com tiers.

A aritmética em ponto flutuante também cria diferenças de centavos. Se seu app espera que 0.1 + 0.2 seja exatamente 0.3, pode acabar com pequenas discrepâncias que crescem quando soma muitos itens.

Padrões por trás da maioria dos bugs de “matemática misteriosa”:

• Regras de preço duplicadas entre telas, rotas de API ou jobs em background
• Descontos e impostos aplicados em ordens diferentes em partes distintas do app
• Arredondamento feito de modo inconsistente em vez de um passo fixo e documentado
• Mudanças de preço atualizadas em um lugar, mas não na lógica de orçamento/fatura salva
• Falta de um detalhamento claro, então você não vê onde o número mudou

Sempre mostre um detalhamento: preço base, ajustes de tier, valor do desconto, subtotal tributável, imposto e total final. Quando algo parecer errado, o detalhamento diz onde procurar.

Casos de borda: tiers, descontos, impostos e arredondamento

A maioria dos bugs de orçamento se esconde nas regras pequenas. Uma calculadora pode parecer certa nos caminhos felizes, e então falhar na primeira vez que alguém compra 11 unidades, usa um cupom ou paga em outra região.

Tiers e limites: onde os totais desviam

Precificação por tiers precisa de limites claros. Exemplo: “primeiras 10 unidades a $20, cada unidade depois a $15.” Decida o que acontece exatamente em 10, em 11 e em 0.

Também decida a ordem das operações quando mistura tiers com mínimos, tetos e taxas únicas. Escreva isso. Se uma parte do app aplica o teto antes da taxa de setup e outra aplica depois, você terá totais diferentes para as mesmas entradas.

Descontos, impostos e arredondamento: escolha uma ordem e mantenha

Cupons são uma armadilha porque “10% off” não é igual a “$10 off”, e regras de empilhamento mudam totais rápido. Se cupons podem expirar, o orçamento deve mostrar se o cupom foi aceito e por quê.

Impostos variam por região, mas a maior pergunta é simples: imposto aplica antes ou depois dos descontos? Muitas equipes assumem uma coisa e constroem a outra.

Para arredondamento, decida se arredonda por linha (cada tier, cada taxa) ou apenas no total final, e como trata meios-centavos.

Decisões que valem a pena travar:

• Limites de tier são inclusivos (1–10) ou lógica de “primeiros N”?
• Cupons empilham, e em qual ordem (fixo então percentual, ou percentual então fixo)?
• Imposto se aplica a taxas de setup, e é calculado antes ou depois dos descontos?
• Qual regra de arredondamento você usa, e onde arredonda?
• Se suportar múltiplas moedas, qual fonte de câmbio e timestamp usar?

Teste concreto: 11 unidades, tiers como acima, $50 de setup, cupom 10%, imposto 8.25% após desconto, arredondar só no final. Se sua calculadora não reproduz o mesmo número sempre, as regras ainda não estão específicas o suficiente.

Um exemplo realista de orçamento (com números) para testar sua lógica

Aqui está um teste concreto que você pode copiar para sua calculadora. É uma pequena agência cotando um site com alguns add-ons comuns.

Use estes inputs de exemplo (e escreva as regras ao lado):

• Pacote base: $2,000 (inclui 5 páginas)
• Páginas solicitadas: 8 (3 páginas extras a $150 cada)
• Add-on: configuração de CMS $300
• Rush: taxa de urgência de 15%
• Código de desconto: SAVE10 (10% sobre base + páginas + add-ons, não sobre rush)
• Imposto: 8% aplicado a tudo (incluindo rush)

Agora o detalhamento esperado:

• Base + páginas extras + add-ons: $2,000 + (3 x $150) + $300 = $2,750
• Desconto (10% de $2,750): -$275.00 -> subtotal com desconto $2,475.00
• Taxa de rush (15% do $2,750 original): +$412.50 -> subtotal tributável $2,887.50
• Imposto (8% de $2,887.50): +$231.00
• Total final: $3,118.50

É aqui que bugs costumam se esconder: esquecer de tributar a taxa de rush, ou aplicar o desconto na ordem errada (descontar depois do imposto, ou descontar o rush quando a promoção não deve incluir ele).

Se a precificação mora em uma função (fonte única de verdade), você pode transformar esse exemplo em um teste automatizado. Quando mudar um preço ou adicionar regra, os mesmos inputs ainda devem produzir $3,118.50. Se mudar, você pega a regressão imediatamente.

Próximos passos quando sua calculadora gerada por IA precisa de conserto

Se sua calculadora parecia ok na demo mas quebra com clientes reais, trate como bug de produto, não como “um ajuste matemático pequeno”. Lógica de preços é fácil de estragar quando espalhada entre código da UI, triggers no banco e funções auxiliares.

Sinais de que é mais que um patch rápido

Alguns padrões indicam que o código precisa de limpeza adequada:

• Totais mudam após um refresh de página ou ao editar um campo
• Totais diferentes para as mesmas entradas (frequentemente arredondamento ou ordem de imposto)
• Novas regras de preço parecem “assustadoras” de adicionar porque tudo pode quebrar
• Orçamentos não podem ser salvos ou enviados por problemas de auth ou estado

Como repassar as regras para que a matemática seja verificada rápido

Você não precisa ser técnico, mas precisa tornar as regras testáveis. Um bom repasse inclui:

• Uma página com resumo das regras (entradas, fórmulas, impostos/taxas, política de arredondamento)
• 5–10 orçamentos reais com totais esperados (incluindo ao menos um caso de borda)
• O que mudou recentemente e quando os totais errados começaram
• Restrições (moeda, regiões, requisitos de fatura, limites de desconto)

Se o protótipo estiver muito emaranhado, reconstruir a calculadora limpo pode ser mais barato do que tentar consertar para sempre.

Se você herdou um app gerado por IA e precisa de alguém para desembaraçar lógica de preço duplicada (e problemas de produção relacionados como auth quebrado ou segredos expostos), a FixMyMess em fixmymess.ai se especializa em transformar protótipos gerados por IA em software pronto para produção. Uma auditoria rápida de código geralmente é suficiente para apontar exatamente onde os totais divergem.