Como contratar um desenvolvedor para startup: o playbook do fundador não-técnico

Um guia prático e opinativo para fundadores não-técnicos. Cobre quando não contratar, como escrever um briefing, como entrevistar sem fingir profundidade técnica, quanto pagar, e como evitar os quatro principais modos de quebra da relação.

A versão curta, para quem caiu aqui com pressa: antes de contratar um desenvolvedor para a sua startup, escreva um briefing de uma página, decida se o que você precisa é uma contratação ou um sócio de entrega, e rode uma semana de teste paga. Três desses quatro passos não custam nada, e a maior parte dos fundadores pula os três. É por isso que essas contratações dão errado.

A versão longa está abaixo. Estivemos do outro lado dessa conversa com dezenas de fundadores não-técnicos nos últimos anos, e os padrões são consistentes o bastante para valer a pena escrever.

Decida primeiro: contratar, freelance, ou sócio de entrega

A maior parte dos fundadores formula a pergunta como quem eu contrato?. A pergunta melhor é que tipo de relação eu de fato preciso?. Existem três opções, e elas não se substituem.

A primeira é uma contratação full-time — geralmente um engenheiro sênior ou tech lead, às vezes um CTO. Faz sentido quando você tem volume de engenharia previsível e estável, orçamento para sustentar salário e equity por pelo menos dezoito meses, e a banda para gerir alguém cujo trabalho você não consegue avaliar diretamente.

A segunda é um freelancer ou contratado fracionado. Faz sentido para trabalho específico, com prazo definido — uma integração com Stripe, uma migração de dados, uma feature pontual — onde a spec é clara e a relação pode terminar limpa. É um péssimo encaixe para “construa minha startup”, porque freelancers otimizam para terminar, e o fundador precisa de alguém que otimize para acertar o que vai ser construído.

A terceira é um sócio de entrega — um time pequeno e sênior que escopa, constrói e entrega sob uma única responsabilidade. Faz sentido para fundadores não-técnicos que não têm um co-founder técnico claro, querem lançar um produto real em quatro a nove meses, e ainda não têm volume de engenharia constante para manter um time interno produtivo. O modelo troca um custo por mês maior por um custo por funcionalidade muito menor, e remove o overhead de gestão de uma contratação.

Há uma quarta opção que fundadores às vezes tentam, que é “um desenvolvedor júnior dedicado”. Mencionamos só para desencorajar. Um júnior precisa de revisão sênior para crescer. Um fundador não-técnico não consegue oferecer essa revisão. O resultado é dívida técnica que se acumula invisível, e o fundador descobre doze meses depois.

Se você não tem certeza de qual opção encaixa, o teste é: se um engenheiro sênior entrasse amanhã, o que eu colocaria nele no primeiro mês? Se a resposta cabe em um parágrafo, você precisa de uma contratação ou freelancer. Se não cabe, você precisa de um sócio — porque o que falta não é um par de mãos. É clareza sobre o que construir.

Quanto pagar

As faixas abaixo são números de 2026 para os mercados norte-americano e brasileiro. Vão flutuar; as formas relativas, não.

Para um engenheiro de software sênior full-time nos EUA (mid-career, quatro a oito anos de experiência, full-stack, capaz de entregar sem supervisão), espere US$ 160–220 mil de salário base mais equity. Para um sênior no Brasil com experiência comparável, espere R$ 18–35 mil por mês CLT, ou cerca de R$ 25–45 mil/mês como PJ. Uma primeira contratação de CTO — a rara feita em estágio seed — costuma adicionar 10 a 25% no caixa e 10 a 25% em equity sobre o que pagaria a um engenheiro sênior.

Para freelancers, hourly rates variam entre US$ 60–180 nos EUA e R$ 150–400 no Brasil para gente sênior. Abaixo dessas faixas, ou você está pagando por alguém júnior, ou por alguém sênior nos engagements em que você não quer estar. Desenvolvedores offshore fora do Brasil têm faixas amplas; os que valem a pena na faixa US$ 25–40/hora existem mas são difíceis de encontrar sem rede de indicação, e a taxa de fracasso de contratação fria por marketplace nesse ponto é alta.

