AutoGestor — O ateliê digital do autônomo

A porta de entrada não é um formulário de cadastro: é uma calculadora aberta na página inicial. Três perguntas — quanto você precisa para viver, quanto gasta para trabalhar e quantas horas quer trabalhar — e o visitante descobre o próprio Valor/Hora Seguro e quanto deixa de cobrar por ano em horas invisíveis. É a ferramenta virando marketing: o produto se apresenta resolvendo um problema antes de pedir qualquer coisa.

A conta parece simples, mas carrega decisões. Ela soma o DAS do MEI aos custos, desconta as horas que ninguém paga (atender, orçar, divulgar) e reserva uma margem de lucro. Para uma designer que precisa de R$ 5.000 para viver, gasta R$ 600 para trabalhar e quer 35 horas por semana, a hora segura sai a R$ 66,95 — e as horas invisíveis somam R$ 36,5 mil por ano que ela não está cobrando.

Tudo isso é cálculo determinístico, no código. Nada de IA para fazer conta: custo zero por uso e o mesmo resultado sempre. Os valores são tratados em centavos e o arredondamento acontece uma vez só, no final, para não acumular erro.

export function valorHoraSeguroExato(entrada: EntradaValorHora): Resultado<number> {
  const horas = horasFaturaveis(entrada); // horas do mês × (1 − horas invisíveis)
  if (!horas.ok) return horas;
  if (entrada.margemSegura + entrada.aliquotaImpostos >= 1) {
    return falha("MARGEM_MAIS_IMPOSTO_ACIMA_DE_100");
  }
  const fatorLiquido = 1 - entrada.margemSegura - entrada.aliquotaImpostos;
  return { ok: true, valor: entrada.custoFixo / (horas.valor * fatorLiquido) };
}

O maior risco de um SaaS para pequenos negócios está nos primeiros minutos: o usuário entra, encontra telas vazias pedindo configuração e vai embora. Por isso o cadastro leva direto a um assistente de três etapas, desenhado para entregar valor em menos de cinco minutos.

A primeira etapa já chega preenchida com os números da calculadora. Na segunda, a profissional escolhe um modelo do seu nicho — aqui, Projeto de Interiores — e o preço sai calculado com a hora dela. Na terceira, a vitrine aparece num preview de celular e é publicada com um clique, com o link pronto para colar na bio do Instagram.

A vitrine é a única parte do sistema aberta ao público, e também a que mais pode receber tráfego: um post que viraliza no Instagram traz milhares de visitas para um usuário que talvez nem pague. Por isso ela é gerada como página estática (ISR do Next.js) e servida pelo cache da Cloudflare. Uma visita não consulta o banco nem gasta servidor; o cache só é renovado quando a profissional muda a vitrine ou um preço.

O cliente escolhe o serviço e pede um orçamento num formulário curto. Esse é o ponto mais exposto a abuso, então tem várias camadas: Cloudflare Turnstile, um campo invisível que só robôs preenchem, limite de cinco pedidos por hora por IP e um teto de tamanho. No banco, o papel público não escreve em tabela nenhuma: ele só pode chamar uma única função, que valida tudo e grava o cliente e o orçamento.

O pedido chega no Kanban da profissional como rascunho, marcado como vindo da vitrine. Ela abre o orçamento, ajusta o que precisar e negocia. Aqui está o diferencial do produto: o sistema guarda o Preço Recomendado de quando o serviço entrou no orçamento e compara com o valor proposto.

Ao dar um desconto para R$ 2.600, aparece na hora: “14% abaixo da Margem Segura”. E, ao mover o card para Enviado, o sistema pergunta se ela quer enviar mesmo assim, mostrando os R$ 412,63 que deixam de cobrir as horas invisíveis. A decisão continua sendo dela — o produto só garante que seja uma decisão consciente.

Para falar com o cliente, um botão abre o WhatsApp com a mensagem do orçamento já escrita, por um link wa.me. Não há integração paga com a Meta: zero custo por mensagem e nenhum risco de bloqueio do número da profissional.

/** Desvio de Margem: fração (−0,15 = 15% abaixo do Preço Recomendado). */
export function desvioDeMargem(entrada: {
  precoProposto: number;
  precoRecomendado: number;
}): Resultado<number> {
  if (!(entrada.precoRecomendado > 0)) return falha("PRECO_RECOMENDADO_ZERADO");
  return {
    ok: true,
    valor: (entrada.precoProposto - entrada.precoRecomendado) / entrada.precoRecomendado,
  };
}

Quando o cliente aprova, o sistema pergunta como ela vai receber: à vista, sinal de 50% e o resto na entrega, ou outra divisão. As parcelas entram em A Receber com o vencimento. A aprovação é reversível — dá para reabrir o orçamento, desde que nenhum recebimento já tenha sido registrado.

