Do MVP ao produto: como validar um SaaS sem queimar o orçamento

A primeira versão precisa de uma única funcionalidade que resolva um problema pelo qual alguém já paga hoje, mesmo que de forma manual. Cobrança, painel administrativo e integrações podem ser feitos na unha nos primeiros meses. Autenticação e backup, não.

O padrão se repete com uma regularidade impressionante: seis meses construindo, lançamento, e a descoberta de que a funcionalidade que consumiu metade do tempo não é usada por ninguém, enquanto a coisa que os clientes realmente queriam nem estava na lista.

O corte que quase ninguém tem coragem de fazer

Liste tudo que o produto deveria ter. Agora escolha uma funcionalidade, aquela que, se fosse a única coisa existente, ainda faria alguém pagar. Esse é o lançamento. Todo o resto é lista de espera.

A resistência é sempre a mesma: “mas sem relatório ninguém vai usar”. Talvez. Só que isso é uma hipótese, e ela custa seis semanas para ser testada construindo, ou uma conversa para ser testada perguntando.

O que dá para fazer manualmente no começo

• Cadastro de clientes. Nos primeiros vinte clientes, criar a conta na mão dá meia hora de trabalho por semana. E rende uma conversa com cada cliente novo, que vale mais do que o tempo economizado.
• Cobrança. Link de pagamento gerado manualmente resolve. Assinatura recorrente automática pode esperar até você ter cliente recorrente.
• Relatórios. Consulta no banco e planilha enviada por e-mail. Se ninguém reclamar da demora, o relatório não era prioridade.
• Painel administrativo. Nos primeiros meses, o painel é o próprio banco de dados.

O que nunca se corta

• Autenticação feita direito. Vazamento de dados de vinte clientes mata o produto antes do primeiro ano.
• Backup restaurado. Perder os dados dos primeiros clientes é o fim, e eles são justamente os que ainda estavam decidindo se confiavam em você.
• Separação entre clientes. Um cliente ver o dado do outro é o pior erro possível em SaaS. Se o produto é multiempresa, o isolamento é estrutural e precisa estar certo desde a primeira linha.
• Registro de eventos. Você precisa saber o que os usuários fazem, ou vai priorizar por opinião.

Multiempresa é a decisão que não dá para adiar

Se cada cliente tem seus próprios usuários e dados isolados, essa decisão precisa ser tomada antes da primeira tabela. Adaptar depois é praticamente uma reescrita, porque todas as consultas do sistema mudam.

Para a grande maioria dos casos, um banco único com identificador de empresa em cada tabela e filtro obrigatório em toda consulta resolve bem, sai barato e escala longe. Bancos separados por cliente só compensam quando existe exigência regulatória ou clientes muito grandes pagando por isolamento físico.

Cobre desde o primeiro cliente

Produto gratuito não valida nada. Gente adora coisa de graça e usa uma vez. O sinal que importa é o segundo pagamento, porque ele significa que o valor apareceu de verdade.

Se o preço ainda é incerto, cobre um valor claramente baixo e diga que é preço de primeiros clientes. Isso preserva a possibilidade de ajustar depois e já produz a informação que você precisa: alguém tira o cartão do bolso por isso?

Os números que dizem se está funcionando

Nos primeiros meses, três informações bastam.

Ativação: de quem se cadastra, quantos chegam a usar a funcionalidade principal pelo menos uma vez? Se for menos da metade, o problema está na primeira experiência, não no produto.

Retorno na segunda semana: quantos voltam sem serem lembrados? Esse número prevê o futuro melhor do que qualquer entrevista.

Cancelamento com motivo: toda saída merece uma pergunta. As respostas que se repetem são a sua lista de prioridades, já ordenada de graça.

Painel bonito com vinte indicadores no primeiro mês é distração. Esses três decidem se o produto continua.

Converse com quem usa, de verdade

Com vinte clientes dá para falar com todos. Não por formulário, por conversa. As frases que aparecem em três clientes diferentes são a próxima entrega. As que aparecem em um só entram na lista e esperam.

Esse é o único mecanismo confiável para não construir a funcionalidade cara que ninguém pediu. E ele custa algumas horas por semana, não seis semanas de desenvolvimento.