Sinais de que você está pronto para atender clientes por conta própria (e os que indicam que ainda não)

Tem uma pergunta que aparece direto na minha caixa de mensagens: "Lucas, será que eu já estou pronto para pegar cliente por conta própria?" Quase sempre quem pergunta é um dev que entrega bem no emprego, resolve ticket difícil, carrega feature sozinho. Tecnicamente, pronto. Mas atender cliente direto não é uma prova técnica. É outro jogo, com outras regras, e a maioria dos devs descobre isso da pior forma: dentro de um projeto que já assinou.

Na OCA, além de tocar nossos próprios projetos, a gente repassa demanda para uma rede de devs parceiros. Isso significa que eu avalio devs para essa função o tempo todo. Vou te falar como funciona do lado de quem recebe os leads: os sinais que me fazem confiar um projeto a alguém quase nunca são os que o próprio dev acha que importam.

A verdade desconfortável: código é o critério de corte, não o de aprovação

Todo dev que chega até mim sabe programar. Sério, todos. Saber React, Node, Flutter, o que for, é o mínimo para entrar na conversa, não o que decide. O que decide é se você consegue carregar um projeto inteiro: entender o problema do cliente, cercar escopo, comunicar atraso, cobrar, entregar e dar manutenção sem que ninguém precise ficar em cima.

Isso não é teoria, é literalmente como a OCA cresceu. Quando a gente construiu o Revo, plataforma com mais de 40 mil usuários, o código foi talvez 60% do trabalho. O resto foi decisão de produto, priorização, conversa difícil, suporte. Cliente direto compra esse pacote inteiro. Se você só vende a parte do código, você não está vendendo um projeto, está vendendo mão de obra, e mão de obra o cliente encontra mais barata em qualquer lugar.

Sinais de que você está pronto

1. Você já entregou algo de ponta a ponta, mesmo que pequeno

Não precisa ser um produto com milhares de usuários. Precisa ser algo em que você tocou tudo: levantou requisito, decidiu arquitetura, publicou, corrigiu bug em produção, conversou com quem usa. Pode ser um sistema interno da empresa onde você trabalha, um projeto próprio, um freela pequeno. O ponto é: você já sentiu o peso de ser o único responsável quando algo quebra às 23h de sexta.

2. Você consegue explicar decisão técnica para quem não é técnico

Teste rápido: explique para alguém leigo por que o projeto dele deveria começar com um MVP menor do que ele imaginou. Se a sua explicação depende de jargão, você ainda não está pronto. Cliente direto não avalia sua arquitetura, avalia se confia em você. E confiança nasce de clareza. Os melhores parceiros que a OCA tem são os que transformam "vamos usar fila assíncrona para desacoplar o processamento" em "o sistema não trava quando entrar muita gente ao mesmo tempo".

3. Você já disse não para escopo

Se você nunca falou "isso fica de fora desta fase" para alguém, você vai sofrer. Cliente sempre quer mais, e não é por má fé, é porque ele não sabe o custo do que pede. O dev pronto para atender direto tem o reflexo de cercar: "cabe, mas muda prazo e preço, quer que eu orce?". O dev que não está pronto responde "deixa comigo" e paga com as próprias noites.

4. Você tem reserva para aguentar 3 meses sem receber

A conta é simples. Projeto freelance tem ciclo: proposta, negociação, sinal, entrega, pagamento final. Entre fechar um projeto e o dinheiro cair, passam semanas. Entre um projeto e o próximo, também. Se um mês sem receita te coloca em pânico, você vai aceitar projeto ruim por desespero, e projeto aceito por desespero é onde todo calote e todo escopo aberto moram. Reserva não é frescura financeira, é ferramenta de negociação.

5. Você responde mensagens como profissional, não como colega

Parece bobo, mas elimina mais gente do que qualquer teste técnico. Cliente mandou mensagem terça, você respondeu quinta sem contexto? Do lado de quem repassa projeto, isso é desclassificatório. Não porque exigimos resposta imediata, mas porque comunicação previsível é o que segura a relação quando o projeto aperta. Quem some no dia bom, some no dia ruim.

