PORTFÓLIO / myPRICER · SISTEMA DE LUCRO PARA CURSOS
Quanto isso realmente precisa custar?
Em 2007/08, eu não estava tentando criar software. Eu só precisava descobrir quanto cobrar por um curso sem decidir no escuro.
A resposta coube numa planilha.
Quase vinte anos depois, a pergunta ainda voltava. Só que agora vinha acompanhada de margem, caixa, parcelamento, inadimplência e uma dúvida mais incômoda: a turma que parecia lucrativa terminou lucrativa?
ANTES DO PRODUTO
Eu não queria criar um SaaS.
Queria parar de tomar uma decisão importante no escuro.
Na época, o problema parecia simples: definir o preço de um curso.
Só que preço nunca vinha sozinho.
- Professor
- Material
- Comissão
- Estrutura
- Taxas
- Alunos
- Inadimplência
A primeira resposta foi Excel. Naquele momento, era a ferramenta certa.
03 / ORIGEM
O problema veio antes do produto.
Numa operação de educação profissional, parte do material e da metodologia era padronizada. A formação do preço, não.
Cada unidade tinha sua própria realidade. Então olhar para o preço do concorrente não respondia à pergunta que eu precisava resolver.
Eu precisava entender a conta daquela turma.
04 / PRIMEIRA RESPOSTA
A planilha resolvia a conta. E, por um tempo, isso bastava.
Eu conseguia mexer nas variáveis e ver a decisão mudar junto.
Era muito melhor do que escolher um preço porque o mercado cobrava parecido — ou porque aquele número simplesmente parecia bom.
- Alterar gastos
- Mudar o número de alunos
- Comparar cenários
- Testar preços
05 / A PERGUNTA CRESCE
O problema é que a conta começou a fazer perguntas de volta.
Conforme a mesma decisão reaparecia em operações diferentes, “quanto devo cobrar?” deixou de ser suficiente.
- 01Quantos alunos preciso vender para não perder dinheiro?
- 02O que acontece com a margem quando eu parcelo?
- 03Quando o dinheiro realmente entra no caixa?
- 04Quanto uma taxa consome do que parecia lucro?
- 05E se parte dos alunos não pagar?
- 06A turma que parecia lucrativa terminou lucrativa?
Foi aí que preço deixou de ser o problema inteiro. A decisão econômica da turma era maior.
06 / O PONTO DE VIRADA
Vender bem e ganhar bem são coisas diferentes.
Depois que você percebe, parece óbvio.
Antes disso, é muito fácil olhar para venda, preço ou lotação e chamar tudo de resultado.
Isso ainda não diz quanto virou lucro.
A receita foi vendida. O caixa ainda precisa esperar.
Sem gastos e taxas, isso não prova margem.
Lotação não conserta uma conta ruim.
A operação real ainda pode discordar.
A planilha conseguia formar preço. O problema já estava pedindo para acompanhar o que acontecia depois dele.
07 / A DECISÃO
A ferramenta precisava acompanhar a turma antes e depois da venda.
Essa foi a mudança de lógica.
Preço deixou de ser uma resposta final. Virou o começo de uma hipótese que a operação teria de confirmar.
- 01ANTES DE LANÇARdecidir
Quanto preciso cobrar e vender?
- 02DURANTE A VENDAoperar
Como estão vendas, matrículas, parcelas e caixa?
- 03DEPOIScomparar
O resultado real confirmou o que eu planejei?
08 / DE CALCULADORA PARA SISTEMA
Foi aí que uma calculadora de preço ficou pequena demais.
O nome veio depois. A mudança importante aconteceu na regra.
Preço passou a conversar com gastos, meta de alunos, formas de pagamento, ponto de equilíbrio, caixa, vendas, matrículas, parcelas e resultado real.
- Preço
- Gastos
- Meta de alunos
- Formas de pagamento
- Ponto de equilíbrio
- Fluxo de caixa
- Vendas
- Matrículas
- Parcelas
- Resultado real
Hoje eu chamo essa estrutura de Sistema de Lucro para Cursos. O software veio depois da regra.
09 / UMA DECISÃO DE PRODUTO
Quatro pessoas podem precificar a mesma turma – e nenhuma começar pela mesma conta.
Uma já sabe quanto pretende cobrar. Outra pensa em margem. Outra quer saber quanto precisa ganhar por aluno. Outra só tem uma meta para o resultado final da turma.
Se eu obrigasse todas a começar por margem, o sistema resolveria uma conta e criaria outro problema: obrigar gente diferente a raciocinar do mesmo jeito.
Por isso, preço, margem, lucro por aluno e meta de lucro podem ser o começo. A pessoa informa o que sabe. O motor recalcula o que falta.
10 / POR QUE ISSO IMPORTA
Software bom não deveria exigir tradução simultânea.
Se alguém pensa “quero que essa turma me deixe R$ X”, não faz sentido obrigá-lo a converter isso mentalmente em margem antes de começar.
- 01
Um professor pode pensar no que precisa ganhar por matrícula.
- 02
Uma empresa pode trabalhar com uma meta de resultado.
- 03
Quem já conhece o preço aceito pelo mercado pode começar por ele e descobrir se a conta se sustenta.
A interface ficou melhor quando deixou de perguntar como o sistema queria receber a decisão e passou a aceitar como a pessoa já pensava nela.
11 / O SEGUNDO PROBLEMA
A turma pode ser lucrativa. O caixa pode discordar no caminho.
Não é contradição. É calendário.
Parte dos gastos pode acontecer antes. A receita pode chegar depois. Entre uma coisa e outra entram parcelamento, prazo de recebimento, taxas, impostos e inadimplência.
A conta pode fechar no resultado projetado e ainda apertar o caixa em algum momento da operação.
Foi aí que apareceu uma pergunta mais útil do que “qual forma de pagamento é melhor?”: quantas vendas precisam entrar à vista para o caixa atravessar a janela sem ficar negativo?
Uma das regras do produto procura justamente o menor número de vendas à vista capaz de manter o caixa não negativo ao longo da projeção.
alguns acontecem antes da receita
espalha o recebimento no tempo
alteram a curva financeira
pode adiar ou impedir uma entrada prevista
Por isso, formar preço não bastava. O myPRICER passou a projetar também o fluxo de caixa e a economia das formas de pagamento.
12 / UMA REGRA DE GESTÃO
Vendas futuras não consertam o passado.
Uma das regras formalizadas no produto é não usar o replanejamento para “consertar o passado” artificialmente.
O ponto de partida continua sendo a realidade que já aconteceu. O que muda é a decisão sobre o que ainda vem pela frente.
- 01PASSADOAconteceu.
Recebimentos e saídas realizados não são reescritos.
- 02HOJEÉ daqui que a decisão parte.
O replanejamento considera a posição atual do caixa.
- 03FUTUROAinda pode mudar.
A projeção busca não aprofundar o buraco e terminar a janela analisada com caixa não negativo.
Planejamento não serve para reescrever a realidade. Serve para decidir o que ainda pode ser feito a partir dela.
13 / PLANEJADO × REAL
O curso terminou. A projeção, sozinha, já não bastava.
Antes da venda, preço, meta, gastos, lucro e caixa são hipóteses organizadas para decidir melhor.
Depois da venda, existe outra história: matrículas, recebimentos, parcelas, imprevistos e o resultado que de fato aconteceu.
Se eu olhasse apenas para a simulação inicial, o ciclo terminaria justamente antes da parte que poderia dizer se a decisão foi boa.
- Preço
- Meta
- Gastos
- Lucro
- Caixa
- Matrículas
- Recebimentos
- Parcelas
- Imprevistos
- Resultado
Foi por isso que o produto passou a comparar planejado e realizado. A projeção deixou de ser o fim da conta e virou a hipótese que a operação precisava confirmar – ou contrariar.
14 / DO PREÇO À VENDA
Calcular de um lado e vender do outro quebrava o fio da decisão.
Para comparar o que foi planejado com o que realmente aconteceu, não bastava saber o total vendido no fim.
Uma venda não acontece de uma vez. Ela muda de estado.
Era preciso preservar o caminho: para quem a proposta foi feita, o que foi aceito, como seria pago, qual matrícula nasceu dali e quais parcelas deveriam ou não entrar.
- 01PROPOSTA
a condição comercial nasce ligada à decisão original
- 02ACEITE
o que foi combinado deixa de ser apenas intenção
- 03PAGAMENTO
a forma de pagamento altera quando o dinheiro aparece
- 04MATRÍCULA E PARCELAS
o planejado finalmente encontra o que está acontecendo na turma
Não para transformar o myPRICER em uma calculadora. Mas para impedir que a decisão econômica perdesse o contexto no caminho entre preço, venda e resultado real.
15 / O PRODUTO ATUAL
A pergunta continua simples. O produto deixou de ser.
Em 2026, o myPRICER já não cabe na planilha que deu origem a essa história.
Hoje, a mesma decisão atravessa formação de preço, cenários, condições comerciais, caixa, venda, operação da turma e resultado real.
Não porque alguém precise pensar em tudo isso ao mesmo tempo. Justamente o contrário.
gastos fixos, variáveis, impostos e taxas
preço mínimo, margem, lucro e ponto de equilíbrio
mudanças de preço, quantidade de alunos e meta
formas de pagamento e condições comerciais
projeção e acompanhamento do realizado
proposta, aceite, pagamento, alunos, matrículas e parcelas
comparação entre planejado e realizado
No fim, a pessoa ainda quer responder coisas bem menos técnicas: quanto cobrar, quantas pessoas precisam comprar, quanto pode sobrar e o que realmente aconteceu.
16 / O QUE O USUÁRIO NÃO PRECISA VER
Quanto mais coisa existe por baixo, menos disso deveria cair no colo de quem usa.
Para manter a decisão simples, o produto precisa resolver uma série de coisas que não são a decisão do usuário.
Regras, pagamentos, estados, parcelas, caixa, autorização, integrações e segurança continuam existindo. Só não deveriam exigir que quem está precificando uma turma pense como quem construiu o software.
Complexidade de infraestrutura não deve virar complexidade para quem só quer saber se o curso vai dar dinheiro.
17 / SEGURANÇA NÃO É FEATURE DE MARKETING
Eu poderia escrever “segurança de nível bancário”. Ficaria bonito. Também seria uma frase que eu não consigo provar aqui.
Prefiro uma promessa menos vistosa e mais responsável: segurança faz parte da arquitetura, não da vitrine.
Quem usa o myPRICER precisa confiar no produto. Não precisa receber um inventário público de como cada camada é protegida.
Os controles existem para reduzir exposição e proteger o uso cotidiano. Os detalhes ficam onde devem ficar: fora desta página.
Segurança boa não entrega o mapa das fechaduras. Faz o trabalho sem transformar proteção em slogan.
18 / O QUE MUDOU NA MINHA FORMA DE CONSTRUIR
No começo, eu adicionava solução conforme encontrava problema.
Hoje também tento proteger o produto do excesso de solução.
Porque adicionar uma resposta nova é fácil de confundir com progresso. Nem sempre é.
REGRA DE FOCOUm módulo novo só deve entrar quando o anterior estiver funcionando sem chamados relevantes de suporte.
Parece uma regra operacional. Para mim, virou uma regra de foco: funcionalidade acumulada mais rápido que estabilidade pode apenas trocar um problema por outro.
19 / O QUE FOI REVISTO
Nem toda ideia merece permanecer ativa só porque já foi construída.
O myPRICER acumulou hipóteses, caminhos e decisões ao longo da evolução. Alguns seguiram. Outros foram adiados. Alguns precisam ser revistos conforme o produto cresce.
Prefiro deixar essa imperfeição visível no raciocínio do case a contar a história como se cada decisão tivesse nascido certa e definitiva.
quando a hipótese continua fazendo sentido na operação
quando a ideia pode ser boa, mas ainda não é a prioridade
quando uso, suporte ou crescimento mostram que a solução precisa mudar
Produto em produção é produto em negociação permanente com a realidade.
20 / O QUE PASSEI A FAZER DIFERENTE
A planilha não estava errada. Ela resolvia o problema que eu conseguia enxergar.
Com o tempo, passei a separar três perguntas desde o início da modelagem.
Na época, bastava resolver a primeira. As outras apareceram quando preço começou a encontrar venda, caixa e operação – e essa separação passou a orientar a evolução do produto.
- 01CÁLCULOQual é o cálculo?
- 02DECISÃOQue decisão esse cálculo precisa sustentar?
- 03OPERAÇÃOO que acontece depois da decisão?
A primeira planilha resolvia muito bem a primeira pergunta. O produto atual foi construído para manter as três conectadas.
21 / O QUE FICOU
Nem toda planilha precisa virar software.
Algumas deveriam continuar sendo planilhas. Resolvem o problema e fazem exatamente o que precisam fazer.
Outras começam a acumular exceções, repetições e dependências até a ferramenta ficar menor que o problema.
Foi isso que aconteceu aqui.
O myPRICER não começou na primeira tela, no domínio ou na decisão de criar um SaaS. Para mim, começou quando apareceu uma pergunta operacional: quanto isso realmente precisa custar?
E continuou crescendo toda vez que a resposta exigiu uma pergunta melhor.
22 / O QUE O PROJETO PROVA
Quando o código entrou na história, a pergunta já tinha quase vinte anos.
O myPRICER não começou porque eu queria construir um SaaS.
Começou porque uma pergunta continuava voltando: quanto isso realmente precisa custar?
No começo, uma planilha bastava.
Depois, a planilha começou a encontrar a operação.
E operação tem esse hábito inconveniente de trazer casos que a primeira versão não previa.
Então vieram as exceções. Algumas aconteceram uma vez. Outras voltaram.
E, quando uma exceção volta vezes suficientes, talvez ela já não seja mais uma exceção.
Talvez seja uma regra que ainda não ganhou nome.
- 01O PROBLEMA APARECEU
Quanto isso realmente precisa custar?
- 02UMA PLANILHA RESOLVEU
Era suficiente para o problema que eu conseguia enxergar naquele momento.
- 03A PLANILHA ENCONTROU A OPERAÇÃO
Preço começou a encontrar venda, caixa e decisões que vinham depois do cálculo.
- 04AS EXCEÇÕES APARECERAM
Mais variáveis, contextos e dependências começaram a escapar do primeiro modelo.
- 05ALGUMAS EXCEÇÕES SE REPETIRAM
O que voltava deixou de parecer caso isolado e começou a revelar um padrão.
- 06O PADRÃO PRECISOU SER ENTENDIDO
Era preciso separar circunstância do que pertencia ao problema em si.
- 07O PADRÃO VIROU REGRA
A ferramenta deixou de apenas calcular e passou a representar uma lógica de negócio.
- 08SÓ ENTÃO VEIO O PRODUTO
Quando o problema ficou maior que a ferramenta, software passou a fazer sentido.
O software veio por último. Não comecei pelo software. Comecei pela operação.
23 / ONDE ESSA LÓGICA REAPARECEU
Depois que um padrão aparece, fica difícil desver.
O myPRICER não ficou isolado. A mesma lógica começou a aparecer em outros problemas.
O problema deixou de ser apenas entregar conteúdo. Regras educacionais e operacionais começaram a pedir uma plataforma própria.
Fazer sites deixou de parecer uma sequência artesanal de entregas e passou a ser tratado como um processo que podia virar sistema.
Tarefas que se repetiam demais começaram a sair da execução manual e ganhar estrutura.
Os projetos mudam. A pergunta que vem antes da ferramenta continua parecida: isso já se repete o bastante para merecer uma estrutura própria?
24 / O QUE O myPRICER É HOJE
Vender não é o mesmo que ter lucro.
Antes do lançamento, a pergunta é quanto precisa cobrar e vender.
Depois, a pergunta muda: o que aconteceu de verdade?
O myPRICER hoje existe entre essas duas perguntas – planejamento antes da venda e leitura do resultado depois dela.
É a versão atual de uma pergunta que começou muito antes do software.25 / O PRODUTO EXISTE E ESTÁ EM OPERAÇÃO
Até aqui, a pergunta era por que ele existe. Daqui em diante, é o que ele faz.
Esta página contou a história da decisão.
O site do myPRICER entra na parte prática: para quem serve, como funciona e como usar.
27 / O QUE CONTINUA
Tem problema que parece pequeno porque cabe em uma frase.
“Quanto cobrar?” cabia.
A resposta foi ficando grande demais para uma planilha.
Foi assim que uma pergunta virou regra, e a regra virou produto.
O próximo problema pode não terminar em software. E tudo bem.