Como vender software: comece com um piloto pago

Por que isso importa

Um cliente pagar por uma solução ainda não construída é uma evidência interessante. Mas há uma distância entre conseguir uma encomenda e encontrar um produto que várias empresas vão contratar. Para quem desenvolve software e quer vender o próprio trabalho, essa diferença determina o que merece virar código reutilizável e o que continuará exigindo atendimento individual.

Bgo defende vender antes de construir e diz ter encontrado esse padrão em mais de mil desenvolvedores. No material apresentado, porém, não há uma base consultável com critérios de seleção, casos que fracassaram e comparação com outras estratégias. Eu trataria a afirmação como argumento do autor, sem dar a ela o peso de uma pesquisa que demonstra como enriquecer.

A parte que considero aproveitável é transformar interesse em um compromisso comercial verificável. Minha ressalva está no passo seguinte: receber dinheiro valida uma oferta inicial, mas ainda deixa em aberto o custo de entregar, a possibilidade de repetir e a disposição do cliente para renovar. É nesses três pontos que eu concentraria o primeiro piloto.

Pontos principais

• 0:33 O autor coloca a venda antes do desenvolvimento. Para aplicar a ideia, o comprador precisa saber o que existe hoje e o que será construído; o pagamento deve corresponder a uma entrega futura claramente descrita.
• 1:39 Programar aparece como uma forma de evitar a rejeição comercial. O alerta útil é observar se cada nova funcionalidade resolve uma objeção real ou apenas adia a primeira conversa com um comprador.
• 2:43 Bgo sugere procurar orçamento existente e investigar tentativas anteriores de resolver o problema. Esse histórico ajuda a encontrar despesas substituíveis, embora gastar hoje não signifique ter autorização para contratar outra solução.
• 3:50 A oferta passa a ser um resultado com prazo e preço. Isso exige escolher uma mudança observável: uma fila processada ou uma rotina concluída é mais fácil de verificar que uma promessa ampla de melhorar a operação.
• 4:22 A garantia é apresentada como pouco custosa para quem sabe desenvolver. Eu discordo dessa simplificação: reembolsar o cliente não recupera suas horas, despesas com fornecedores ou trabalho comercial.
• 4:56 O vídeo propõe três clientes com a mesma oferta ou US$ 15 mil de receita recorrente mensal como sinal para aumentar o compromisso. São referências do autor; três projetos muito diferentes ainda podem representar apenas três encomendas.
• 5:31 A expansão comercial vem depois desse sinal inicial. Minha leitura é acrescentar uma verificação de margem, uso e renovação antes de investir mais tempo na aquisição de clientes.

Como aplicar

Como vender software com um piloto verificável

Eu começaria por um processo pequeno e frequente. Exemplo hipotético: uma distribuidora recebe pedidos por e-mail e alguém passa parte do dia conferindo se os dados foram lançados corretamente no sistema. A primeira oferta pode cobrir apenas a conferência de um formato de pedido, em uma unidade da empresa, durante duas semanas.

Esse recorte ajuda a distinguir uma venda de software de um projeto aberto de desenvolvimento. O comprador consegue avaliar uma entrega delimitada, e você consegue descobrir quanto trabalho ela exige antes de assumir um compromisso maior.

1. Investigue a última ocorrência

Converse com quem executa a tarefa e com quem aprova a despesa. Use perguntas sobre fatos recentes:

• Na última vez que isso aconteceu, quem precisou intervir?
• Quanto tempo levou e qual foi a consequência?
• O que vocês já contrataram ou tentaram para resolver?
• Quem poderia aprovar um piloto e em qual momento?

Peça para acompanhar um exemplo do processo, usando dados fictícios ou uma amostra adequada à demonstração. A validação de ideias melhora quando você observa as exceções que a descrição inicial costuma esconder: arquivos incompletos, pedidos duplicados e regras conhecidas apenas por uma pessoa.

Histórico de gasto é uma pista. Também pode haver uma oportunidade onde ninguém comprou uma ferramenta, mas funcionários dedicam horas ao trabalho. Nesse caso, ainda falta demonstrar prioridade e disposição para pagar. Tempo liberado representa capacidade disponível; só vira economia de caixa se alguma despesa realmente diminuir.

2. Escreva a oferta em uma página

Descreva o processo incluído, o volume atendido, os acessos necessários, a participação do cliente e a forma de conferir o resultado. Separe explicitamente o que já funciona do que será desenvolvido.

Para a distribuidora, um critério hipotético seria: comparar os pedidos de um único modelo com os registros exportados do sistema e listar divergências para revisão humana. O piloto termina com uma comparação entre a conferência manual e a assistida. Não depende de prometer aumento de faturamento.

Faça uma verificação técnica curta antes de definir prazo e preço. Confirme se a exportação existe, se os campos necessários estão disponíveis e se há acesso autorizado. Vender primeiro não obriga ninguém a assumir uma integração desconhecida sem investigar sua viabilidade.

3. Calcule o custo da experiência

Considere um piloto ilustrativo de R$ 2.500. Se ele consumir 20 horas avaliadas internamente a R$ 80 e R$ 200 em infraestrutura, restam R$ 700 antes de impostos, aquisição do cliente e outras despesas. Se consumir 35 horas, o custo dessas horas mais a infraestrutura já chega a R$ 3.000.

O exercício serve para definir um limite de esforço e perceber cedo quando o escopo deixou de caber no preço. Registre também horas de reunião, implantação e suporte. Elas fazem parte da entrega, mesmo quando não geram nenhum commit.

Se oferecer reembolso, descreva o critério de aceitação e mantenha disponível o valor que pode precisar devolver. Uma garantia pode facilitar a decisão do comprador, mas precisa caber no seu caixa e no seu calendário.

4. Separe serviço inicial de assinatura

O guia indicado na descrição hoje se apresenta como material para engenheiros dispostos a começar por serviços. Essa informação ajuda a interpretar a proposta do vídeo: conseguir um cliente para uma entrega personalizada pode ser o começo de uma consultoria, mesmo que exista software na solução.

No piloto, registre separadamente implantação e operação contínua. Se houver mensalidade, explique o que ela cobre depois da entrega: processamento recorrente, hospedagem, acompanhamento ou suporte com limites definidos. Um projeto parcelado continua sendo um projeto; as parcelas não demonstram demanda recorrente por si mesmas.

5. Compare os próximos compradores

Use uma tabela simples para avaliar a repetição da oferta:

| Evidência | O que registrar | |---|---| | Compra | Quem aprovou e por que comprou agora | | Entrega | Horas, custos e exceções encontradas | | Reutilização | O que funcionou sem alteração no próximo cliente | | Continuidade | Uso após a implantação e decisão de renovar |

Antes de criar uma plataforma, tente vender o mesmo recorte a outra empresa independente. Observe se o resultado prometido permanece igual ou se cada conversa exige uma solução nova.

Meu critério para investir mais seria conseguir repetir a entrega com esforço previsível e identificar uma razão concreta para o cliente continuar pagando. Três clientes podem justificar a próxima experiência. A transformação em produto depende do que você aprende ao atendê-los.