Entrega de projeto freelance: o checklist final que transforma cliente em fonte de indicação

Você fechou o projeto, desenvolveu, o cliente aprovou. Aí você manda o link de produção, recebe a última parcela e some. Três meses depois, o pipeline está vazio de novo e você volta para o modo caçada: prospecção fria, propostas, follow-up. Se essa é a sua rotina, o problema não está em como você vende. Está em como você entrega. A entrega é o momento de maior confiança na relação com o cliente, e a maioria dos devs joga esse momento fora com um "qualquer coisa me chama".

Vou te falar como funciona do lado de quem recebe os leads: uma parte relevante dos projetos que chegam na OCA vem de indicação de cliente antigo. E indicação não acontece por acaso. Ela é consequência direta de como o projeto terminou, não só de como ele foi feito.

Por que a entrega vale mais que a proposta

A conta é simples. Conseguir um cliente novo exige presença online, propostas, calls, negociação. Cada lead frio que vira contrato custa horas que você não fatura. Uma indicação chega com a confiança pronta: o cliente já ouviu de alguém que você entrega. A conversão é maior, a negociação é mais curta e o cliente indicado briga menos por preço, porque ele não está comparando você com cinco orçamentos.

Só que existe uma janela. O cliente indica você nas semanas seguintes à entrega, enquanto o projeto está fresco e ele está contando para todo mundo que lançou o sistema. Se a sua última interação foi um deploy corrido e um boleto, é isso que ele vai lembrar quando alguém perguntar "conhece um dev bom?".

O que uma entrega profissional inclui (e quase ninguém faz)

Entregar não é dar deploy. É encerrar o projeto de um jeito que o cliente consiga operar sem você e, ao mesmo tempo, queira continuar com você por perto. Na OCA, todo projeto termina com o mesmo pacote, e ele cabe em qualquer projeto freelance:

1. Documento de entrega

Uma ou duas páginas, em português de gente, sem jargão. O que foi construído, o que ficou de fora do escopo (com referência à proposta original), onde cada coisa está hospedada, e quais contas e serviços estão no nome do cliente. Esse documento resolve dois problemas: protege você de "mas isso não estava incluído?" seis meses depois, e mostra ao cliente que ele contratou alguém organizado.

2. Acessos no nome do cliente

Domínio, hospedagem, banco, repositório, contas de API. Tudo em contas que o cliente controla, com você como colaborador, nunca o contrário. Dev que segura acesso como garantia de pagamento está criando um refém, não um cliente. E cliente refém não indica ninguém, ele avisa os amigos para tomarem cuidado.

3. Vídeo curto de walkthrough

Dez a quinze minutos de tela gravada mostrando o sistema funcionando: como acessar o painel, como fazer as operações do dia a dia, onde ver os dados. Um Loom resolve. Esse vídeo reduz drasticamente as mensagens de "como eu faço tal coisa?" e vira material que o cliente reencaminha para a equipe dele, com o seu nome junto.

4. Período de garantia definido por escrito

Trinta dias de correção de bugs sem custo é um padrão razoável para a maioria dos projetos. O ponto não é o prazo, é a clareza: bug de algo que estava no escopo entra na garantia, funcionalidade nova não entra. Sem essa linha escrita, todo pedido dos próximos seis meses vira uma negociação desconfortável.

5. Proposta de manutenção na mesa

A entrega é o melhor momento para oferecer um contrato de manutenção mensal. O cliente acabou de ver o sistema funcionando e sabe que não quer ficar sozinho com ele. Um valor mensal para monitoramento, pequenos ajustes e prioridade de atendimento transforma o fim do projeto no início de receita recorrente. Se ele recusar, tudo bem, mas a oferta precisa existir.

Como pedir indicação sem parecer desesperado

Aqui está a parte que trava a maioria dos devs. Pedir indicação parece coisa de vendedor, e dev odeia parecer vendedor. Só que existe um jeito de fazer isso que é só profissionalismo.

Duas ou três semanas depois da entrega, você manda uma mensagem de acompanhamento: pergunta se está tudo rodando bem, se a equipe se adaptou, se apareceu alguma dúvida. Isso já te diferencia de 90% do mercado. Se a resposta for positiva, você emenda algo nessa linha:

"Fico feliz que esteja rodando bem. Estou com agenda abrindo para o próximo trimestre, então se você conhecer alguém que precise de um sistema ou aplicativo, uma apresentação sua vale muito para mim."

Repare no que essa mensagem não faz: não pede favor, não oferece comissão logo de cara, não pressiona. Ela informa uma disponibilidade e dá ao cliente um jeito concreto de ajudar. Cliente satisfeito quer ajudar, ele só não sabe como, e ninguém pediu.

Nesse mesmo contato, peça um depoimento curto. Duas ou três frases sobre o problema que ele tinha e o resultado que teve. Isso vira prova social no seu portfólio e, na prática, o cliente que escreve um depoimento se compromete publicamente com a opinião de que você é bom. Ele indica mais depois disso.

Os erros que matam a indicação

• Sumir depois do último pagamento. O silêncio pós-entrega é lido como "ele só queria o dinheiro". A mensagem de acompanhamento de 15 dias custa dois minutos e muda a percepção inteira do projeto.
• Entregar sem documentar. Cliente que não sabe operar o próprio sistema vira cliente frustrado, mesmo que o código esteja impecável. E frustração é o que ele vai contar por aí.
• Tratar cada pergunta pós-entrega como interrupção. Se você respondeu com má vontade, a garantia virou atrito. Responder bem duas ou três dúvidas nas primeiras semanas é o investimento mais barato em reputação que existe.
• Não deixar a porta aberta para a fase 2. Todo projeto entregue gera ideias novas no cliente. Se você não perguntar "o que você imagina para os próximos meses?", outro dev vai perguntar.
• Prometer suporte eterno de graça. O extremo oposto de sumir. Sem limite claro, você vira o suporte gratuito vitalício do projeto e passa a atender com raiva. Garantia com prazo e contrato de manutenção resolvem isso.

Entrega bem feita é o que a gente procura em um parceiro

Isso não é teoria, é literalmente como a OCA cresceu. Aparecer no Google e nas IAs traz o lead, mas o que sustenta a operação é cliente antigo voltando e indicando. E é exatamente esse comportamento que a gente procura nos devs da nossa rede de parceiros.

Contexto rápido: a OCA recebe mais leads qualificados do que consegue atender, todos os dias. Nossa resposta foi montar uma rede de devs seniores de confiança que recebem projetos já vendidos, com escopo e orçamento fechados. O que a gente avalia antes de repassar um projeto não é só código. É se o dev documenta, se comunica prazo, se encerra o projeto de um jeito que o cliente final saia falando bem, porque o nome na mesa é o nosso também.

Se você leu este artigo e pensou "eu já faço a maior parte disso", você é o perfil que a gente quer conhecer. Se quiser ver o tipo de projeto que a gente constrói e repassa, o portfólio da OCA dá uma boa noção do nível.

Entre para a rede de parceiros da OCA

O próximo passo, com ou sem a OCA

Independente da rede, uma ação para esta semana: pegue o último projeto que você entregou e mande a mensagem de acompanhamento. Pergunte se está tudo rodando, ofereça resolver alguma dúvida pendente e mencione que sua agenda está abrindo. É uma mensagem, custa dois minutos, e é o teste mais barato que existe de tudo que está neste artigo. Se você já entrega bem, o seu problema não é técnico, é distribuição. E indicação é distribuição que você já pagou para ter.