Para um sócio de entrega, uma primeira versão típica fica entre US$ 80–250 mil ao longo de quatro a nove meses, dependendo do escopo. Um time de dois a quatro engenheiros sêniores mais suporte de design é o formato usual. A comparação econômica que os fundadores deveriam fazer não é “custo do parceiro vs salário do desenvolvedor” — é “quanto custa para mim entregar o mesmo produto, na mesma qualidade, na mesma data, com o time que de fato consigo contratar?”. Quando se faz essa conta com honestidade, o parceiro costuma ser a opção mais barata para os primeiros dezoito meses.

Escreva o briefing antes do anúncio da vaga

A maior razão pela qual essas contratações falham é que o fundador contrata antes de decidir o que está contratando. Um briefing é a apólice de seguro mais barata que você vai comprar este ano. Gaste um final de semana nele.

Um briefing útil, em uma página, contém:

O cliente em uma frase — quem é, o que faz hoje em vez disso, por que mudaria. O produto em um parágrafo — o que faz, em linguagem que um leitor não-técnico repetiria. O escopo mínimo de um primeiro lançamento — três a cinco capacidades, no máximo, ranqueadas por qual prova a tese mais rápido. As integrações e restrições — com que outros sistemas tem que conversar, que regulação se aplica (LGPD, HIPAA, SOC 2), que plataformas (web, iOS, Android). A métrica de sucesso — uma métrica, com limiar, com data. Os não-objetivos — três coisas que você deliberadamente não vai construir agora, para não ter que defender a escolha em toda sprint.

Se você não consegue preencher um desses campos, o gap não é de engenharia. É de produto ou comercial. Contratar um desenvolvedor para preencher um gap de produto é a forma mais cara de descobrir esse fato.

Como entrevistar quando você não consegue ler o código

O problema da entrevista técnica para fundadores não-técnicos é real, e a maior parte do conselho publicado não ajuda. Você não consegue rodar um screening de código. Não consegue avaliar um system design. O candidato pode passar por ambos blefando, e você não vai perceber.

O que você pode fazer são três checagens que não exigem profundidade técnica, e juntas são surpreendentemente diagnósticas.

Leitura do briefing. Mande o briefing de uma página antes da entrevista. Na primeira reunião, peça que ele te explique como abordaria os primeiros noventa dias. O sinal que você quer não é “ele tem a resposta certa”. Geralmente não há resposta certa nesse estágio. O sinal é: ele faz perguntas mais afiadas sobre o briefing do que você já ouviu? Um engenheiro sênior lendo um briefing pela primeira vez deveria expor pressuposições que você não sabia que estava fazendo. Um júnior ou genérico vai pular as pressuposições e te dizer o que construir. A pergunta é a habilidade.

Reference check que não é protocolar. Pegue dois dos referidos — idealmente um ex-gestor e um ex-par — e tenha uma conversa real de vinte minutos, não um checklist de cinco. A melhor pergunta a fazer: se você fosse abrir uma empresa amanhã e pudesse contratar um engenheiro do time, ele estaria na shortlist?. Observe a pausa antes da resposta. A pausa importa mais que a resposta.

Semana de teste paga. Esse é o passo de maior sinal em todo o processo, e o que mais fundadores se recusam a rodar, porque parece um movimento de poder estranho. Pague o pro-rata semanal do candidato para fazer um pedaço real de trabalho — uma tarefa pequena, contida, do briefing real, idealmente com uma pequena ambiguidade embutida. No fim da semana você tem ou trabalho entregue, ou uma pergunta cuidadosa sobre a ambiguidade, ou um prazo perdido. Qualquer uma das três é mais útil que outra entrevista de duas horas.

Se você não consegue rodar um teste — porque o candidato está empregado em tempo integral em outro lugar — o substituto é pedir que ele percorra, em screen-share, o pedaço mais recente de código do qual ele tem orgulho, em linguagem simples, para um público não-técnico. Os sêniores vão adorar. Os juniores vão sofrer. Esse é o filtro.

Os quatro modos como a relação quebra

Vimos muitas dessas relações morrerem. Os modos de falha se agrupam.

