Como lançar um app: o guia do fundador não-técnico

Um guia, do ponto de vista do fundador, para colocar um software sob medida no ar: como saber quando um app está realmente pronto, as quatro decisões de lançamento que só você pode tomar e o que monitorar nas primeiras 48 horas.

Uma fundadora com quem trabalhamos recebeu a mensagem que todo fundador não-técnico espera: “Está pronto. Tudo funcionando.” Ela anunciou o app no LinkedIn naquela tarde, colou o link de download e foi jantar. Quando a sobremesa chegou, a tela de cadastro já dava erro para metade das pessoas que tocavam nela, e os e-mails de boas-vindas tinham parado de sair em silêncio. O código estava terminado. O app não estava lançado.

Essa distância é o jogo inteiro. Como lançar um app, para um fundador não-técnico, é o trabalho de levar o produto de “o time de desenvolvimento diz que terminou” até “pessoas de verdade estão usando em produção e nada cai”. Lançar é um evento de engenharia, não um anúncio de marketing. O anúncio é a parte fácil. Quase todo conselho que você encontra na internet pula direto para ele.

Terminado não é lançado

Pesquise “como lançar um app” e você vai achar dois tipos de artigo. Um é um checklist de marketing: otimize a página na loja, alinhe imprensa, configure suas tags de atribuição. O outro é uma plataforma no-code mandando você apertar o botão de publicar dela. Os dois tratam o lançamento como os últimos 5% do marketing. Nenhum fala da parte que realmente quebra.

Vale guardar este reenquadramento: lançar um app é um evento de engenharia antes de ser um evento de marketing. O risco que derruba fundadores no primeiro dia quase nunca é “pouca imprensa”. É o banco de dados que nunca foi testado com tráfego real, o webhook de pagamento que falha em silêncio, o fluxo de redefinição de senha que ninguém clicou porque todo mundo que testou já tinha conta. Terminado quer dizer que as funcionalidades existem. Lançado quer dizer que elas sobrevivem ao contato com quem não as construiu.

Para um fundador não-técnico isso é desconfortável, porque o evento de engenharia é justo a parte para a qual você se sente menos preparado. Então você delega tudo e torce. Esse é o erro. Você não consegue escrever o script de deploy, mas consegue ser dono das decisões em volta dele, e são essas decisões que determinam se o seu lançamento é uma comemoração ou um incêndio.

Antes de lançar: o teste de prontidão

Estar com as funcionalidades completas não é o mesmo que estar pronto. Um fundador precisa de um jeito de enxergar a diferença sem ler código. O teste que damos aos fundadores com quem trabalhamos é simples: um estranho conseguiria usar o fluxo principal, no próprio celular, com os próprios dados, enquanto você observa e não diz nada?

Essa última parte importa. Se você precisa se inclinar e explicar, não está pronto. Se a demo só funciona no notebook do desenvolvedor com uma conta de teste preparada, não está pronto. A confiança do time de desenvolvimento não é prova; a confiança deles está calibrada para um ambiente que eles controlam.

Faça um ensaio geral antes de lançar. Escolha três ou quatro pessoas parecidas com seus usuários reais e que nunca viram o app. Dê um celular, uma tarefa real e silêncio. Observe onde elas travam. Isso é diferente do aceite que você fez no teste de aceitação do usuário, onde você conferia o build contra a especificação. O ensaio geral confere o build contra um humano que nem sabe que a especificação existe.

Algumas coisas precisam ser verdade antes de você entrar no ar, e você pode confirmar cada uma delas sem ser técnico:

• Alguém consegue se cadastrar, fazer a única coisa para a qual o app existe e voltar amanhã para encontrar os dados ainda lá.
• Pagamentos, se você cobra, foram rodados com um cartão real, não um cartão de teste, e o dinheiro de fato se moveu.
• Os critérios de aceitação que você combinou para as funcionalidades do lançamento passam todos, conferidos por você, não descritos para você.
• Você sabe o que acontece quando algo falha: o usuário vê uma mensagem clara ou uma tela em branco?
• Se o seu app vai para a loja da Apple ou do Google, ele passou pela revisão. Leia as diretrizes de revisão da App Store da Apple antes de enviar, porque uma rejeição pode custar uma semana que você não tinha previsto.

