Índice do artigofaltam 7 min de leitura
Você tem um valor para investir em software. A pergunta que decide o destino do produto não é com quem gastar, nem quanto gastar. É quanto gastar agora e quanto guardar para os dez meses seguintes.
Esta conversa acontece toda semana. Alguém com um orçamento definido recebe duas propostas: uma que entrega mais coisa por um valor mais alto, e outra que entrega o mesmo por menos, com um valor mensal de manutenção baixo. A segunda parece obviamente melhor.
Este artigo é sobre por que ela normalmente não é, e sobre a conta que quase ninguém faz antes de assinar.
Resumo do artigo
- Gastar o orçamento inteiro na versão 1.0 entrega um produto completo do qual nenhum usuário real participou.
- Como referência de planejamento, cerca de 40% do orçamento na primeira versão e 60% nos meses seguintes é uma divisão mais segura que o oposto.
- A densidade de melhorias é máxima logo depois do lançamento, e é exatamente quando o caixa costuma ter acabado.
- Custo de infraestrutura escala com o número de usuários. Custo de desenvolvimento não, e por isso manutenção que "escala conforme a demanda" costuma ser uma conta mal montada.
A conta que quase todo fundador faz errado
Vale desarmar a leitura mais provável deste título: isto não é um argumento para pagar menos, nem para negociar desconto. O valor total investido pode ser exatamente o mesmo. O que muda é a distribuição dele no tempo.
Quem gasta tudo na primeira versão compra a coisa mais cara que existe em software: um produto completo construído inteiramente a partir de suposições. Todas as telas foram desenhadas antes de qualquer pessoa usar. Todos os fluxos foram decididos por quem conhece o problema, não por quem tem o problema. E, quando os primeiros usuários finalmente chegam e apontam o que está errado, não há mais orçamento para mudar.
O que isso destrava, quando invertido: a mesma quantia, dividida de outro jeito, compra um produto menor no lançamento e a capacidade de melhorá-lo com informação real durante quase um ano.
A demanda por mudança é maior no começo, não menor
Este é o ponto mais contraintuitivo da conversa, e o que mais aparece como objeção: "no começo eu tenho zero clientes, então não vou precisar de suporte".
A intuição confunde dois volumes diferentes. O volume de chamados realmente cresce com a base de usuários. Mas a densidade de descoberta faz o caminho oposto: uma versão 1.0 é o momento em que existe mais coisa errada por usuário, porque nada foi validado ainda. Dez pessoas usando um produto novo geram mais decisões de produto do que mil pessoas usando um produto maduro.
O resultado prático é desconfortável: o período em que a evolução mais importa é justamente aquele em que o fundador acha que não vai precisar dela, e é onde ele planeja não ter caixa.
Manutenção e evolução não são a mesma linha
Duas coisas muito diferentes viajam com o mesmo nome em proposta comercial, e comparar propostas sem separá-las produz decisão ruim.
Manutenção é reativa. Ela conserta o que quebrou, atualiza dependência, responde a incidente e mantém o que já existe funcionando. É trabalho necessário e o escopo dele é preservar.
Evolução contínua é dirigida por uso real. Ela muda a ordem das telas porque as pessoas se perdiam, corta o recurso que ninguém abriu, constrói o que dez clientes pediram na mesma semana e ajusta preço e embalagem porque a venda não estava fechando. O escopo dela é transformar.
Uma proposta de manutenção barata não é desonesta: ela está cotando a primeira coisa. O problema aparece quando o comprador achou que estava comprando a segunda.
Orçamento todo na v1
Produto grande, nenhum usuário dentro- Escopo decidido só por suposição
- Lançamento tarde, com tudo pronto de uma vez
- Sem caixa quando surge a primeira correção de rumo
- Recursos construídos que ninguém abre
V1 enxuta e operação longa
Produto menor, moldado por quem usa- Escopo inicial cortado ao núcleo que vende
- No ar cedo, com clientes reais mais cedo
- Caixa disponível exatamente quando as melhorias aparecem
- Cada mês de operação decide o mês seguinte
Custo de servidor escala com usuário. Custo de software não.
Existe um modelo comercial comum que soa justo e não fecha: manutenção mensal baixa que "escala conforme a demanda de usuários". Vale separar o que de fato escala do que não escala.
Infraestrutura escala. Servidor, banco de dados, tráfego, armazenamento e disparo de mensagem crescem com a base. Cobrar mais por mais usuários faz todo sentido nessa linha, e é assim que a nuvem cobra de você.
Desenvolvimento não escala assim. Construir um recurso custa o mesmo esforço para atender dez pessoas ou dez mil. E o suporte por usuário tende a ficar mais barato conforme a base cresce, porque as mesmas dúvidas se repetem, viram documentação, viram melhoria de produto e param de chegar.
Quando um contrato de desenvolvimento é cotado como se fosse infraestrutura, uma das duas pontas está errada: ou o valor inicial é baixo demais para o trabalho real, ou o reajuste por usuário vai cobrar por um custo que não existe.
Os primeiros usuários são o time de produto que você não pode contratar
Há um ganho nessa inversão que raramente entra na planilha, e ele é comercial, não técnico.
Um cliente que aceita usar uma solução desconhecida está assumindo risco. O que ele recebe em troca, quando o produto ainda está sendo moldado, é influência: ele pede, aquilo aparece, e o produto passa a se parecer com a operação dele. Isso aumenta retenção por um motivo simples, que é ele ter participado da construção, e transforma os primeiros clientes nas melhores referências de venda que vão existir.
Um produto lançado pronto e fechado não oferece nada disso. Ele chega ao primeiro cliente como mais um fornecedor genérico, competindo por preço com quem já está estabelecido.
Como dividir o orçamento na prática
Vale um exemplo com números redondos, como referência de planejamento e não como tabela de preço. Um fundador com R$ 60 mil reservados para software.
| Fase | Escopo | Recorrência | Valor |
|---|---|---|---|
| Núcleo operacionalO mínimo que permite cobrar do primeiro cliente | Único | ~ R$ 24.000 | |
| Operação e evoluçãoCerca de dez meses moldando o produto com uso real | Mensal | ~ R$ 36.000 | |
| Mesmo orçamento, outra distribuição | R$ 60.000 |
Faixas de exemplo para ilustrar a proporção. O valor real depende do escopo do núcleo e do ritmo de operação contratado.
A leitura da tabela é a única coisa que importa aqui: os dois cenários gastam o mesmo. Um entrega um produto grande no mês seis, sem cliente. O outro entrega um produto pequeno no mês dois e passa dez meses melhorando com quem paga.
O breakeven é mais perto do que a planilha sugere
A objeção seguinte costuma ser sobre o custo mensal comer o caixa antes de o produto captar clientes. Ela merece ser respondida com conta, não com opinião.
Se o produto é cobrado a R$ 400 por mês por cliente, um custo de operação nessa faixa se paga com cerca de dez clientes. Não é uma meta trivial, mas está longe de ser impossível para um produto que já está no ar e sendo ajustado. E a mesma conta, feita antes do lançamento, tende a ser pessimista: ela assume o preço da versão 1.0, que é justamente o que a operação existe para melhorar.
O que perguntar a quem ofereceu manutenção barata
A proposta de mensalidade baixa pode ser a certa para o seu caso. O que separa uma escolha informada de uma surpresa é fazer estas perguntas antes de assinar.
- O que exatamente está incluído: só corrigir defeito, ou também construir o que os clientes pedirem?
- Quantas horas de desenvolvimento por mês esse valor comporta, e o que acontece quando estouram?
- Qual o prazo de resposta combinado, e o que acontece se o sistema cair num sábado?
- Quem responde se a pessoa que construiu sair, e o código está documentado para outra equipe assumir?
- O contrato prevê o que acontece se eu quiser levar o produto para outro fornecedor?
A última é a mais reveladora. Um fornecedor que responde bem a ela está confortável com a possibilidade de você sair, o que costuma indicar que ele não depende de dependência para manter o contrato.
O produto bom não nasce na versão 1.0
A história dos produtos que viraram referência conta sempre o mesmo enredo, e ele não é sobre a primeira versão ser boa. O Facebook nasceu como um diretório de perfis de uma universidade. O Airbnb nasceu como uma página para alugar colchões infláveis, com o nome escrito por extenso. O Uber nasceu como um serviço de carro preto sob demanda em uma cidade só, chamado UberCab.
Se qualquer um deles tivesse gasto todo o dinheiro deixando aquela primeira versão perfeita, teria conseguido apenas uma versão perfeita de algo que não era o produto final. O que os transformou foi o tempo depois do lançamento, e a capacidade de continuar mudando durante ele.
É essa capacidade que o orçamento precisa preservar. Não porque a primeira versão não importa, mas porque ela é o começo da descoberta, e não o fim dela.
Vai tirar um produto do zero e quer distribuir o orçamento certo?
Solicite um orçamento e comece pelo núcleo que permite cobrar do primeiro cliente.
Perguntas frequentes
Como referência de planejamento, algo em torno de 40% do que você tem para software, deixando os outros 60% para os meses seguintes de evolução. A proporção exata muda por projeto, mas gastar tudo na versão 1.0 é o padrão que mais quebra produto novo.
Não. Manutenção é reativa: conserta o que quebrou. Evolução contínua é mudar o produto com base no que os primeiros usuários fizeram. A primeira preserva o que existe, a segunda é o que transforma a versão 1.0 em produto competitivo.
É o contrário. Uma versão 1.0 é onde há mais oportunidade de melhoria por usuário, porque nada foi validado ainda. O volume de chamados cresce com a base, mas a densidade de descoberta é máxima no início e cai com o tempo.
É sinal de que o escopo daquele contrato é reativo, não evolutivo. Não é necessariamente desonesto: é outro produto. O risco é descobrir isso quando você precisar de uma mudança de verdade e ela não couber no contrato.
Para custo de infraestrutura, sim: servidor, banco e tráfego crescem com a base. Para custo de desenvolvimento, não. Construir um recurso custa o mesmo para atender dez ou dez mil pessoas, e o suporte por usuário tende a ficar mais barato conforme a base cresce.
É um caminho possível e troca um custo por um risco de gestão. Você passa a coordenar prioridade, prazo, qualidade e continuidade, num momento em que sua atenção deveria estar em conseguir os primeiros clientes.
Fontes e método
O raciocínio deste artigo vem da prática comercial e de entrega da X-Apps com produtos construídos do zero, incluindo negociações em que essa mesma discussão de alocação de orçamento aconteceu. Os casos e interlocutores foram despersonalizados, e os valores aparecem como faixas de exemplo para ilustrar proporção, não como tabela de preço nem como média medida.
As referências ao histórico de Facebook, Airbnb e Uber tratam de fatos amplamente documentados sobre as primeiras versões desses produtos e servem como ilustração do argumento, sem qualquer relação comercial com a X-Apps.
