Como um aplicativo sai do papel

Duas a quatro semanas entendendo o negócio, o problema e quem vai usar o produto. Conversamos com quem conhece o assunto, olhamos o que já existe e testamos as hipóteses mais caras antes de assumi-las.

É a etapa mais curta e a que mais muda o custo de todas as outras. Quase sempre termina com um escopo menor do que o imaginado — não por economia, mas porque metade das funcionalidades planejadas depende de uma resposta que só o uso real dá.

Sai daqui: escopo da primeira versão, fluxos principais, roadmap e as métricas que vão dizer se deu certo.

A visão vira experiência. Desenhamos o caminho que a pessoa percorre — quais decisões toma, em que ordem, com qual informação à mão — e só depois isso ganha forma, tipografia e cor.

Ao fim desta etapa existe um protótipo navegável: você usa o aplicativo antes de ele existir. É onde sai barato corrigir o que custaria dez vezes mais depois de programado, e é o material que costuma destravar aprovação de orçamento.

Design e código andam juntos, com entrega toda semana. Mostramos trabalho cedo e ainda incompleto de propósito: sumir por um mês e reaparecer com uma grande revelação só empurra o risco para o fim, quando mudar de ideia é caro.

É aqui que se decide entre nativo e Flutter, se constrói o backend e se monta a infraestrutura. As decisões ficam registradas com o motivo, não só com o resultado — seis meses depois, quando alguém perguntar por que é assim, a resposta existe.

Publicar é um projeto dentro do projeto: contas de desenvolvedor, certificados, política de privacidade, classificação etária e a revisão da Apple e do Google, que leva de um a sete dias e entra no prazo desde o começo.

Depois do lançamento, monitoramos falhas e desempenho. Um aplicativo que trava para 3% dos usuários perde muito mais que 3% deles. As contas das lojas e o código ficam no seu nome, desde o primeiro dia.