O que aprendi levando um SaaS de 0 a 1M de ARR
Nos últimos anos eu participei da construção de um SaaS do zero — do primeiro frame no Figma até o dia em que a receita anual recorrente cruzou sete dígitos. Não foi uma linha reta. Foi uma sequência de decisões, algumas boas de primeira, outras corrigidas às pressas em produção.
Este artigo é o resumo do que eu levaria comigo para qualquer produto novo.
1. Percepção de valor é o produto
O usuário não compra arquitetura. Ele não vê o Redis, as filas, os retries com backoff. Ele vê a tela carregar rápido, a mensagem chegar, o relatório fazer sentido. A engenharia existe para sustentar uma experiência — e a experiência é o que se compra.
Na prática, isso mudou a ordem das minhas decisões: primeiro a jornada no Figma, depois o contrato da API, por último a implementação. Quando a ordem inverte, o produto vira um espelho do banco de dados — e ninguém paga por isso.
2. Escala se decide no dia um
Tem uma ideia romântica de que escala é um problema bom para o futuro. O problema: as decisões que definem se você vai escalar sem reescrever são tomadas nas primeiras semanas — multi-tenancy, mensageria assíncrona, idempotência nos webhooks.
Nada disso custa caro no início. Todas custam uma reescrita se ficarem para depois.
3. Mensagem perdida é cliente perdido
Num produto de atendimento, o pior bug não é o que quebra a tela — é o que perde um evento em silêncio. Um webhook do WhatsApp que não foi processado é uma conversa que não aconteceu e uma venda que não fechou.
Concorrência aqui não é otimização, é correção: ordem garantida por conversa, paralelismo entre conversas, fila com reprocessamento. O sistema pode ficar lento por um minuto; não pode perder uma mensagem nunca.
4. Observabilidade compra sono
Todo sistema quebra. A diferença entre um incidente de cinco minutos e uma madrugada perdida é saber onde quebrou antes do cliente sentir.
Métricas, logs estruturados e alertas não são infraestrutura de luxo — são a diferença entre operar um produto e ser refém dele. O melhor elogio que um sistema em produção pode receber é ninguém falar dele.
5. Produto e engenharia precisam da mesma cabeça
Atuar como PO e dev ao mesmo tempo me ensinou que a fricção clássica entre "o que o negócio quer" e "o que dá para construir" é, na maioria das vezes, falta de contexto compartilhado.
Quando a mesma pessoa (ou o mesmo time, de verdade) entende o funil de vendas e o custo da fila, as decisões mudam: features nascem menores, mais afiadas e com um caminho claro até o valor. O ticket deixa de ser um pedido e vira uma hipótese.
6. 1M de ARR não é linha de chegada
Sete dígitos de receita recorrente parecem um final de filme, mas na prática são um checkpoint: a base de clientes cresce, o volume dobra, e as decisões do dia um são testadas de novo — em escala maior.
O que fica é o método: desenhar antes de codar, decidir escala cedo, tratar cada evento como dinheiro, medir tudo, e nunca esquecer que do outro lado da tela existe uma pessoa decidindo se aquilo vale o que custa.
Se você está construindo um produto e quer trocar ideia sobre qualquer um desses pontos, me chama no LinkedIn.