Proposta de projeto freelance que fecha: a estrutura seção por seção que a OCA usa (e os erros que fazem o cliente sumir)

Você fez a call, o cliente gostou e disse que o projeto é prioridade. Você abriu um doc, listou as funcionalidades, colocou a stack, botou o preço no final e mandou o PDF. O cliente respondeu "vou analisar com o sócio". Faz duas semanas. Você já mandou um follow-up e nada.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E dentro de distribuição, a proposta é a peça mais malfeita do processo. A maioria dos devs trata proposta como orçamento: um número com uma lista de itens em volta. O cliente recebe três desses, não consegue avaliar nenhum tecnicamente e decide pelo único critério que ele entende. O preço.

A verdade desconfortável: o cliente não compra funcionalidade, compra segurança

Vou te falar como funciona do lado de quem recebe os leads: a OCA recebe dezenas de contatos por dia. Uma parte vira call. Uma parte das calls vira proposta. E o que decide se a proposta fecha quase nunca é o preço. É se o cliente leu a primeira página e pensou "essa pessoa entendeu o meu problema".

O cliente não sabe julgar se React Native é melhor que Flutter para o caso dele. Não sabe se 8 semanas é rápido ou lento. O que ele sabe é se você descreveu a dor dele melhor do que ele mesmo descreveria. Quando isso acontece, o preço vira detalhe de negociação. Quando não acontece, o preço vira o único assunto.

Isso muda a função da proposta. Ela não existe para informar o preço. Ela existe para provar que você entendeu, cercar o que vai ser feito e dar ao cliente um caminho óbvio para dizer sim.

A estrutura de proposta de projeto que a OCA usa

A proposta tem entre 2 e 4 páginas. Leva de 2 a 4 horas para escrever depois de uma call bem feita. Sai em até 48 horas depois da reunião, de preferência em 24. Se você precisa de mais tempo que isso, o problema foi a call, não a proposta. As seções, na ordem em que o cliente lê:

1. Diagnóstico: o parágrafo que fecha ou perde o projeto

Reescreva o problema do cliente com as palavras dele, mais organizadas do que ele conseguiria. Nada de "desenvolvimento de aplicativo mobile com backend escalável". É assim:

Hoje os pedidos da loja chegam pelo WhatsApp, são copiados para uma planilha e conferidos à mão antes de ir para a expedição. Isso gera cerca de 10 pedidos errados por semana e consome 3 horas por dia da pessoa que faz a conferência. O objetivo é tirar o WhatsApp do meio e ter o pedido entrando direto no sistema.

Os números vêm da call. Se você não os tem, a call foi rasa demais. Esse parágrafo é 80% da venda, e é exatamente a parte que quase ninguém escreve.

2. Objetivo: o que é sucesso em uma frase

Uma ou duas frases sobre como o cliente vai saber que deu certo. "Pedidos entrando sem digitação manual, com erro abaixo de 1%, até o fim do segundo mês de uso." Se dá para medir, melhor. Se não dá, descreva o comportamento esperado.

3. Escopo: em português, não em stack

Liste o que o sistema faz do ponto de vista de quem usa. "O cliente final escolhe produtos, monta o pedido e recebe confirmação por WhatsApp" vale mais do que "API REST com autenticação JWT". A stack entra em uma linha no final, para quem tiver curiosidade. Agrupe por módulo ou por perfil de usuário e mantenha cada item em uma linha. Se o escopo passa de uma página, o projeto está grande demais para uma proposta só e provavelmente precisa de uma fase de descoberta paga antes.

4. Fora do escopo: a seção que salva sua margem

Tudo que o cliente imaginou e você não escreveu vira obrigação sua na cabeça dele. Então escreva. Publicação nas lojas da Apple e do Google? Painel administrativo? Integração com o ERP? Migração dos dados antigos? Design das telas? Se não entra, diga que não entra e coloque ao lado o caminho para entrar depois: "pode ser orçado como fase 2". Na OCA, essa lista tem entre 5 e 10 itens em toda proposta. É a seção que mais evita conversa difícil no meio do projeto.

5. Como vai funcionar: ritmo e responsabilidades

Descreva o processo: entregas a cada 1 ou 2 semanas, demo ao final de cada ciclo, um único canal de comunicação. E escreva o que o cliente precisa fazer: enviar logo, textos e acessos até uma data, dar feedback em até 3 dias úteis por entrega. Isso não é burocracia. É o que permite você dizer, mais tarde, que o atraso não foi seu.

6. Prazo: semanas, marcos e condições

Prazo sempre em semanas, contado a partir do sinal e do recebimento dos materiais, dividido em marcos. Para um MVP de app com 4 a 6 telas e backend simples, algo entre 6 e 10 semanas em 3 marcos. Para um sistema web de gestão com dois ou três módulos, entre 8 e 16 semanas. O que move o número: integrações com terceiros, design pronto ou não, e velocidade de feedback do cliente. Diga isso na proposta.

