Um produto bonito sem operação é custo, não ativo

Software só vira ativo quando alguém responde por ele todos os dias: releases saem, suporte é respondido, conteúdo se mantém vivo, erros são vistos antes de os usuários verem. Um produto lançado sem ninguém operando não fica quieto guardando valor. Ele apodrece, em público, com a sua marca em cima, e cada mês sem atenção o afasta de ativo e o aproxima de passivo.

Essa é a parte desconfortável de construir um produto que a maioria das propostas nunca menciona. A construção tem data de início e data de fim. A operação começa no lançamento e nunca termina. Se ninguém for dono dessa segunda metade, o dinheiro gasto na primeira não foi investimento. Foi o preço de um screenshot muito caro.

O que é operação, na prática

Operação não é uma linha vaga de manutenção no rodapé de um contrato. É um conjunto concreto de tarefas, e cada uma precisa de um nome ao lado:

• Alguém acompanhando logs de erro e relatórios de crash, pegando problemas antes de os usuários reclamarem
• Releases nas lojas de app: novas versões de sistema, novos aparelhos, mudanças de política de review, certificados vencendo
• Conteúdo vivo: itens novos publicados, listagens mortas removidas, preços e fotos atualizados
• Suporte respondido em horas, não em semanas, incluindo as mensagens irritadas
• Pagamentos monitorados e conciliados, reembolsos tratados, cobranças falhas acompanhadas
• Os pequenos ajustes que nunca entram num roadmap, mas decidem se um produto parece vivo ou abandonado

Como produtos morrem em silêncio

Produtos raramente morrem com uma queda dramática. Eles morrem em silêncio. Há um lançamento, talvez uma pequena comemoração, screenshots circulando. Depois as atualizações param. O último post no app é de quatro meses atrás. A página na loja diz que a última atualização foi há mais de um ano, ao lado de concorrentes atualizados na semana passada. Um botão que quebrou num celular novo continua quebrado, porque ninguém está olhando.

Usuários quase nunca reclamam na saída. Eles simplesmente param de abrir o app, e o produto continua existindo como um link levemente constrangedor na sua bio. Quando alguém percebe o silêncio, reviver o produto custa mais do que operá-lo teria custado, porque confiança é a única feature que não sai em release.

Por que agências não resolvem isso

O modelo padrão de agência é construído em torno da entrega. Ele precifica um escopo, constrói, entrega e move o time para o próximo projeto. Isso não é defeito de uma agência específica: é o formato do negócio. O contrato termina exatamente onde a vida real do seu produto começa.

Operação também é um músculo diferente de construção. Construção premia grandes arrancadas e finais claros. Operação premia rotina: ler logs numa terça-feira qualquer, publicar um release pequeno que ninguém pediu, responder a mesma dúvida de suporte com educação pela décima vez. Times montados para entregar raramente têm gente, preço ou motivação para esse trabalho, e é por isso que a entrega vira tantas vezes o começo do apodrecimento.

Como a Cazullo acabou operando software

A Cazullo não nasceu para vender operação. Acabamos operando software porque rodamos os nossos próprios produtos, mais de dez hoje, e ninguém mais ia responder por eles. Quando o seu próprio nome está na página da loja, você aprende rápido que o dia do lançamento é o dia fácil.

Operar os próprios produtos nos obrigou a construir para o dia seguinte ao lançamento: monitoramento que acusa erros antes dos usuários, rotinas de release que sobrevivem a atualizações de sistema, pipelines de conteúdo e painéis administrativos que um time pequeno e não técnico consegue de fato usar. Esse back office existe porque precisávamos dele para manter os nossos produtos vivos. Hoje oferecemos a mesma operação a clientes, porque a máquina já está rodando e adicionar um produto a ela custa muito menos do que montar uma operação do zero.

A realidade do orçamento

Operação é um custo recorrente, e deve ser planejada na mesma conversa da construção, não descoberta três meses depois do lançamento quando a primeira atualização de sistema quebra alguma coisa. Não vamos te dar uma porcentagem mágica, porque a resposta honesta é que depende do que o produto faz, de quantos usuários tem e de quão crítico ele é para o seu negócio.

O enquadramento que importa é mais simples: se o orçamento só cobre a construção, o orçamento não cobre o produto. Um orçamento só de construção compra um lançamento, não um ativo. Planeje uma linha recorrente desde o primeiro dia, dimensionada pela importância do produto, e trate como aluguel: não é opcional, não é surpresa.

Checklist antes de lançar

Antes de aprovar qualquer produto, coloque um nome real ao lado de cada uma destas perguntas:

• Quem publica o próximo release, e o seguinte?
• Quem lê os logs de erro toda semana, antes de os usuários reportarem?
• Quem responde o primeiro e-mail irritado de suporte, e em quanto tempo?
• Quem mantém o conteúdo vivo para o produto nunca parecer abandonado?
• Quem concilia pagamentos e trata reembolsos?
• Quem reage quando a loja de apps exige atualização para uma nova versão de sistema?
• Quem decide quais pequenos ajustes valem a pena neste mês?
• Existe uma linha recorrente no orçamento para tudo isso, acordada antes do lançamento?

Se alguma resposta for "a gente resolve depois", você não está pronto para lançar, ou deveria lançar com um parceiro que opera. Nossa recomendação é simples: trate a operação como parte do produto, contrate junto com a construção e aceite que um produto modesto com operação sólida vence um produto bonito por quem ninguém responde, todas as vezes.