O que decidir antes de construir um MVP

Um MVP não é uma versão reduzida de cada ideia do seu roteiro. É o produto útil mais pequeno que permite a um grupo definido de pessoas completar um fluxo de trabalho importante e dá à equipa evidência para a decisão seguinte.

Nessa palavra — evidência — vale a pena parar.

A análise da CB Insights sobre porque falham as startups (abre num novo separador), publicada em março de 2026, examinou 431 empresas financiadas por capital de risco que encerraram publicamente desde 2023. Encontrou falta de capital em 70 % dos casos e má adequação produto-mercado em 43 %.

A sua observação mais útil é sobre quando ocorrem as falhas de adequação: «dois terços das falhas de adequação produto-mercado foram empresas em fase inicial que nunca encontraram mercado».

O dinheiro é como aquilo acaba. Não aprender depressa o suficiente é muitas vezes o porquê. O mesmo princípio vale para uma ferramenta interna de negócio: a sua primeira versão deve provar que um fluxo de trabalho importante funciona melhor.

Por isso a primeira versão não é uma demonstração da sua ambição. É um instrumento para descobrir alguma coisa. As decisões seguintes determinam se consegue fazê-lo.

O que um MVP não é

Três leituras erradas causam quase todos os danos, e vale a pena nomeá-las antes de o planeamento começar:

• Uma versão mais barata do produto completo. Baixar a qualidade em todo o lado deixa-o com algo que ninguém consegue julgar. Corte antes o âmbito, e construa bem o que sobrar.
• Um protótipo. Um protótipo responde a uma pergunta de design e depois é descartado. Um MVP é software real com utilizadores reais, e tem de ser sustentável.
• Uma arquitetura definitiva. A primeira versão deve poder mudar. Decisões caras de reverter merecem mais reflexão do que as que não são.

A pergunta útil não é «qual é o mínimo que conseguimos construir?». É «qual é o mínimo que conseguimos construir que ainda assim nos ensine algo sobre o qual agiríamos?».

Deve mesmo construir à medida?

Antes de definir o âmbito de uma construção à medida, vale a pena perguntar se já precisa dela.

O software à medida é a resposta certa quando o seu fluxo de trabalho é genuinamente específico, quando precisa de ser dono do resultado, ou quando as ferramentas de prateleira não conseguem ligar-se ao modo como o seu negócio funciona.

É muitas vezes a primeira resposta errada quando uma ferramenta no-code, uma folha de cálculo ou um produto existente lhe permitiriam testar a mesma hipótese esta semana.

Uma sequência útil é validar a procura com a coisa mais barata que funcione e só depois construir à medida quando souber que partes precisam mesmo disso.

Muitos produtos bem-sucedidos começam como um processo manual ou um conjunto de ferramentas montado. Só se tornam software à medida onde essa montagem começa a doer.

Construir à medida cedo de mais gasta o seu orçamento a provar algo que um teste muito mais barato lhe poderia ter dito. Fazê-lo tarde de mais deixa-o a lutar com ferramentas que já não servem.

Responda a isso com honestidade antes de começar a definir o âmbito, não depois.

Comece pelo fluxo de trabalho do utilizador

Antes de falar de tecnologia, descreva quem vai usar o produto, em que situação está e que tarefa precisa de terminar. Se isso ficar vago, o vago acompanha-o em cada ecrã e em cada funcionalidade.

Escreva o fluxo principal como uma sequência curta. Por exemplo: um cliente submete um pedido, alguém da equipa revê-o, o sistema regista a decisão, e ambos os lados veem o passo seguinte.

O Government Digital Service britânico formaliza isto como uma fase de descoberta. O seu manual de serviços (abre num novo separador) é direto quanto à ordem: «antes de se comprometer a construir um serviço, precisa de perceber o problema que tem de ser resolvido».

Sugere cerca de quatro a oito semanas como duração típica dessa descoberta, terminando numa decisão explícita sobre se existe sequer um serviço viável.

Uma investigação curta e delimitada com um verdadeiro go/no-go é mais barata do que uma construção que descobre o mesmo ao quinto mês.

Defina o que pertence ao âmbito

Depois separe o trabalho indispensável do trabalho útil mais tarde. Autenticação, permissões, pagamentos, notificações, relatórios, integrações e ferramentas de administração podem importar todos, mas a primeira versão não precisa de todos ao mesmo nível.

