O app não fracassa no lançamento. Ele fracassa na rotina.

Tem empresa que trata o lançamento de um app como se fosse a prova de que o projeto deu certo.

O app entrou no ar. A interface ficou boa. O cronograma foi cumprido. A entrega aconteceu.

E, por alguns dias, tudo parece indicar que a missão foi concluída.

Eu não compro muito essa leitura.

Porque o lançamento, sozinho, não prova quase nada.

O teste real começa depois. Começa quando o app encontra a rotina.

É nessa hora que ele deixa de ser apresentação e passa a virar operação.

O lançamento engana porque ele é visível

Lançamento tem uma vantagem perigosa: ele é muito visível.

• tem marco
• tem anúncio
• tem interface para mostrar
• tem sensação de progresso

E isso, para muita empresa, já parece suficiente para chamar o projeto de bem-sucedido.

Só que visibilidade não é a mesma coisa que maturidade.

Um app pode entrar no ar e ainda estar longe de provar que foi bem pensado.

Porque o que realmente importa não é só a publicação. É o comportamento do produto quando ele encontra uso real, pressão operacional, integração, exceção, volume, atendimento e necessidade de evolução.

É na rotina que o app encontra a vida real

No lançamento, quase tudo ainda está organizado demais.

• existe atenção concentrada
• existe energia de time
• existe tolerância maior a ajuste
• existe curiosidade do usuário
• existe empolgação em volta da novidade

Mas a rotina muda o jogo.

É nela que começam a aparecer coisas como:

• comportamento real do usuário
• demandas não previstas
• exceções operacionais
• limites de integração
• necessidade de ajuste fino
• pedidos internos de evolução
• pressão por desempenho
• dificuldade de suporte
• atrito no atendimento

É aí que o app deixa de viver na lógica do projeto e passa a viver na lógica do negócio.

O fracasso raramente aparece como um grande colapso imediato

Muita gente imagina fracasso como uma queda dramática, um bug gigantesco ou um desastre evidente.

Às vezes acontece. Mas, em boa parte dos casos, o fracasso aparece de forma mais silenciosa.

Ele surge quando:

• o time começa a contornar problema manualmente
• cada nova melhoria demora mais do que deveria
• o fornecedor vira gargalo
• a manutenção fica sofrida
• a adesão fica abaixo do esperado
• o atendimento encontra atrito o tempo todo
• a operação começa a perder confiança no produto
• o app existe, mas ninguém sente que ele realmente ajuda como deveria

Ou seja: o app não quebra necessariamente de um jeito cinematográfico. Ele vai se tornando um peso.

Esse raciocínio conversa muito com o que eu já escrevi em o custo invisível de um app mal planejado começa depois do lançamento. Em muitos casos, a conta mais pesada aparece justamente quando o produto começa a conviver com a rotina.

O problema normalmente começou antes da rotina mostrar a conta

Quando um app começa a falhar na rotina, a origem quase nunca está naquele momento específico.

Ela costuma estar antes:

• em escopo mal pensado
• em arquitetura fraca
• em prioridade mal definida
• em integração tratada como detalhe
• em uma leitura pobre da operação
• em um fornecedor que entregou interface, mas não sustentação
• em uma liderança que tratou o lançamento como objetivo final

É por isso que eu gosto de dizer que o app não fracassa no lançamento. Ele começa a mostrar o fracasso que já estava embutido quando encontra a rotina de verdade.

O lançamento é só o começo do teste

Quando a empresa entende que lançar não é provar, ela começa a fazer perguntas melhores.

Começa a pensar mais em:

• sustentação
• operação
• aderência do fluxo
• qualidade de integração
• facilidade de evolução
• governança de manutenção
• resposta a mudanças de negócio

Isso muda o tipo de projeto que nasce. E, normalmente, melhora bastante a chance de o app continuar fazendo sentido depois do entusiasmo inicial.

Essa mesma lógica aparece também em o fornecedor de tecnologia errado encarece a operação inteira. Quando a empresa toma decisões olhando só para a primeira entrega, ela frequentemente empurra o problema para a vida real do produto.

O app bom não é o que impressiona no começo

É o que aguenta a rotina sem virar atrito permanente.

É o que continua útil depois que a novidade passou.

É o que acompanha a operação em vez de obrigar a operação a se curvar a ele.

É o que evolui sem trauma excessivo.

É o que sustenta o negócio em vez de criar dependência, retrabalho e remendo.

Por isso, eu sempre desconfio um pouco de projeto elogiado cedo demais.

App não se prova no anúncio. Se prova quando começa a conviver com atendimento, pressão, exceção, manutenção, meta, integração e realidade.

No fim, o fracasso real é operacional

No fundo, é isso.

O fracasso do app quase nunca é só tecnológico.

Ele vira tecnológico, claro. Mas antes disso ele já virou operacional.

• virou desgaste
• virou lentidão
• virou improviso
• virou baixa confiança
• virou produto que existe, mas não sustenta bem a rotina da empresa

É por isso que o app certo não é o que apenas entra no ar.

É o que sobrevive à rotina sem se tornar um problema silencioso.

E, na prática, é essa diferença que separa um lançamento bonito de um produto realmente bem pensado.