MVP: como construir um produto web do zero ao deploy

O que é MVP e o que não é

MVP é Minimum Viable Product. A versão mais enxuta do seu sistema que resolve o problema principal e permite validar se o negócio funciona com usuários reais.

O que MVP não é: protótipo no Figma. Não é wireframe. Não é “vamos fazer tudo e lançar de uma vez”. É software funcionando em produção, com pessoas reais usando, gerando dados reais que informam as próximas decisões.

A confusão mais comum: tratar MVP como “versão ruim do produto final”. Não é. É a versão que te dá informação mais rápido. Um MVP bem feito tem qualidade de código, segurança e usabilidade. O que ele não tem é escopo desnecessário.

Outra confusão que aparece bastante: achar que MVP serve só pra startup. Não. Empresa consolidada que quer testar um produto novo, vertical nova ou canal digital novo se beneficia do mesmo processo. O raciocínio é idêntico: gasta pouco pra aprender rápido, e só escala depois de confirmar que funciona.

Por que construir um MVP antes do produto completo

Porque você não sabe se sua ideia funciona até alguém usar.

Isso parece óbvio quando digo assim, mas na prática a maioria dos projetos que recebo começa ao contrário. O empreendedor chega com 40 telas desenhadas, 15 integrações listadas e 8 perfis de usuário mapeados. Quer tudo funcionando antes de mostrar pra ninguém.

O problema: já vi projeto de R$ 200k que levou 8 meses pra lançar e descobriu no primeiro mês de operação que o mercado queria algo diferente. Os 8 meses de desenvolvimento viraram 8 meses de desperdício. E já vi MVP de R$ 25k que validou a hipótese em 3 semanas e evoluiu a partir de feedback real de usuários.

O MVP não é a versão pior. É a versão que responde a pergunta “isso funciona?” antes de você investir R$ 200k na resposta errada.

Tem um efeito colateral positivo que pouca gente menciona: o MVP força clareza. Quando você tem orçamento limitado e prazo curto, precisa decidir o que realmente importa. Essa restrição elimina features “legais de ter” e deixa só o que resolve o problema de fato. Muitos produtos melhoram justamente porque foram forçados a ser simples na primeira versão.

O processo que eu sigo

1. Definir o problema central

Antes de pensar em feature, tela ou tecnologia: qual problema o sistema resolve? Pra quem? Uma frase. Se não cabe em uma frase, o escopo tá grande demais pra um MVP.

Exemplo ruim: “plataforma completa de gestão de oficina mecânica com estoque, financeiro, agendamento, CRM, relatórios, app pra cliente e integração com nota fiscal.”

Exemplo bom: “sistema pra oficina controlar os serviços em andamento e avisar o cliente quando o carro tá pronto.”

O exemplo ruim tem 10 meses de trabalho. O exemplo bom tem 6 semanas e resolve o maior problema da oficina: cliente ligando pra perguntar se o carro ficou pronto.

O Mariah seguiu exatamente essa lógica. O problema: “minha irmã não sabe quanto vendeu nem quem deve pra ela.” A solução: app com painel de encomendas e controle financeiro. Saiu em 4 horas. Se tivesse tentado fazer gestão de estoque, catálogo de produtos, e relatório mensal na primeira versão, teria levado 2 semanas e ela não ia usar a metade.

2. Mapear o fluxo principal

O MVP faz uma coisa bem. Qual é o fluxo que o usuário mais vai repetir? Desenho esse fluxo do começo ao fim e construo só isso na primeira versão.

No AutoPars, o fluxo principal era: vendedor publica peça → comprador busca → comprador compra → vendedor é notificado → envio é gerado. Tudo que não tá nesse fluxo (relatórios avançados, sistema de avaliação, chat entre vendedor e comprador) ficou pro backlog.

O resto não some. Só espera. E quando volta, volta com dados pra justificar se vale a pena ou não.

3. Escolher a stack

Pra webapp, minha stack padrão:

• React no frontend (componentes, estado, roteamento)
• TypeScript pra evitar bugs bobos em produção
• Supabase no backend (auth, banco PostgreSQL, storage, realtime)
• Tailwind CSS pra UI rápida e consistente

Com essa combinação, entrego MVP funcional em 4 a 8 semanas trabalhando solo. O Supabase elimina semanas de setup de backend, o React dá flexibilidade pra qualquer tipo de interface, e o TypeScript pega erros antes de ir pra produção.

Se precisa de landing page junto (pra captação, SEO ou apresentação), Astro entra pra parte estática. Duas stacks, cada uma fazendo o que faz melhor.

4. Construir em ciclos curtos

Não fico 6 semanas codando pra mostrar tudo no final. A cada semana, o cliente vê o que tá funcionando, testa e dá feedback. Isso evita retrabalho e mantém o projeto alinhado com a realidade.