Um bom âmbito tem uma razão para cada funcionalidade. Mantenha uma funcionalidade na primeira versão quando passa pelo menos um destes testes:

1. o primeiro utilizador não consegue completar o fluxo principal sem ela
2. reduz um risco de entrega que já identificou
3. dá à equipa o controlo de que precisa desde o primeiro dia
4. deixá-la de fora obrigaria a reescrever em vez de acrescentar

Se uma funcionalidade não passa nenhum deles, é uma decisão posterior e não um corte. Registá-la assim costuma desarmar a discussão sobre removê-la.

Decida como vai saber que resultou

Antes de a construção começar, acordem que resultado justificaria continuar, mudar de direção ou parar. Sem isso, qualquer desfecho parece encorajador.

Escolha sinais que consiga observar nas primeiras semanas de uso real, não os que precisam de um ano de dados:

• as pessoas completam o fluxo principal sem serem conduzidas
• voltam sem serem lembradas
• o trabalho manual que o produto substituiu desce de forma clara
• alguém pede a funcionalidade seguinte em vez de uma correção básica

Escreva o que espera ver e até quando. Comparar isso com o que acontece é todo o sentido de lançar cedo.

Escreva o que «concluído» quer dizer

Defina o que «funciona» significa antes de o desenvolvimento começar. Use critérios de aceitação observáveis: o utilizador consegue submeter um pedido, a pessoa certa consegue revê-lo e o sistema regista o resultado corretamente.

As orientações do GDS sobre a escrita de user stories (abre num novo separador) descrevem os critérios de aceitação como «uma lista de resultados que usa como lista de verificação para confirmar que o seu serviço fez o seu trabalho», cada um formulado na forma está feito quando… — uma afirmação.

O valor está em poder ser verificado por alguém que não o construiu.

Ao nível da versão, The Scrum Guide (abre num novo separador) define a Definition of Done como «uma descrição formal do estado do incremento quando cumpre as medidas de qualidade exigidas para o produto».

Use Scrum ou não, a ideia viaja. Uma fasquia de qualidade acordada e escrita impede que «terminado» signifique coisas diferentes para cada pessoa na conversa.

Fixe as regras de dados antes do esquema

Decida que informação o produto tem de guardar e quem pode aceder-lhe. Privacidade, permissões, conservação, cópias de segurança e necessidades de auditoria são mais fáceis de planear antes de existirem as primeiras tabelas e integrações.

Para produtos que tratam dados pessoais de pessoas na UE, seguir essa ordem é a lei, não uma preferência.

As orientações da Comissão Europeia sobre proteção de dados desde a conceção e por defeito (abre num novo separador) descrevem medidas que se aplicam desde as fases mais iniciais da conceção do tratamento, com predefinições fixadas de modo a que «os dados pessoais sejam tratados com o mais elevado nível de proteção da privacidade».

O Comité Europeu para a Proteção de Dados adotou orientações sobre o artigo 25.º (abre num novo separador) em versão final em outubro de 2020, caso precise da posição detalhada do regulador.

Na prática é uma lista curta para escrever: o que recolhe, porquê, quem pode ver, quanto tempo guarda e como é que alguém consegue que seja apagado.

Responder a isso antes de desenhar a base de dados custa muito menos do que acrescentá-lo depois.

Escolha tecnologia e IA com cuidado

Escolha a tecnologia à volta do produto e das suas restrições. Uma framework moderna pode servir, mas a melhor escolha depende dos utilizadores, dos dados, das integrações, das necessidades de entrega e das pessoas que vão manter o software.

A IA merece a mesma disciplina. Decida se sustenta o fluxo principal, o que acontece quando a sua saída está errada e como uma pessoa a pode rever ou corrigir antes de a tratar como um requisito de produto.

Há agora razões medidas para cuidado. O 2025 DORA report (abre num novo separador), baseado em respostas de quase 5.000 profissionais de tecnologia, relata que «a adoção de IA continua a ter uma relação negativa com a estabilidade da entrega de software».

Produzir mais depressa sem testes e revisão sólidos não se acumula em entregas mais rápidas. Acumula-se em retrabalho.

Planeie revisões, acessos, transferência

Planeie os pontos de revisão antes da primeira linha de código. Demonstrações curtas, uma lista de tarefas partilhada e decisões escritas à vista de todos permitem mudar de rumo enquanto mudar de rumo ainda é barato.