Se você não conseguir um passe limpo nesses pontos, você ainda não tem data de lançamento. Você tem uma meta.

As quatro decisões de lançamento que só você pode tomar

Você não vai fazer o deploy do app. Mas quatro decisões são suas, e nenhum desenvolvedor pode tomá-las por você, porque cada uma é sobre o negócio, não sobre o código.

A decisão de ir ou não ir. Em algum momento alguém tem que dizer “vamos” ou “vamos esperar”. Se você deixa isso para o time de desenvolvimento, a decisão é tomada por padrão no instante em que o código entra, que é exatamente como nossa fundadora acabou anunciando um app quebrado durante o jantar. Marque uma conversa de ir/não-ir na agenda, com o teste de prontidão como pauta. Você toma a decisão, em voz alta, num dia específico.

A decisão de reverter, o rollback. Antes de lançar, faça uma pergunta: se isso der errado na primeira hora, como a gente desliga? Às vezes a resposta é “voltamos para a versão anterior em dois minutos”. Às vezes é “não dá, a nova estrutura do banco de dados é só de ida”. Você precisa saber em qual mundo está antes do lançamento, não durante o incêndio. Um parceiro que não responde isso com clareza está te dizendo alguma coisa.

Quem fica de plantão, o on-call. Lançamentos de verdade quebram em horários inconvenientes. Decida, por escrito, quem está olhando o sistema nas primeiras 48 horas e como você fala com essa pessoa às 23h. “Todo mundo está por aí” não é um plano. Uma pessoa com nome, um número de telefone, uma janela combinada. Essa é a parte de virar a noite depurando, e é justo a parte que arranjos baratos deixam de fora em silêncio.

O plano dos primeiros usuários. Quem usa o app primeiro, e quantos? A resposta quase nunca deveria ser “todo mundo, de uma vez”. O que nos leva à parte que a maioria dos fundadores pula.

Soft launch antes de hard launch

Um hard launch é o grande anúncio: o post no LinkedIn, a imprensa, o e-mail para a sua lista inteira. Um soft launch é deixar entrar primeiro um fluxo controlado de usuários reais, observar, corrigir e só então abrir as portas.

O motivo de fazer um soft launch não é cautela por cautela. É que seus primeiros usuários reais vão achar problemas que seus usuários de teste nunca conseguiriam, e você quer achá-los num volume que dá para corrigir. Vinte usuários reais revelando cinco bugs é uma terça-feira comum. Dois mil usuários revelando os mesmos cinco bugs é um problema de reputação e uma fila de suporte que você não consegue zerar.

Uma sequência que funciona: abra para um punhado de usuários amigáveis que vão perdoar as arestas e te dizer a verdade. Depois um grupo um pouco maior que não te conhece. Observe cada grupo por uns dois dias. Se o fluxo principal se segura e os números fazem sentido, amplie de novo. Seu hard launch vem quando você já viu estranhos de verdade usarem a coisa e ela não caiu. A essa altura o anúncio é uma formalidade, que é como deveria ser. O lançamento já aconteceu, em silêncio, e funcionou.

Essa também é a resposta honesta para fundadores que acham que lançar é um único dia dramático. Os bons lançamentos de que participamos eram chatos por fora. O drama, quando havia, aconteceu duas semanas antes com doze usuários e foi resolvido antes de qualquer um estar olhando.

As primeiras 48 horas: o que monitorar

Com usuários reais dentro, seu trabalho muda de decidir para observar. Você não precisa de um painel cheio de métricas de vaidade. Você precisa saber, perto do tempo real, se a coisa está funcionando. Três perguntas cobrem quase tudo.