Cronograma típico de um MVP:

Semana 1: autenticação + estrutura base + modelo de dados. No final da semana, o cliente consegue fazer login e navegar pela estrutura vazia. Parece pouco, mas valida que a fundação tá certa. Nessa fase já configuro o Supabase com RLS (Row Level Security), porque retroficar controle de acesso depois é muito mais caro que fazer certo desde o início.

Semana 2-3: fluxo principal funcionando. O core do produto tá rodando. Dá pra usar, dá pra testar, dá pra dar feedback concreto.

Semana 4-5: integrações e refinamento. Pagamento, notificação, upload de arquivo — tudo que complementa o fluxo principal. Interface polida, edge cases tratados.

Semana 6: testes finais, ajustes de feedback e deploy. Sistema vai pro ar com domínio customizado, HTTPS e monitoramento básico. Configuro analytics (Plausible ou Umami) pra começar a coletar dados de uso desde o dia 1 — esses dados vão guiar as decisões da v2.

5. Deploy e primeiros usuários

MVP precisa ir pro ar cedo. Não na versão perfeita, na versão funcional. Os primeiros 10 usuários vão mostrar o que falta, o que tá sobrando e o que precisa mudar.

Deploy na Vercel (frontend) e Supabase cloud (backend). Em 15 minutos o sistema tá online com domínio customizado e HTTPS. Sem configurar servidor, sem gerenciar infra, sem provisionar banco de dados. O setup que antes levava dias agora leva minutos.

O que cortar no MVP

Essa é a parte mais difícil. Todo cliente quer tudo na primeira versão. O trabalho do dev é mostrar o que pode esperar sem prejudicar o produto.

Corta:

• Dashboard de analytics. Usa Plausible ou Umami por enquanto. Dados básicos sem desenvolver painel customizado
• Sistema de notificação elaborado. WhatsApp manual ou email simples. Automação vem depois
• Múltiplos perfis de usuário. Começa com o perfil principal. Admin e secondary users vêm na v2
• App nativo. PWA resolve na primeira fase. Instala no celular, funciona offline, sem App Store
• Integrações que podem ser manuais. Pagamento via Pix manual antes de integrar gateway. Frete calculado por tabela antes de integrar Melhor Envio
• Relatórios detalhados. Uma tela com números básicos. O dashboard completo vem quando você souber quais métricas importam de verdade

Não corta:

• Autenticação e controle de acesso. Segurança não é feature, é requisito. Não vai pro ar sem auth
• Responsividade. Se não funciona no celular, metade dos usuários não usa. E metade é generosa — pra alguns produtos, 80% do acesso é mobile
• Validação de dados. Dado errado no banco é dívida técnica cara. Validar na entrada é 10x mais barato que corrigir depois
• Backup do banco de dados. Supabase faz backup diário no plano Pro. Se você tá no plano gratuito, configure backup manual. Perder dados de produção não tem volta

O mito do “escopo mínimo” que vira maximal

O maior risco do MVP é o escopo crescer durante o desenvolvimento. “Já que estamos fazendo isso, vamos adicionar aquilo.” Começa com 5 telas, termina com 25. Começa com 1 integração, termina com 4. Começa como MVP, termina como produto completo que levou 4 meses.

Minha regra: qualquer adição de escopo durante o MVP vai pra lista de “pós-lançamento”. Se não era necessário no dia 1, não é necessário agora. Lança, coleta dados, e decide com informação real o que adicionar.

Na prática, mantenho um documento compartilhado com o cliente chamado “Backlog pós-MVP”. Toda ideia que surge durante o desenvolvimento vai pra lá com uma nota curta sobre o problema que resolve. Quando o MVP tá no ar e os dados começam a chegar, a gente cruza esse backlog com o comportamento real dos usuários. Umas 40% das ideias que pareciam essenciais durante o desenvolvimento se mostram irrelevantes quando confrontadas com dados. E features que ninguém tinha pensado aparecem como prioridade.

Depois do MVP: evolução com dados

Com o MVP rodando e gerando dados, as próximas decisões ficam mais fáceis:

• Quais features os usuários pedem? Prioriza as que mais aparecem
• Quais telas ninguém acessa? Remove ou repensa
• Onde o fluxo trava? Melhora UX no ponto de fricção
• O modelo de negócio funciona? Valida antes de escalar

O FitPlan seguiu esse caminho. Começou com treinos e painel do aluno. Os dados de uso mostraram que alunos abandonavam nas primeiras semanas. Isso gerou o sistema de notificação de inatividade que reduziu cancelamento em 37%. Essa feature não tava no plano original — surgiu dos dados.

MVP não é o fim. É o ponto de partida — e os dados de uso mostram pra onde ir depois.