Quanto tempo leva para desenvolver um MVP? Prazos reais por tipo de produto

A complexidade é o melhor indicador do prazo de um MVP. Usamos três níveis para orçar os projetos.

Os mesmos níveis definem o orçamento. A nossa análise de quanto custa um MVP SaaS mostra a faixa de preço de cada um.

Os tipos de produto se encaixam nesses níveis de um jeito bem previsível. Esta tabela mostra onde os MVPs mais comuns costumam cair; o seu produto pode subir ou descer um nível dependendo dos detalhes.

Um Mini App do Telegram costuma ficar no nível simples ou médio. Ele abre dentro do Telegram, então não é preciso publicar em loja de aplicativos, e a conta do usuário vem do próprio Telegram.

Todo MVP passa pelas mesmas fases, embora elas se sobreponham mais do que uma lista simples sugere.

• Orçamento. O seu briefing vira uma proposta com escopo, prazo e preço. Na Sakura, a maioria das propostas sai em 2–3 dias úteis depois de um briefing completo.
• Design. Primeiro os fluxos do usuário, depois as telas feitas com um sistema de componentes reutilizáveis e, por fim, um protótipo clicável.
• Desenvolvimento. Frontend, backend e integrações, com uma versão funcionando que você pode testar clicando toda semana.
• Testes. Cada fluxo nos navegadores e dispositivos combinados, além do desempenho e da acessibilidade básica.
• Lançamento. Publicação, analytics, envio para a loja se houver aplicativo e as primeiras correções quando os usuários reais chegarem.

Design e desenvolvimento se sobrepõem de propósito. Assim que os primeiros fluxos são aprovados, o desenvolvimento começa por eles enquanto os demais ainda estão sendo desenhados.

O design costuma começar antes e terminar antes do desenvolvimento, mas os dois não deveriam andar um depois do outro. Quando o design entrega um arquivo pronto e vai embora, o desenvolvimento muitas vezes descobre telas caras de implementar, e semanas vão para o retrabalho.

A solução é desenhar com os mesmos componentes que os desenvolvedores vão construir. Assim, uma tela aprovada já está quase pronta, e as dúvidas são resolvidas enquanto ainda é barato.

Por exemplo, o AutoIntel, uma ferramenta B2B para o mercado alemão de carros usados, começou com o design de produto e um protótipo interativo com anúncios de exemplo. O cliente apresentou o protótipo à equipe e decidiu quais campos e filtros importavam antes de orçar a coleta de dados. Essa ordem mantém a parte mais cara do desenvolvimento focada no que a interface realmente precisa.

Está planejando uma data de lançamento? Mande um briefing curto e diremos em que nível o seu produto se encaixa e qual é um prazo realista.

Algumas funcionalidades parecem pequenas no briefing e acrescentam semanas ao desenvolvimento. Fique de olho nestas:

• Integrações. Pagamentos, provedores de login, CRMs e APIs externas exigem configuração, tratamento de erros e testes.
• Perfis e permissões. Cada perfil a mais multiplica os estados que cada tela precisa tratar.
• Um aplicativo nativo. Ele acrescenta um segundo frontend e a revisão da loja. O App Review da Apple avalia pelo menos 50% dos envios em menos de 24 horas e 90% em menos de 48 horas, mas uma rejeição zera o relógio.
• Vários idiomas. Cada texto, mensagem de erro e ajuda precisa existir em cada idioma, e o layout tem que comportar a versão mais longa.
• Conteúdos atrasados. Textos, preços, documentos legais e dados reais que chegam na última semana travam os testes.
• Decisões lentas. Uma pergunta que espera uma semana por resposta atrasa tudo o que é construído em cima dela.

Você encurta o prazo de um MVP fazendo menos, não fazendo pior. Estas decisões economizam mais tempo:

• Corte fluxos inteiros, não o acabamento. Leve os fluxos secundários para uma versão posterior em vez de construir cada fluxo pela metade.
• Lance primeiro na web. Um aplicativo web responsivo chega aos usuários no celular e no computador e não passa pela revisão das lojas.
• Use serviços prontos. Checkout hospedado, provedores de login e serviços de e-mail existentes são mais rápidos e seguros do que versões próprias.
• Decida rápido. Defina uma pessoa que possa aprovar os designs e responder às perguntas no mesmo dia.
• Teste cedo com poucos usuários. A pesquisa de Jakob Nielsen mostrou que testar com 5 usuários revela a maioria dos problemas de usabilidade, então várias rodadas pequenas valem mais do que uma grande.

O CarPixly, um estúdio de fotos com IA para anúncios de carros, lançou a versão para Android como APK na própria página de download enquanto a versão para iOS ainda estava a caminho. Lançar onde dá e acrescentar plataformas depois costuma ser o caminho mais rápido até usuários reais.

As primeiras semanas andam mais rápido quando algumas coisas já estão prontas antes do início. Nenhuma delas exige conhecimento técnico:

• Uma lista curta de fluxos principais. As uma a três tarefas que os usuários precisam conseguir fazer no lançamento, em palavras simples.
• Uma pessoa que decide. Alguém que possa aprovar os designs e responder às perguntas no mesmo dia.
• Acesso às contas que já existem. Domínio, hospedagem, analytics, provedor de pagamentos e qualquer API que você já use.
• Conteúdo real, ou uma data para ele. Textos, preços, páginas legais e dados de exemplo que o produto vai mostrar.
• A sua restrição de lançamento. O evento, a reunião com investidores ou a temporada que tornam a data importante.

Com isso em mãos, o orçamento leva dias em vez de semanas, e o design pode começar com conteúdo real em vez de textos provisórios.

Os prazos raramente atrasam porque os desenvolvedores digitam devagar. Eles atrasam por causa das decisões tomadas, ou não tomadas, em volta do desenvolvimento:

• Um escopo que cresce no meio do projeto sem um processo de mudanças por escrito.
• Rodadas de feedback que levam uma semana em vez de um dia.
• Uma definição de “pronto” que ninguém escreveu, e as últimas semanas viram uma discussão.
• Integrações previstas como uma linha no escopo, em vez de considerar seus casos extremos reais.

Um escopo fechado com processo de mudanças mantém quase tudo isso sob controle. Explicamos como em preço fechado ou por hora.

O lançamento liga um segundo relógio, não desliga o primeiro. As primeiras semanas depois da publicação costumam ser as mais movimentadas do projeto inteiro.

Os usuários reais encontram bugs que os testes não pegaram, pedem pequenas mudanças e usam o produto de jeitos que ninguém planejou. Reserve logo depois do lançamento um período curto de correções e melhorias rápidas, antes de qualquer funcionalidade nova.

Depois disso, o trabalho entra em um ritmo estável: um plano mensal de melhorias com base no que o uso real mostra. Todo projeto da Sakura inclui um período de garantia definido para corrigir bugs, e o trabalho seguinte pode continuar em um plano mensal ou passar para a sua própria equipe.

O mínimo possível, desde que ainda teste a sua principal hipótese. O sentido de um MVP, nas palavras do Lean Startup, é “começar a aprender o mais rápido possível”.

Se o seu plano passa muito do nível complexo, pergunte-se o que você quer aprender e se um produto menor poderia ensinar a mesma coisa. Muitas vezes, um único fluxo lançado antes responde à pergunta que mais importa.

Quando quiser planejar o seu, conte sobre o seu produto. Você vai receber uma proposta com escopo, prazo e preço fechado, e toda semana uma versão para acompanhar o produto tomando forma.