Drift de escopo. O entendimento do produto pelo fundador muda toda semana. O engenheiro continua construindo o que o fundador pediu na sprint anterior. No mês três, estão entregando a coisa errada — ou discutindo se estão entregando a coisa errada. A correção é congelar um escopo específico para cada iteração de duas semanas e insistir que mudanças esperem a próxima iteração. Fundadores que não conseguem segurar essa linha estão sinalizando que precisam de um sócio com PM no loop, não de um desenvolvedor solo.

Mismatch de comunicação. O engenheiro fala em implementação. O fundador entende implementação como compromisso e se surpreende quando a realidade dobra. A correção é uma nota de status semanal escrita — o que entregou, o que está bloqueado, o que mudou no plano — com riscos explícitos. Se o engenheiro não consegue escrever, é um sinal. Se o fundador não consegue ler, é outro sinal.

Invisibilidade de dívida técnica. O engenheiro entrega rápido, o fundador fica feliz, o código apodrece silenciosamente. Dezoito meses depois, qualquer mudança leva três vezes mais tempo do que levava, e ninguém consegue explicar por quê. A única profilaxia é contratar alguém que de fato se importa com isso e que ocasionalmente possa vetar uma vitória rápida em favor da escolha durável — e confiar nele quando o faz. Se você não consegue confiar nesse ponto, a relação está fundamentalmente quebrada.

O problema do ônibus. Você tem um único desenvolvedor. Ele pede demissão, fica doente, ou tira férias longas. O código está sem documentação; o processo de deploy mora na cabeça dele; as chaves de API estão num arquivo .env no laptop dele. O dano do problema do ônibus é assimétrico e severo. A correção é insistir, da semana um, que o repositório tenha um README que um estranho consiga seguir, um runbook de deploy, e um cofre de credenciais que não viva em uma só máquina. Se o desenvolvedor empurra contra esses três, isso por si só é um sinal de falha de contratação.

Bandeiras vermelhas que valem ser levadas a sério

Um candidato que responde ao seu briefing prometendo o escopo todo em menos da metade do tempo que você esperava. Um candidato que nunca construiu nem manteve o tipo de sistema que você pede. Um candidato que recusa um teste pago “porque ele não faz testes”. Um candidato cujas referências trabalharam todas com ele há mais de três anos. Um candidato cujo portfólio impressiona, mas cujo papel em cada projeto fica vago quando você cutuca. Um candidato que quer começar com um documento longo de arquitetura em vez de uma fatia pequena entregável.

Nada disso é desqualificação automática. Tudo vale ao menos uma pergunta direta e desconfortável antes de prosseguir.

O que a contratação deveria parecer no mês três

Se a relação está funcionando, os primeiros três meses produzem quatro coisas, mais ou menos nessa ordem. Semana dois: um esboço de arquitetura escrito que você lê em quinze minutos. Semana quatro: a primeira peça real de funcionalidade em produção, mesmo que estreita. Semana seis: um processo de deploy que o fundador viu rodar de ponta a ponta. Semana dez: uma peça pequena de feedback de cliente real que mudou algo na próxima sprint.

Se três dessas quatro não aconteceram pela semana doze, o diagnóstico raramente é “o engenheiro é ruim”. Geralmente é que o fundador contratou antes de o briefing ficar claro, contratou na forma errada (um freelancer onde precisa de parceiro, um sênior onde precisa de CTO, um júnior em qualquer lugar), ou não instalou os ritmos — briefings escritos, escopos congelados, status semanal — que transformam talento bruto em produto entregue.

A boa notícia é que esse diagnóstico aponta para coisas consertáveis. A má é que nenhuma delas se conserta com mais contratações.

A versão mais simples da regra

Contrate o desenvolvedor quando você sabe o que colocaria nele. Até lá, escreva o briefing, converse com mais dez clientes, e pague um sócio sênior para escopar a primeira versão. Os fundadores que vimos seguir essa ordem, nessa sequência, quase nunca acabam se arrependendo da contratação que eventualmente fazem. Os que pulam o briefing e correm para a contratação quase sempre se arrependem.