O preço que paga a hora do dono, calculado sem conta

A confeiteira que vira a madrugada com encomendas e o artesão da impressão 3D com a fila cheia chegam ao fim do mês com o mesmo problema: sabem exatamente quanto venderam e não fazem ideia de quanto sobrou. O preço nasceu olhando o da concorrente, o dinheiro da casa mora na mesma conta da empresa, e a resposta para "valeu a pena?" é uma sensação, não um número.

A restrição que herdamos desse cenário é de entrada de dados, não de cálculo. Perguntar "quanto de custo fixo cabe em cada unidade?" para quem nunca fez rateio devolve um chute que contamina tudo o que vem depois, e sistema alimentado por chute produz relatório bonito com decisão errada dentro. Por isso o princípio de interface do produto é uma proibição, e não uma boa intenção: nunca pedir ao empreendedor uma informação que ele provavelmente não sabe responder.

O que a Lucrei pede são os custos fixos do mês e as unidades vendidas no mês, duas coisas que qualquer dono responde de cabeça, e deriva o rateio dividindo um pelo outro. O mesmo vale para a perda de produção, que chega preenchida com a média do tipo de fabricação (8% para filamento 3D, 15% para resina, 3% para corte a laser) e continua editável para quem conhece a própria bancada melhor que a média do mercado.

A restrição veio antes da solução: pedir faturamento a quem ainda não confia no produto é pedir cedo demais, e uma calculadora que só revela o resultado depois do cadastro é captura de contato fantasiada de ferramenta. Decidimos o contrário: o visitante vê o próprio número primeiro e decide depois se quer uma conta.

A calculadora que abre a home da Lucrei é um componente de cliente sem nenhuma chamada de rede: nenhum fetch, nenhum estado no servidor, nada gravado. São 8 campos na tela, material por unidade, tempo de produção, quanto vale a sua hora, perda, custos fixos do mês, unidades do mês, preço praticado e taxa do canal de venda: mais 4 sob "avançado", para energia e depreciação de equipamento, que só entram na conta se forem preenchidos.

As metas de negócio são quatro botões em vez de um campo de percentual: Sobrevivência com 10%, Crescimento com 20%, Expansão com 30% e Premium com 40% de margem líquida, porque quem vende artesanato entende objetivo melhor que abstração. O resultado sai com o custo por unidade, o lucro por hora de trabalho e um veredito de quatro estados: abaixo do equilíbrio, abaixo da meta, no alvo ou acima do sugerido.

Um detalhe que só aparece quando se testa com gente de verdade: os campos não usam o tipo numérico do HTML. O navegador trata "39,90" como valor inválido e devolve string vazia, então o campo apaga sozinho enquanto a pessoa digita. Trocamos por campo de texto com teclado decimal e o mesmo interpretador de números em português que o importador de planilhas do produto usa, que já entende tanto "1.234,56" quanto "1234.56".

A restrição aqui é de confiança: num produto que afirma quanto você lucrou, basta o painel e a tela de preço divergirem uma única vez para o número inteiro virar suspeito. É uma falha barata de introduzir: alguém reimplementa uma fórmula numa tela nova porque foi mais rápido que importar a existente, e cara de descobrir, porque quem descobre é o usuário.

Todo indicador de negócio nasce de um hub único de métricas, e a lógica de cálculo vive em módulos puros, sem banco e sem entrada e saída, com o arquivo de teste ao lado de cada um. O acesso a dados fica num invólucro fino por cima. Uma regra de arquitetura roda no CI e reprova a entrega quando alguém refaz a conta por fora, o que transforma a fonte única de verdade em mecanismo e não em combinado verbal.

É essa disciplina que deixa a calculadora pública ser honesta: ela importa exatamente as funções que rodam dentro do produto, custo unitário efetivo, custo de mão de obra, energia, depreciação por unidade, margem por meta e lucro por hora. Se a fórmula mudar lá dentro, a página muda junto, porque não existe uma segunda cópia para alguém esquecer de atualizar. Hoje são 1.642 testes automáticos em 130 arquivos guardando esse contrato.

Multi-tenant por linha é a arquitetura mais econômica de operar e a mais fácil de furar: basta uma consulta que confie no identificador que veio da tela. A restrição que assumimos foi tirar essa decisão das mãos de quem escreve a consulta, porque atenção humana não escala para todas as telas de um produto que só cresce.

Toda consulta ao banco é escopada pelo identificador da empresa derivado da sessão validada criptograficamente, nunca do que o usuário digitou ou do que veio na URL. Quando a assinatura vence, o sistema entra em modo somente leitura: nada é apagado e nada é escrito, mas tudo continua consultável, a saída de um cliente não pode se parecer com perda de dados.

A política de segurança de conteúdo é emitida a cada requisição com um nonce próprio, e não como cabeçalho estático: em produção o navegador só executa o script que aquele carregamento específico assinou. E a trilha de tentativas de login vive numa tabela separada da auditoria administrativa, com o e-mail guardado apenas como hash: uma rajada de tentativas não afoga a trilha que o operador precisa ler, e um vazamento do log não entrega endereço de ninguém.

A armadilha número um deste produto tem nome e sobrenome: coluna que falta. O banco é SQLite hospedado na Turso, acessado por Prisma através do adaptador libsql, e o Prisma nunca faz seleção genérica: ele enumera as colunas do schema em cada consulta. Se o código sobe antes da migração, a primeira consulta do fluxo de autenticação pede uma coluna que ainda não existe e o login inteiro cai, para todo mundo, de uma vez.

A regra que adotamos é que toda migração seja aditiva e segura para o login: adicionar coluna anulável, criar tabela, nunca remover, renomear ou impor obrigatoriedade sem valor padrão. São 56 migrações no repositório sob essa disciplina, e um teste no CI reprova a entrega quando uma migração nova contém remoção, renomeação, alteração de coluna ou campo obrigatório sem default.

O aplicador de produção registra cada migração já executada numa tabela de controle com checksum, então rodar duas vezes não faz nada: idempotência é propriedade do runner, não sorte do operador. E uma renomeação de identificadores de plano, que seria porta de mão única, ficou deliberadamente fora da pasta de migrações: aplicá-la transformaria qualquer rollback do código num rebaixamento silencioso de plano, e o custo de segurá-la é zero porque um apelido no código já entrega o vocabulário novo na tela.

A Lucrei é whitelabel de nascença: cores, logo e nome trocam por configuração, e a mesma base vira o produto de outro operador com a cara dele. Isso obriga o sistema a servir dois clientes ao mesmo tempo: o empreendedor que registra a venda do dia e o operador que revende a plataforma e precisa de painel de dono, com receita recorrente, funil de clientes e trilha de auditoria de tudo o que acontece.

Para o empreendedor, a tela de abertura resume em vez de despejar: 7 fatores de saúde do negócio são condensados em 5 pilares clicáveis (Finanças, Vendas, Estoque, Produção e Crescimento) que viram uma nota de 0 a 100 e uma frase que nomeia o pilar mais fraco. Os micro-gráficos são SVG escrito à mão em vez de biblioteca de gráficos, decisão que mantém essa página em torno de 158 kB contra os cerca de 269 kB das telas que carregam Recharts.

O plano de crescimento pega o capital já investido e devolve a meta do dia, com um controle de prazo que desliza de 3 a 36 meses e recalcula no navegador enquanto a pessoa arrasta. E a central fiscal monitora o teto anual do MEI, hoje R$ 81.000, com farol de obrigações e calendário de datas, porque estourar o teto sem perceber não é um susto contábil, é a perda do enquadramento.