O US Government Accountability Office expõe o argumento do risco no seu Agile Assessment Guide (abre num novo separador): a entrega incremental com avaliação contínua «pode reduzir os riscos de financiar um programa que falha ou produz tecnologia desatualizada».

Acordem propriedade e acessos desde o início. O projeto deve ter um repositório de código claro, ambientes documentados, um caminho de implantação acordado e um plano de transferência que não dependa da conta privada de uma só pessoa.

A capacidade DORA de controlo de versões (abre num novo separador) é específica quanto ao que lhe pertence: código da aplicação e dependências, ferramentas de criação de ambientes, ficheiros de composição de contentores, configuração de nuvem e artefactos de IA como os prompts.

A sua base declarada é que «a investigação mostra de forma consistente que o uso completo do controlo de versões prevê a entrega contínua».

As orientações do GDS sobre controlo de versões (abre num novo separador) acrescentam a outra metade da regra, a revisão: «cada alteração de código é revista por alguém que não a escreveu».

Juntos, esses hábitos são o que torna possível uma transferência. Se recriar o sistema depende do portátil de alguém, não tem um entregável — tem uma dependência.

Planeie o prazo e o orçamento

Um MVP focado pode muitas vezes ser planeado à volta de uma janela de entrega de 6–8 semanas quando o âmbito tem essa forma. É uma referência de planeamento, não uma promessa universal; integrações, aprovações e sistemas antigos desconhecidos podem mudar o prazo.

Ajuda saber como os prazos de software falham, porque não falham por igual nos dois sentidos.

Um estudo de 5.392 projetos de TI publicado no Journal of Management Information Systems (abre num novo separador) concluiu que as derrapagens de custo seguem uma lei de potência em vez de uma distribuição normal.

A maioria das derrapagens é modesta, mas há «uma cauda espessa que inclui um número menor de projetos com derrapagens extremas». Planear pela média subestima o risco que importa.

E não é só um problema de startups. A avaliação de alto risco das TI federais do GAO (abre num novo separador), publicada em janeiro de 2025, regista que os investimentos federais em TI «falham ou incorrem em derrapagens de custo e atrasos de calendário com demasiada frequência, contribuindo pouco para os resultados ligados à missão».

E isto contra uma despesa anual superior a 100 mil milhões de dólares. Escala e orçamento não resolvem isto; disciplina de âmbito e ciclos de retorno curtos resolvem.

Orce decisões, não apenas horas de código. Descoberta, desenho, construção, testes, lançamento, conteúdos, serviços de terceiros e as correções depois do lançamento somam-se todos ao que é preciso para tornar útil a primeira versão.

Um exemplo trabalhado

Pense num fundador que quer uma plataforma de marcações: os clientes marcam consultas, os prestadores gerem calendários, ambos os lados pagam e recebem lembretes, e um administrador supervisiona tudo. É um produto real com uma longa lista de funcionalidades.

O fluxo principal, porém, é estreito: um cliente encontra um horário livre e marca-o, e o prestador vê a marcação. Tudo o resto apoia isso ou pode esperar.

Uma primeira versão disciplinada podia ser assim:

• No âmbito: disponibilidade do prestador, marcação do cliente, uma confirmação e uma vista simples das próximas marcações para o prestador.
• Adiado: pagamentos na aplicação (ao início, receber um sinal manualmente), lembretes automáticos, avaliações, pesquisa entre vários prestadores e o painel de administração.
• Decidido à partida: que dados de cliente são guardados e por quanto tempo, de quem é o repositório e o que significa «uma marcação funcionou» como critério de aceitação.

A lista adiada não está abandonada — é o roteiro. Mas lançar primeiro o núcleo responde à única pergunta que importa cedo: os prestadores vão manter os calendários atualizados, e os clientes vão marcar?

Se vão, vale a pena construir o resto. Se não vão, nenhuma integração de pagamentos o teria salvo.

Como começar

O objetivo não é prever tudo. O objetivo é tornar visíveis os pressupostos importantes, testar o fluxo principal e criar uma base de produto que possa ser melhorada sem deitar fora o trabalho.

Se tem uma ideia mas não uma especificação completa, comece pelo utilizador, pelo fluxo de trabalho e pela decisão que precisa que a primeira versão sustente. Esses três pontos chegam para iniciar uma conversa de planeamento útil.