Estudo de viabilidade: os cinco testes, e como rodá-los em um dia

O que um estudo de viabilidade realmente decide

Um estudo de viabilidade é uma avaliação estruturada anterior ao compromisso que testa se um empreendimento proposto é tecnicamente construível, economicamente viável, legalmente permitido, operacionalmente sustentável em pessoal e planejável — produzindo uma decisão de seguir, revisar ou parar antes de comprometer capital.

As palavras que fazem o trabalho são anterior ao compromisso. Tudo para o que um estudo de viabilidade serve acontece antes de o dinheiro se mover. Feito depois, a mesma análise vira um exercício de justificação, porque quem a conduz agora tem uma posição a defender.

Essa é também a diferença para um plano de negócios. Um plano de negócios assume que o empreendimento deve existir e descreve como vai funcionar. Um estudo de viabilidade tem permissão — na verdade, obrigação — de concluir que não deveria. Um estudo que não consegue produzir um "parar" não é um estudo.

Os cinco testes

O arcabouço padrão é TELOS: Technical, Economic, Legal, Operational, Scheduling. Cinco testes independentes, e o sentido da estrutura é que qualquer um deles desqualifica. Um empreendimento que pontua brilhantemente em quatro e falha o quinto não é viável em quatro quintos. Ele é inviável.

1. Técnico — dá para construir?

Não "é teoricamente possível". Se dá para construir com as pessoas que você de fato terá, com tecnologia que existe hoje, numa qualidade que o mercado aceitará.

A versão honesta desse teste pergunta três coisas. Qual é o componente mais difícil, e alguém já entregou isso? De que o sistema depende que você não controla — uma API, uma fonte de dados, um provedor de modelo, uma licença? E o que acontece com o produto quando essa dependência muda os termos?

A última pergunta é onde a maioria dos estudos de viabilidade de software é rasa. Um produto construído sobre a plataforma de outro herda as decisões de preço e o calendário de descontinuação dela.

2. Econômico — a aritmética fecha?

É o teste que mata mais empreendimentos, e o mais frequentemente substituído por uma planilha que cresce 20% ao mês porque a célula de cima crescia.

No mínimo você precisa de três números e da relação entre eles: quanto custa adquirir um cliente, quanto um cliente vale ao longo da vida e quanto tempo leva o payback. Dois pisos muito usados:

• LTV/CAC de 3.0 é a definição comum de saudável. Em torno de 1.5 é o ponto abaixo do qual o payback se torna aritmeticamente impossível uma vez contabilizados churn e margem.
• Payback de CAC de 18 meses é o referencial padrão de estágio inicial. Passados uns 36 meses, o modelo deixou de ser um negócio.

Não são leis. São os limiares que a maioria dos investidores vai aplicar a você, o que os torna os limiares que vale testar antes que outra pessoa o faça.

A metade de tamanho de mercado do teste econômico tem o próprio modo de falha. Um único relatório de analista não é evidência; é uma estimativa com data de publicação e uma metodologia que você não vê. Combinar várias é melhor, mas só se a divergência for tratada com honestidade — descartando outliers escandalosos e tratando um conjunto de estimativas publicadas com anos de diferença como desatualizado em vez de tirar média sobre um mercado que mudou. A implementação da INITE Studio descarta o que está a mais de 3σ da mediana a partir de quatro fontes, e sinaliza um conjunto cujos anos de publicação abrangem mais de cinco.

3. Legal — é permitido?

O teste mais barato de pular e o mais caro de falhar, porque um problema jurídico descoberto depois do lançamento raramente se conserta por iteração.

Três perguntas. A atividade em si é licenciada ou restrita nos seus mercados-alvo? Que dados você vai guardar, e que regime os governa? E a propriedade intelectual de quem o produto toca — dados de treinamento, conteúdo raspado, um processo protegido de um concorrente?

Para qualquer coisa que toque saúde, dinheiro, emprego, crianças ou dados pessoais, esse teste vai para o início da fila. Nesses domínios a resposta regulatória determina o desenho do produto, e não o contrário.

