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.
A DCODER constrói SaaS do primeiro lançamento à operação, com arquitetura multiempresa pensada desde o início. Fale com o estúdio em dcoder.io.