As pessoas estão entrando? Cadastros que começam e não terminam são o sinal inicial mais barulhento de que algo no funil quebrou. Elas estão fazendo a tal coisa? Se os usuários chegam e nunca alcançam a ação principal, ou ela está escondida ou está quebrada. E tem algo pegando fogo nos bastidores? Erros, pagamentos que falharam, e-mails que não saíram. Seu time de desenvolvimento pode colocar um alerta simples para que um humano fique sabendo das falhas antes de um usuário reclamar no Twitter.

Combine antes do lançamento o que vai ser monitorado e quem monitora. O fundador não precisa ler os logs. O fundador precisa saber que alguém está lendo, e que esse alguém vai ligar.

Quem realmente aperta o botão

Se você não é técnico, a pergunta honesta por trás de tudo isso é: quem faz o deploy do meu app, e o quanto eu preciso confiar nessa pessoa? Você não vai rodar o release sozinho. Tudo bem. Muitos fundadores sérios nunca tocam no deploy. O que você não pode fazer é tratar tudo como uma caixa-preta e descobrir quem era o responsável só depois de quebrar.

Parceiros de tecnologia não deveriam ser caixas-pretas. O estúdio ou desenvolvedor que coloca o seu app no ar deveria conseguir te dizer, em linguagem simples, o que o lançamento envolve, como vão saber que deu certo, como desfariam e quem está acordado se quebrar. Se essas respostas voltam vagas, a vagueza é o aviso. O time que recebe bem uma conversa de ir/não-ir e já tem um plano de reversão pronto é o time que vale a pena manter. O trabalho do dia do lançamento é real, com a mão na massa, e às vezes acontece às 2 da manhã. O parceiro certo já sabe disso e já se planejou.

O que você lança, no fim, é a menor versão do produto que você teria orgulho de colocar na frente de um cliente pagante. Lance como se importasse, porque a primeira impressão é a que você não recupera. Depois observe, corrija o que o mundo real achar e deixe o anúncio ser a volta da vitória discreta que ele deveria ser.

Perguntas frequentes

Quanto custa lançar um app?
As taxas das lojas são pequenas: a Apple cobra uma anuidade de desenvolvedor e o Google uma taxa única. O custo real de lançar não é o cadastro na loja, é a prontidão e o plantão: o ensaio geral, a correção de bugs na janela do soft launch e alguém olhando o sistema nos primeiros dias. Reserve orçamento para o trabalho em volta do go-live, não só para o build. Nosso detalhamento de quanto custa desenvolver um app mostra para onde esse dinheiro vai.

Dá para lançar um app de graça?
Você pode publicar na web por quase nada, e as taxas das lojas são modestas. Mas “de graça” geralmente quer dizer que ninguém está de plantão quando quebra e ninguém fez um ensaio geral de verdade. Isso não é um lançamento, é uma aposta. O custo que importa é atenção nas primeiras 48 horas, e atenção não é de graça.

Qual a diferença entre soft launch e hard launch?
Um soft launch deixa entrar primeiro um grupo controlado de usuários reais para você achar e corrigir problemas em silêncio. Um hard launch é o anúncio público para todo mundo. Soft launch primeiro, sempre. O hard launch deveria parecer sem graça, porque o lançamento de verdade já aconteceu e se segurou.

Quem faz o deploy do meu app se eu não sou técnico?
Seu desenvolvedor ou estúdio faz. Você não precisa rodar o release, mas precisa saber quem é o responsável, como vão confirmar que deu certo e como reverteriam. Se o seu parceiro não consegue explicar o lançamento em linguagem simples, isso é um problema para resolver antes do go-live, não depois.

Como sei que meu app está realmente pronto para lançar?
Faça o teste de prontidão: um estranho parecido com seus usuários reais completa o fluxo principal no próprio celular, com os próprios dados, enquanto você observa e não diz nada. Se ele passa sem a sua ajuda e os dados continuam lá no dia seguinte, você está perto. Também ajuda confirmar que o lançamento é o produto mínimo viável certo e que seus critérios de aceitação e o teste de aceitação do usuário passaram antes de marcar uma data.