4. Operacional — você consegue tocar isso?

Um produto que funciona numa demo e não pode ser operado é inviável. Esse teste pergunta quem faz o trabalho depois que a coisa existe: suporte, moderação, fraude, onboarding, o acúmulo lento de casos de borda.

A armadilha específica de produtos de IA é que a demo é autônoma e o sistema em produção não é. Se todo caso ambíguo precisa de um humano, o custo operacional por cliente é uma linha de pessoal, não de computação — e escala linearmente com os clientes, que é o formato de um negócio de serviços vestindo as margens de um de software.

5. Cronograma — o prazo sobrevive às dependências?

O mais fraco dos cinco como normalmente praticado, porque costuma ser respondido com um gráfico de Gantt desenhado de trás para frente a partir de uma data desejada.

A versão útil pergunta qual é a cadeia genuinamente serial mais longa do projeto — as coisas que não podem ser paralelizadas por mais gente que você acrescente. Aprovação regulatória, prazo de entrega de hardware, integração com parceiro, ciclo sazonal de vendas. E depois pergunta o que acontece com o teste econômico se essa cadeia esticar 50%, porque geralmente estica.

Onde o modelo clássico falha com software

Os cinco testes foram formalizados para projetos de capital — plantas, pontes, aquisição de sistemas. Duas das premissas não se transferem.

O estudo não é um portão único. Num projeto de capital a viabilidade é avaliada uma vez porque o compromisso é irreversível. Compromissos de software são escalonados, o que significa que a viabilidade deveria ser reavaliada a cada estágio — e os pesos deveriam mudar. Se o time consegue construir importa muito mais quando já existe produto do que quando havia só uma ideia.

Por isso a auditoria da INITE Studio pondera suas lentes por estágio em vez de aplicar uma fórmula fixa. No estágio de ideia, o encaixe problema-solução carrega 35% do peso e a tração carrega 5% — porque não há tração para medir, e fingir o contrário só acrescenta ruído. Em estágios posteriores a distribuição se move para a evidência que já existe.

O resultado costuma ser um número, e um número não é uma decisão. A maioria dos modelos termina numa nota ou classificação. Uma nota sem limiar é uma opinião com casa decimal.

A correção é escrever as condições de falha antes de reunir evidência: a métrica específica, o valor específico e a data até a qual precisa ser verdade. Comprometer-se com essas condições de antemão é o que torna a eventual parada uma decisão em vez de uma discussão, porque quem tem que aceitá-la já concordou com as regras.

Pela mesma razão vale ser explícito sobre o que um resultado positivo exige. A auditoria da INITE Studio só devolve GO quando quatro condições valem juntas: nota composta de pelo menos 80, zero bandeiras vermelhas, confiança média entre lentes de pelo menos 0,6 e nenhuma contradição não resolvida entre lentes. Faltando uma, o veredito é REFINE ou KILL — não porque a ideia seja ruim, mas porque ainda não há resposta confiante disponível.

O que não é: quatro artefatos vizinhos

Metade da confusão sobre estudos de viabilidade vem de quatro documentos que se sobrepõem a eles e respondem perguntas diferentes.

Os dois mais frequentemente substituídos são o plano de negócios e a prova de conceito, e as duas substituições são caras do mesmo jeito: respondem uma pergunta mais estreita e são tratadas como se tivessem respondido a ampla. Um protótipo funcionando prova o teste técnico e não diz nada sobre o econômico, o legal ou o operacional. Um plano polido prova que alguém sabe escrever.

Quem conduz, e o conflito que ninguém nomeia

Um estudo de viabilidade normalmente é encomendado por quem quer que o projeto aconteça. Isso é um conflito estrutural, e é a razão de tantos estudos concluírem que o projeto é viável.

Três defesas práticas.

Escreva as condições de parada antes de reunir evidência. Depois de conhecer os números, você vai escolher limiares que os números já passam. Vinte minutos gastos primeiro nos limiares são o controle de viés mais barato disponível.

