Como validar uma ideia de SaaS antes de construir

Construir um SaaS por empolgação com a stack tecnológica é um jeito caro e demorado de descobrir que ninguém tinha a dor que o produto resolve. Validar uma ideia não exige ciência teatral, pesquisa de mercado de consultoria ou meses de planejamento — exige conversa direta com quem pagaria e um recorte mínimo capaz de ensinar algo real sobre comportamento, não sobre opinião.

A hipótese em uma frase

Antes de qualquer linha de código, escreva a hipótese central do produto numa única frase: "[Público específico] tem o problema [X] e hoje resolve com [Y], que falha porque [Z]."

Se essa frase não sai com clareza — se o público é vago demais, o problema é genérico demais, ou a alternativa atual não tem uma falha específica e nomeável — ainda não existe um produto ali. Existe uma vibe, uma intuição interessante que ainda não foi transformada em algo testável.

Entrevistas sem questionário de teatro

O erro mais comum na validação é conversar com as pessoas erradas, da forma errada. Fale com quem já sofre a dor hoje, na prática — não com quem acha a ideia interessante em abstrato. Pergunte o que a pessoa fez ontem para lidar com o problema, não o que ela "compraria" hipoteticamente — respostas sobre comportamento passado são muito mais confiáveis do que previsões sobre intenção futura.

Preste atenção especial ao workaround que a pessoa já usa: planilha remendada, processo manual, um estagiário dedicado a resolver isso, mensagens de WhatsApp organizando o que deveria estar num sistema. Um workaround forte e trabalhoso é sinal real de dor — ninguém monta uma gambiarra elaborada para um problema que não incomoda de verdade. Um elogio educado à sua ideia, sem nenhum workaround por trás, é fumaça.

Waitlist e pré-venda, com honestidade sobre o que cada uma prova

Uma lista de e-mails de interessados prova curiosidade — é um sinal fraco, fácil de conseguir e fácil de superestimar. Um depósito, mesmo pequeno, ou uma carta de intenção assinada prova prioridade real: a pessoa está disposta a comprometer algo de valor (dinheiro, tempo, reputação) antes do produto existir. Misturar os dois sinais no discurso para investidor ou para si mesmo — tratar "500 e-mails na lista" como se fosse "500 clientes validados" — é o tipo de autoengano que sustenta produtos que nunca deveriam ter sido construídos.

MVP de aprendizado não é MVP de vaidade

Um MVP de vaidade tem telas bonitas, roda uma demonstração impecável, e tem zero uso real por alguém fora do time que o construiu. Um MVP de aprendizado é mais feio, mais restrito no escopo, mas permite que uma pessoa real complete a tarefa crítica do produto — mesmo com arestas visíveis, mesmo sem polimento. É o critério certo de recorte, detalhado em MVP em oito semanas: o que entra, o que fica de fora.

O que observar, sem inventar estatística que soa científica

Sem amostra grande o suficiente para significância estatística de verdade, os sinais qualitativos que realmente importam são:

• As pessoas voltam a usar o produto sem você precisar cobrar ou lembrar?
• Elas pedem a próxima funcionalidade dentro do fluxo crítico que já existe, ou só sugerem coisas genéricas do tipo "ficaria legal se tivesse..."?
• Elas aceitam pagar de alguma forma concreta — tempo dedicado a testar, dinheiro, ou fornecer dados reais para o teste — em vez de só elogiar a ideia de longe?

Multi-tenant e tabela de preço sofisticada vêm depois da dor confirmada

Arquitetura multi-tenant bem desenhada e uma tabela de preços com múltiplos planos são investimentos prematuros se a tarefa principal do produto ainda não foi genuinamente amada por quem testou. Resolver esses dois problemas cedo demais é otimizar uma estrutura para um produto que ainda pode nem sobreviver à validação.

Quando parar

Se, depois de conversas honestas com pessoas reais do público-alvo, a dor não aparece com frequência suficiente nem com intensidade suficiente, o caminho certo é arquivar a ideia — não insistir mais um mês, não pivotar sem critério, arquivar. Matar uma ideia cedo, com base em evidência real, é competência, não fracasso.

Próximo passo

Escreva a hipótese numa frase, liste dez pessoas reais para entrevistar de verdade, e só depois disso desenhe a primeira tela. Se você quiser um parceiro tanto para esse discovery inicial quanto para a construção que vem depois: fale com a Auryx.