Construí este produto completamente sozinho, principalmente à noite, nos fins de semana e sacrificando mais feriados do que eu gostaria de admitir. Durante muito tempo, ele ainda parecia um projeto pessoal que, por acaso, estava disponível na Web.
Ativar os pagamentos mudou essa sensação imediatamente. O código não ficou de repente mais sofisticado, mas minha responsabilidade pelo produto mudou. A partir do momento em que alguém pode pagar, um fluxo quebrado deixa de ser apenas um edge case inacabado. Onboarding, moderação, retenção, confiança e confiabilidade deixam de ser assuntos para o futuro. Passam a fazer parte do que o produto promete agora.
Essa foi a principal lição que tirei do lançamento: construir sozinho um projeto cheio de funcionalidades e operar um produto real são trabalhos diferentes.
No desenvolvimento solo, a atenção virou o gargalo
Enquanto construía o produto, quase desapareci das redes sociais. Não foi uma estratégia de lançamento. Decisões de produto, implementação, edge cases, testes de fluxo e preparação da release competiam pelas mesmas horas limitadas.
Hoje entendo muito melhor essa parte do trabalho solo. O gargalo nem sempre é a velocidade com que consigo escrever código. É a quantidade de atenção que consigo dar a um número crescente de estados, transições e modos de falha dentro do produto.
Uma build bem-sucedida não responde a essas perguntas. Um pagamento bem-sucedido também não.
Os pagamentos mudaram o significado de um bug
Antes dos pagamentos, eu ainda conseguia tratar algumas imperfeições como coisas que corrigiria depois. Quando os pagamentos entraram no ar, esse modelo mental deixou de funcionar para mim. Um produto pago não precisa ser livre de bugs; isso não seria realista. Mas o custo de deixar um problema conhecido sem solução muda quando outra pessoa já confiou dinheiro ao produto.
O mesmo vale para onboarding e moderação. Durante o desenvolvimento, eles podem parecer sistemas de apoio em volta da funcionalidade “real”. Em produção, eles fazem parte da funcionalidade porque o usuário os experimenta diretamente. Retenção é parecida: uma boa primeira sessão não prova que o produto dê um motivo para a pessoa voltar.
Os pagamentos não provaram que o produto estava terminado. Eles mostraram quanto trabalho a palavra “terminado” escondia.
O lançamento me deu outro tipo de informação
Depois do release veio o trabalho menos fotogênico: bugs que só aparecem depois da publicação, fluxos quebrados, problemas de moderação que se tornam reais quando os usuários chegam e perguntas sobre retenção muito mais difíceis do que causar uma boa primeira impressão.
Eu tento não interpretar esses sinais além do que eles realmente mostram. Um bug depois do release não significa automaticamente que a arquitetura seja ruim. Um problema de retenção, sozinho, não é um diagnóstico de product-market fit. Um problema de moderação não prova que o sistema inteiro seja inseguro. Um sintoma mostra onde investigar; não explica automaticamente a causa.
O que muda é a qualidade da evidência. Antes do lançamento, posso testar o que espero que os usuários façam. Depois, preciso lidar com o que eles realmente fazem. Uma release não é o momento em que a incerteza desaparece. É o momento em que uma parte da incerteza mais importante finalmente se torna observável.
O ciclo pós-lançamento que uso hoje
Hoje me interessa mais o trabalho depois do lançamento do que deixar perfeita a narrativa do próprio lançamento: lições sobre pagamentos, fluxos quebrados, desafios de moderação, comportamento dos usuários, surpresas de retenção e pequenos ajustes que tornam o produto gradualmente mais confiável.
- Observar o fluxo real. Não presumir que o caminho que desenhei é o mesmo caminho que os usuários realmente seguem.
- Separar sintomas de causas. Uma etapa que falha mostra onde algo deu errado, não automaticamente por quê.
- Priorizar falhas que afetam a confiança. Pagamentos, acesso, onboarding e moderação merecem mais urgência do que imperfeições cosméticas porque o custo da falha é maior.
- Corrigir primeiro o menor problema verificado. Prefiro remover uma fonte de atrito confirmada a redesenhar um sistema com base numa suposição.
- Rever a experiência do usuário depois da correção. Uma mudança no código pode estar correta e ainda assim não resolver o problema do usuário.
Isso não é um framework universal. É simplesmente a disciplina que faz mais sentido para mim desde que passei de construir o produto para operá-lo.
O lançamento mudou minha fonte de verdade
A distinção que mais importa para mim hoje é entre ter construído o produto e estar pronto para operá-lo. Construir pergunta se o sistema consegue fazer aquilo para o qual foi projetado. Operar pergunta o que acontece quando pessoas reais usam, entendem errado, abandonam, voltam, pagam ou chegam a um caminho que eu não tinha previsto.
É por isso que já não vejo o lançamento como uma linha de chegada. Antes dele, boa parte da evidência vem das minhas próprias hipóteses e testes. Depois, o produto começa a responder por meio do comportamento real, das falhas e do uso repetido.