7. Investimento: depois do valor, nunca antes

O preço vem na sétima seção por um motivo. Quando o cliente chega nele, já leu o diagnóstico, viu o escopo e entendeu o processo. Ele está comparando o número com o que vai receber, não com os outros dois PDFs.

Uma opção recomendada funciona bem. Duas ou três opções (essencial, recomendada, completa) funcionam melhor quando você sente que o cliente vai pedir corte. Mais que três paralisa. Na OCA, a maioria das propostas sai com duas: a versão que a gente recomenda e uma enxuta, com o que dá para tirar sem matar o produto.

Forma de pagamento entra aqui, em duas linhas: sinal de 30% a 40% para começar e o restante por marco de entrega. Nunca 100% no final. Um projeto de R$ 40 mil sem sinal significa você financiando o cliente por dois meses.

8. Premissas: o que você assumiu

Lista curta do que precisa ser verdade para o preço e o prazo valerem. "O cliente fornece o design das telas." "A API do ERP existe e tem documentação." "Os textos são entregues até o marco 1." Quando uma premissa cai, o escopo muda, e você tem a frase escrita que justifica a mudança de preço.

9. Próximo passo: validade e como dizer sim

Validade de 15 dias. O cliente que volta em 4 meses esperando o mesmo preço é um clássico. E a instrução exata para fechar: "Para começar, responda este e-mail com o OK na opção escolhida. Envio o contrato e a fatura do sinal no mesmo dia e agendamos o kickoff." Sem isso, o cliente lê, gosta e não sabe o que fazer com a informação.

Os erros que fazem o cliente sumir depois da proposta

• Preço na primeira página. O cliente lê o número, para de ler e vai comparar. Todo o resto virou anexo.
• Proposta que é lista de tecnologias. "React Native, Node.js, PostgreSQL, AWS" não diz nada para quem decide. Vira ruído e sinaliza que você não entendeu o negócio.
• Sem "fora do escopo". O projeto fecha e, na semana 5, o cliente pergunta onde está o painel admin que "obviamente" fazia parte.
• Prazo sem condição. "8 semanas" sem "a partir do sinal e dos materiais". O cliente demora 3 semanas para mandar o logo e o atraso vira seu.
• Proposta antes da call. O cliente pediu "só um valor" por mensagem e você mandou. Você precificou sem conhecer o problema e agora está preso ao número.
• Quinze páginas com "quem somos" na frente. Ninguém lê. Prova social entra no final, em três linhas e um link para o portfólio.
• Enviar e esperar. Mande o PDF e proponha 20 minutos para passar junto. É nessa call que a objeção aparece e você responde na hora, em vez de descobrir semanas depois que o cliente travou em um detalhe bobo.

Como isso mudou a conversa na OCA

Quando a gente passou a colocar o diagnóstico antes de qualquer outra coisa, a reação do cliente mudou de "está caro" para "faz sentido, dá para começar com menos?". A segunda pergunta é uma negociação de escopo. A primeira é uma negociação de preço. Você quer sempre estar na segunda.

O mesmo vale para o "fora do escopo". Nos projetos em que a gente listou tudo que não entrava, as mudanças no meio do caminho viraram orçamento de fase 2. Nos projetos em que não listou, viraram desgaste e trabalho não pago. A conta é simples: 2 horas a mais escrevendo a proposta, ou 20 horas a mais fazendo de graça.

Onde entra a rede de parceiros da OCA

A OCA aparece no Google e nas IAs para quem procura desenvolvimento de software no Brasil. Isso traz mais projeto do que o time consegue atender. A resposta foi montar uma rede de devs seniores e times pequenos que recebem projetos já qualificados: cliente real, call feita, escopo cercado.

O que a gente espera de um parceiro: entrega consistente, comunicação clara com cliente não técnico e capacidade de escrever proposta e cercar escopo do jeito que descrevi acima, porque em muitos projetos a fase 2 e as mudanças no meio do caminho passam pelo parceiro. O que o parceiro recebe: projetos que já passaram pelo filtro, sem disputa de preço com plataforma gringa e sem semanas gastas em proposta que não fecha. A rede não é fila de espera nem promessa de projeto todo mês. É um filtro dos dois lados.

Entre para a rede de parceiros da OCA

O que fazer esta semana

Pegue a última proposta que você mandou e não fechou. Corte a primeira página e escreva no lugar um parágrafo de diagnóstico com o problema do cliente, com número, do jeito que ele contaria. Depois adicione uma seção "Fora do escopo" com pelo menos cinco itens. Só isso já muda a leitura. Se quiser ver como a OCA apresenta projeto para cliente, os cases estão no portfólio da OCA.