Dê uma dimensão a alguém que não quer o projeto. Os testes legal e operacional são os dois mais frequentemente aprovados sem exame, e são os dois em que um leitor sem motivação acrescenta mais.

Registre o que mudaria a resposta. Um estudo que diz "seguir" sem declarar que evidência o viraria para "parar" não foi falseável em momento algum, o que significa que nunca foi um teste.

Os padrões de falha

Seis que se repetem, e como cada um aparece de fora:

O quarto merece uma nota, porque é o que mais se parece com trabalho. Um único número de mercado publicado é uma estimativa com metodologia que você não pode inspecionar. Dois números que discordam informam mais que um que não discorda, e um conjunto publicado com anos de diferença descreve vários mercados diferentes em vez de um.

Um exemplo trabalhado

Um time quer construir uma ferramenta de relatórios de compliance para clínicas em três países europeus. Rode os cinco testes na ordem que pode encerrar o estudo mais cedo.

Legal, primeiro, porque o domínio é regulado. Dados de pacientes no escopo significa GDPR mais regras nacionais de dados de saúde que diferem nos três países-alvo. A constatação não é "isso é ilegal" — é que o produto precisa de uma história de residência de dados por país, e isso muda a arquitetura. Custo de descobrir agora: uma tarde. Custo de descobrir depois de construir: a arquitetura.

Econômico, segundo. Digamos cerca de 9.000 clínicas do tamanho certo nos três mercados, um ACV plausível de € 4.000, e uma venda que precisa de uma pessoa no processo. Isso é um SAM perto de € 36 milhões e um CAC que não tem formato de autoatendimento. A € 4.000 de ACV e 70% de margem bruta, o lucro bruto mensal por cliente é cerca de € 233, então um payback de 18 meses permite um CAC de uns € 4.200 completos — que uma venda de campo vai ultrapassar com folga, e uma venda interna talvez consiga cumprir. O teste não falha: ele diz que a restrição é o canal, e o canal agora precisa ser provado, não presumido.

Técnico e operacional juntos. A lógica de relatórios é tratável. A pergunta operacional é quem resolve registros ambíguos — e num produto de compliance, um registro ambíguo não pode ser resolvido automaticamente. Isso é uma fila de revisão humana, que é uma linha de pessoal que escala com os clientes.

Cronograma por último. A cadeia serial é o trabalho de residência de dados por país mais pelo menos um cliente de referência por mercado antes de o segundo assinar. Rode o teste econômico de novo com essa cadeia 50% mais longa e veja se o plano de financiamento ainda fecha.

O veredito aqui não é seguir nem parar. É revisar: o produto é viável com uma venda interna e um modelo de custo com fila de revisão, e inviável com as premissas de autoatendimento com que o time começou. Esse é o desfecho útil mais comum, e um estudo que só sabe dizer sim ou não não consegue produzi-lo.

Rodando em um dia

Para um produto de software, a sequência que funciona:

1. Escreva as condições de parada primeiro. Antes de qualquer evidência. De três a cinco, cada uma com métrica, limiar e data. Leva vinte minutos e determina se o resto é honesto.
2. Teste legal primeiro se o domínio é regulado. Ele pode encerrar o estudo, e é o único teste que não se resolve construindo de outro jeito.
3. Teste econômico em segundo. LTV/CAC, payback e um tamanho de mercado montado de várias fontes com a divergência deixada à vista em vez de mediada.
4. Técnico e operacional juntos. Eles interagem: o atalho técnico normalmente aparece como custo operacional.
5. Cronograma por último, contra a cadeia serial, e então rode de novo o teste econômico com o prazo 50% mais longo.
6. Escreva a decisão, não a nota. Seguir, revisar ou parar, e a evidência específica que mudaria isso.

O último passo é o que cai fora, e é o objetivo inteiro. Um estudo de viabilidade existe para tornar uma decisão barata de reverter e cara de maquiar.