PoC e MVP mobile, do escopo à entrega
Respondo, construindo, a pergunta técnica que trava a decisão. A fase 1 transforma material solto em escopo, estimativa hora a hora e uma hipótese com critério de resposta. A fase 2 constrói o PoC ou o MVP que responde essa hipótese, com as mesmas práticas de governança das outras ofertas, e termina em handover do repositório.
Aplicativos autorais publicados nas lojas da Apple e do Google, com arquitetura, esteira e distribuição operadas de ponta a ponta.
Para quem é
- Produto ou negócio com uma hipótese cara, seja um SDK novo, uma integração incerta ou uma exigência de performance, que precisa de resposta antes de comprometer roadmap
- Empresas que vão contratar ou internalizar um squad e querem entrar na conversa com escopo dimensionado e um artefato funcionando, não com slide
- Áreas sem time mobile próprio que precisam levar um app a público restrito para validar demanda antes de montar estrutura
- Integradoras e times de pré-venda que precisam responder uma RFP com número defensável e, quando o cliente pede, uma demonstração que sustente a proposta
Sintomas
Se você reconhece três ou mais destes, a oferta provavelmente se aplica.
- A decisão de investir depende de uma pergunta técnica que ninguém consegue responder sem escrever código
- Existe um protótipo em Figma que todo mundo aprova, e nenhuma evidência de que ele funciona no dispositivo real
- O time discute nativo versus cross-platform há meses, e a decisão trava o roadmap inteiro
- Uma integração crítica de pagamento, biometria ou NFC nunca foi testada fora da documentação do fornecedor
- A estimativa foi feita por analogia, e ninguém consegue explicar como se chegou ao número
- Já houve uma tentativa de PoC que virou projeto, consumiu meses e não respondeu nada
O que você recebe
- Escopo macro e requisitos com critérios de aceitação
- Estimativa hora a hora, por fase e perfil
- Premissas e matriz de risco rastreadas à origem
- Hipótese declarada, com o que conta como resposta sim e como resposta não
- Aplicativo funcionando em dispositivo real, distribuído por TestFlight ou faixa interna
- Repositório transferido para a organização do cliente, com histórico e README de operação
- Arquitetura registrada em ADR
- Esteira de build, teste e distribuição
- Relatório de hipótese com a evidência medida
Fases
Escopo e estimativa
Entrevista de enquadramento, leitura de insumos, escopo macro, premissas, riscos, estimativa hora a hora e a hipótese que o PoC vai responder. Uma a duas semanas
Esqueleto
Repositório, arquitetura mínima e esteira de build e distribuição, antes de qualquer feature
Caminho de risco primeiro
A jornada que carrega a incerteza é implementada antes das fáceis. Se algo vai falhar, que falhe na semana 1
Iteração com demo semanal
Implementação das demais jornadas do escopo, com build instalável e nota de mudanças toda sexta
Handover
Transferência do repositório, ADRs, walkthrough técnico e o relatório de hipótese
O que não está incluído
- Entrar no squad do cliente, sem PR no repositório dele, sem sprint e sem daily
- Evolução do produto depois do handover, porque a partir dali quem constrói é o time
- Plantão, on-call, SLA de disponibilidade ou sustentação
- Publicação em loja pública e o processo de revisão da Apple ou do Google
- Backend de produção, já que o PoC consome mock ou o ambiente que o cliente fornecer
- Design de UI, design system ou pesquisa com usuário
- Escopo aberto: o que não entrou na fase 1 vira aditivo, nunca surpresa
- Garantia de que a hipótese será confirmada, porque a resposta pode ser não
Como meço sucesso
Combinado antes de começar, não descoberto no fim.
- A hipótese escrita na fase 1 tem resposta com evidência medida, e a resposta negativa conta tanto quanto a positiva
- A liderança sai do handover com uma decisão registrada: seguir, parar ou mudar de abordagem
- O build é reproduzível pela esteira e roda em dispositivo instalado por alguém do time, sem a minha presença
- Depois do walkthrough, uma pessoa do cliente implementa uma alteração pequena sozinha. É o teste real do handover
- O desvio entre o estimado na fase 1 e o realizado na fase 2 fica registrado, o que melhora a próxima estimativa
Perguntas frequentes
Qual a diferença entre o PoC e o MVP?
O PoC responde uma pergunta e é descartável: o valor está na resposta, e o código pode ser jogado fora sem prejuízo. O MVP é software que vai a público restrito e precisa sobreviver à evolução, então carrega mais teste, mais observabilidade e um handover mais longo. Confundir os dois é o que faz PoC virar produto por acidente.
E se a hipótese for refutada?
A oferta cumpriu o objetivo. Descobrir em cinco semanas que a abordagem não funciona custa uma fração de descobrir no oitavo mês, e o relatório traz o porquê, que costuma apontar o caminho alternativo. Não se cobra a mais nem a menos pela resposta ter sido não.
Você entra no nosso time durante a construção?
Não. Não abro PR no repositório de vocês, não participo de sprint nem de daily, e não assumo plantão. O artefato é construído fora e transferido no handover. É essa fronteira que permite entregar no prazo combinado.
O código fica com quem?
Com você, integralmente, no handover: repositório, histórico e ADRs transferidos para a sua organização. O app também nasce nas suas contas de loja, não nas minhas.
Podemos contratar só o escopo e a estimativa?
Sim, é a fase 1 avulsa, com o mesmo pacote rastreável de escopo, estimativa e risco. Se a construção for contratada em até 60 dias, o valor da fase 1 vira crédito integral.
Já temos escopo pronto. Dá para pular a fase 1?
Dá, mas ela é reduzida, não eliminada: preciso ler o material, escrever a hipótese com critério de resposta e conferir a estimativa contra a minha base. Construir sobre escopo que eu não li é como este tipo de trabalho estoura.
Próximo passo
Uma conversa de 30 minutos para delimitar o escopo. Ao fim dela dá para dizer se esta oferta se aplica e, se não se aplicar, qual das outras se aplica. Isso também é resultado.