O financeiro segue o regime de caixa, e essa foi uma decisão consciente. O lucro do mês conta o dinheiro que entrou, não o orçamento aprovado. Um número que não bate com o extrato do banco destrói a confiança de quem já não sabe se teve lucro; o aprovado e ainda não pago aparece separado, como A Receber.

A aba MEI em dia acompanha o teto anual de faturamento e monta o relatório mensal de receitas brutas exigido do MEI, a partir dos próprios recebimentos. O teto fica numa tabela datada com a fonte legal; como a mudança de valor para 2027 ainda aguardava sanção, um teste passa a falhar se esse valor entrar em vigor sem confirmação na fonte oficial.

• Planos com travas no backend: o gratuito tem até 10 orçamentos por mês e 3 serviços na vitrine; o backend responde 402 e o front só reflete.
• Lead acima da trava nunca é perdido: fica guardado e escondido por uma política de RLS restritiva, e aparece no upgrade ou na virada do mês.
• A projeção de fluxo de caixa dos próximos três meses é um recurso do plano pago — o gratuito vê o histórico.

Cada cliente ganha uma ficha com o histórico de orçamentos, recebimentos, taxa de aprovação e linha do tempo de anotações — e o sistema sugere marcar como VIP quem está entre os melhores. O telefone que aparece ali é guardado cifrado no banco.

A tela de Início responde três perguntas do dia: quanto entrou, quanto falta para cobrir o custo fixo do mês e quem precisa de um contato hoje. O “termômetro do mês” usa o mesmo custo fixo da calculadora, então a meta é a vida real da profissional, não um número genérico.

Todos os profissionais vivem no mesmo banco PostgreSQL, então o isolamento não pode depender de alguém lembrar de filtrar uma consulta. Cada tabela tem Row Level Security forçado — nem o dono da tabela escapa — e o backend só acessa dados dentro de uma transação que informa ao banco qual profissional está logado. Sem esse contexto, a consulta volta vazia: o sistema falha fechado.

Os papéis do banco são separados por função: um para migrações, um para o app, um só para login e um só para a leitura pública da vitrine, nenhum com permissão de ignorar o RLS. Um teste quebra o CI se alguma tabela nova aparecer sem política. Registro de outro profissional responde 404, e não 403, para não confirmar que ele existe.

Dados pessoais dos clientes — CPF, telefone, e-mail, endereço — são cifrados na aplicação com AES-256-GCM, com o identificador da chave guardado junto para permitir rotação. Para buscar um cliente pelo telefone sem decifrar nada, uma coluna ao lado guarda um HMAC do valor normalizado (blind index). Se só o banco vazar, nenhum CPF ou telefone fica exposto.

• Senhas com argon2id; login e sessões com Better Auth, num schema que só o papel de autenticação enxerga.
• LGPD na prática: termos e privacidade, exportação dos próprios dados e exclusão de conta, inclusive no plano gratuito.
• Logs e erros (Sentry) sem dados pessoais, health check que testa o banco e backup cifrado com roteiro de restauração.

ALTER TABLE "clientes" ENABLE ROW LEVEL SECURITY;
-- FORCE: nem o dono da tabela escapa da política.
ALTER TABLE "clientes" FORCE ROW LEVEL SECURITY;

-- USING vale para ler, alterar e excluir; WITH CHECK impede
-- gravar (ou mover) uma linha para outro Profissional.
CREATE POLICY "isolamento" ON "clientes"
  USING ("profissional_id" = app_profissional_id())
  WITH CHECK ("profissional_id" = app_profissional_id());

É um monorepo com pnpm em três pacotes: o front em Next.js 16 com Tailwind e componentes no padrão shadcn; a API em Fastify, a única que acessa o banco; e um pacote compartilhado só com regras de negócio puras — precificação, planos, teto do MEI, mensagens de WhatsApp —, usado pelos dois lados e coberto por centenas de testes.

A infraestrutura foi desenhada para um ticket baixo: tudo roda em Docker numa VPS de custo fixo, orquestrada pelo Dokploy, com a vitrine servida pelo cache da Cloudflare. O app também funciona como PWA, para quem trabalha na rua pelo celular. O trabalho foi organizado em issues e pull requests pequenos, e as decisões que mudam a arquitetura viraram ADRs.

Três frentes estão no roteiro. Um servidor MCP (Model Context Protocol), para que assistentes de IA consultem e operem o AutoGestor em nome da profissional — lançar uma despesa, ver o que falta receber —, com as mesmas regras de acesso do app. Um chatbot no WhatsApp, para quem vive no celular resolver o dia a dia sem abrir o painel. E pagamentos integrados com split, para o cliente pagar o sinal direto pela vitrine e o card andar sozinho no Kanban.

Nos três casos vale a mesma regra que guiou o produto até aqui: a IA entra onde ajuda a conversar, nunca onde a conta precisa ser exata — e cada nova peça tem que caber no custo de uma assinatura de baixo valor.