Sinais de que ainda não é a hora (e o que fazer sobre cada um)

• Você nunca cobrou por nada. Se todo código que você escreveu fora do CLT foi de graça, comece cobrando pouco de alguém. O primeiro "me paga X por isso" destrava mais do que qualquer curso. O valor pode estar errado, a experiência de cobrar não tem substituto.
• Você trava em conversa de dinheiro. Ensaie. Escreva o preço antes da call, fale o número e fique em silêncio. Se você preenche o silêncio com desconto, o problema não é o mercado, é o roteiro.
• Você não tem nem um projeto que possa mostrar. Portfólio não precisa de dez cases, precisa de um bom, descrito do jeito certo: problema, o que você fez, resultado. Sem isso, você pede confiança sem oferecer prova.
• Você depende de alguém para decidir arquitetura. Normal em time, fatal sozinho. Antes de atender direto, force situações onde a decisão é sua: um projeto pessoal publicado resolve.
• Você acha que contrato é formalidade. Não está pronto quem nunca leu uma cláusula de propriedade intelectual ou de garantia. Não precisa de advogado no início, precisa de um modelo decente e do hábito de nunca começar sem assinatura.

O teste prático: o projeto sombra

Quer um jeito honesto de se avaliar sem arriscar reputação? Faça um projeto sombra. Pegue um pedido real, pode ser de um grupo de freelas, um conhecido, um edital, e conduza tudo como se fosse fechar: escreva a proposta, defina escopo, monte cronograma, precifique. Não precisa nem enviar.

Depois responda: quanto tempo levou para escrever a proposta? Você soube dar preço ou chutou? O escopo que você escreveu aguentaria um cliente pedindo "só mais uma coisinha"? Se o exercício inteiro saiu razoável em poucas horas, você está mais pronto do que imagina. Se você travou no preço ou escreveu um escopo de duas linhas, ótimo: descobriu o gap sem custar um cliente real.

Você não precisa pedir demissão para começar

Um erro clássico é tratar isso como decisão binária: ou CLT ou freelance, tudo ou nada. Não é. Os devs mais bem-sucedidos que conheço fizeram transição em camadas: primeiro projeto pequeno no fim de semana, depois um contrato de manutenção recorrente, depois a conta de quando a renda de fora cobre o essencial. Cada camada gera prova: prova para o mercado de que você entrega, e prova para você mesmo de que aguenta o jogo.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E distribuição se resolve de dois jeitos: construindo sua própria presença, o que leva meses, ou se conectando a quem já tem demanda sobrando.

Onde a OCA entra nessa história

Aqui vai a parte que me interessa diretamente. A OCA aparece no Google e nas respostas das IAs para buscas de desenvolvimento de software no Brasil, e isso gera dezenas de leads de clientes por dia, mais do que nosso time consegue atender. Nossa resposta foi montar uma rede de parceiros: devs e times pequenos que recebem projetos já qualificados, com escopo cercado e cliente educado sobre prazo e preço.

O que a gente procura é exatamente o que este artigo descreveu: gente que entrega de ponta a ponta, comunica bem, respeita escopo e trata o cliente como profissional. Você pode ver o tipo de projeto que a gente toca no portfólio da OCA. Não prometo volume nem aprovação automática, seria desonesto. Prometo que projeto repassado pela OCA chega limpo: sem leilão de preço, sem cliente fantasma, sem escopo infinito.

Entre para a rede de parceiros da OCA

Uma ação para esta semana, independente de tudo

Faça o projeto sombra. Escolha um pedido real de software, escreva a proposta completa com escopo, prazo e preço, e cronometre. O documento que sair desse exercício vale mais do que qualquer autoavaliação: ele mostra, no papel, exatamente onde você está pronto e onde ainda falta. E se o resultado te surpreender positivamente, você já sabe onde me encontrar.