Contratar programador: o que perguntar antes de assinar

Terça de manhã, a proposta do programador chega por e-mail. São três páginas em PDF: o que ele vai construir, o prazo, o valor e, lá no fim, uma linha que diz "manutenção: a combinar". Você já conversou com ele duas vezes, gostou do jeito dele e viu os projetos anteriores. Ele quer começar logo, porque tem outro projeto pra fechar.

Dá vontade de assinar hoje. O escopo está lá, o prazo parece razoável e o portfólio é bom. O que a proposta não diz é quem atende quando o sistema parar no fechamento de março, onde fica o código e o que acontece se ele aceitar um emprego no meio do caminho.

Contratar programador, um time ou uma empresa

Quem vai contratar programador costuma começar pela pergunta de onde achar a pessoa: plataforma de freelancer, indicação, vaga CLT ou PJ, empresa de desenvolvimento. Essa escolha importa, e eu comparei os modelos no texto sobre o que é software house, com quem gerencia e quem mantém o sistema em cada um. Na hora de achar a pessoa, uma indicação de quem tem um sistema rodando há tempo com ela costuma dizer mais que o portfólio, porque mostra o depois da entrega.

Aqui o foco é a etapa seguinte. Você achou alguém, fez o teste técnico e gostou da conversa. Antes de assinar, vale fazer as perguntas que nenhum teste técnico responde.

Elas valem para os três formatos que aparecem quando alguém resolve contratar programadores:

• Uma pessoa, freelancer ou PJ, que constrói e cuida do sistema enquanto estiver disponível.
• Um time contratado dentro de casa, em que a empresa vira empregadora e precisa de alguém pra dizer o que construir primeiro.
• Uma empresa, que entra com gerente de projeto e processo próprio.

Em todos eles, o desenvolvimento de software para empresas tem a mesma parte difícil, e ela fica depois da entrega. Sistema de operação muda junto com a operação: chega um imposto novo, um cliente grande pede um relatório diferente, o banco troca a forma de integração. Quem responde por isso precisa estar combinado antes da primeira linha de código.

Também existe o caminho de fazer você mesmo, com IA, numa ferramenta no-code ou low-code, ou de montar o app no Lovable. Para testar uma ideia, funciona bem. Este texto é para quando o sistema vai rodar a operação e alguém precisa responder por ele.

Quem mantém o sistema e o que acontece quando a pessoa sai

"Manutenção a combinar" quer dizer que ninguém combinou. Na prática, a palavra cobre correção, atualização e evolução, e vale perguntar por cada uma:

• Correção: quem atende quando o sistema dá erro, em quanto tempo e por qual canal.
• Atualização: quem acompanha o servidor, as bibliotecas e as integrações, que mudam com o tempo mesmo sem nada quebrado.
• Evolução: se a mudança que a operação vai pedir entra num contrato mensal, num pacote de horas ou num orçamento novo a cada pedido.

A outra pergunta é a que ninguém gosta de fazer: o que acontece se a pessoa sair. O freelancer pode pegar um emprego. Quem está no time interno pode pedir demissão. Na empresa contratada, o desenvolvedor que conhecia o seu sistema pode ir para outro cliente. Ninguém está fazendo nada de errado nesses casos, e mesmo assim o sistema fica sem quem o entendia.

O que protege você é o que fica escrito fora da cabeça da pessoa:

• A regra do negócio em português, num documento que você consegue ler: quem aprova desconto, o que acontece com o pedido devolvido, como o rateio é calculado.
• O passo a passo para rodar o sistema, que outro programador consiga seguir sem ligar pra ninguém.
• Um aviso prévio combinado, com um período de passagem para quem chegar depois.

Na reunião, pergunte o que o próximo programador recebe se a pessoa sair daqui a seis meses. A resposta mostra bastante de como ela trabalha, e quem já passou por uma troca costuma responder rápido.

De quem é o código, o domínio e as senhas

Essa parte parece burocracia até o dia em que você precisa trocar de programador.

Comece pela lei. A Lei do Software, de 1998, diz no artigo 4º que, salvo estipulação em contrário, os direitos sobre o programa feito durante um contrato de serviço pertencem a quem contratou. O "salvo estipulação em contrário" é o detalhe que importa: o contrato pode dizer outra coisa, então leia a cláusula de propriedade antes de assinar. Se o seu caso tiver nuance, como um componente que o programador reaproveita com outros clientes, vale a leitura de um advogado.

Ter o direito no papel ainda é diferente de ter o código na mão. Peça desde o primeiro dia:

• O repositório do código numa conta da sua empresa, com o programador convidado como colaborador, e não na conta pessoal dele.
• O domínio, o servidor e o banco de dados no nome da empresa, pagos com o cartão da empresa.
• As contas de serviço no seu cadastro, como o envio de e-mail, o meio de pagamento e a chave da IA que o sistema usa, com o programador entrando como usuário.
• Um cofre de senhas compartilhado, em que você consegue tirar o acesso de alguém numa tarde.

Num contrato de desenvolvimento de software, isso cabe em poucas linhas: de quem é o código, onde ele fica e o que é entregue no fim. E tem uma razão prática pra resolver na assinatura: pedir os acessos depois que a relação azedou é bem mais difícil do que pedir no começo.

Como medir o andamento sem ler código

O pior jeito de acompanhar um projeto de software é o relatório que diz quanto falta em porcentagem. Para quem não lê código, ele não informa nada, e a última parte de um projeto costuma ser a mais demorada.

O jeito que funciona é ver funcionando. Combine antes:

• Uma entrega que dá pra clicar a cada uma ou duas semanas, num endereço de teste, com dado parecido com o real.
• Uma pessoa da operação testando, de preferência quem vai usar o sistema todo dia, além do dono.
• Um critério de pronto para cada parte, escrito antes, como "o financeiro consegue lançar uma nota e ver o valor no relatório do mês". Pronto quer dizer que quem usa consegue fazer a tarefa sozinho.
• Uma lista curta do que está feito e do que falta, que você abre quando quiser, sem precisar pedir.

A primeira entrega deveria ser a menor versão que alguém da operação consegue usar de verdade, a mesma lógica do produto mínimo viável. Assim você descobre cedo se o sistema resolve o problema certo. Se já se passaram três semanas sem nada pra clicar, a hora de perguntar é essa, e não o fim do prazo.

Com IA, o programador entrega mais rápido o que foi pedido

Hoje é comum o programador escrever código com IA do lado. Isso é bom pra quem contrata: a primeira versão sai antes, o teste custa menos e dá pra mudar de ideia sem jogar meses fora.

A IA escreve muito bem o que foi pedido. Quando a regra do negócio está escrita, ela acelera a parte trabalhosa. Quando não está, o programador, com ou sem IA, preenche o buraco com um palpite razoável, e você só descobre que era o palpite errado com o sistema no ar. Contei um caso assim no texto sobre o que é vibe coding.

Por isso, com IA no meio, a especificação pesa mais que o prazo. E dá pra usar o ChatGPT, o Claude ou o Gemini pra escrever essa especificação antes de falar com qualquer programador:

• Conte a operação e peça as perguntas. Descreva como o pedido chega, quem aprova e onde ele termina, e peça que a IA liste o que um programador precisaria saber. As perguntas que você não sabe responder são a parte da especificação que falta.
• Peça os critérios de pronto. Cole a especificação e peça, para cada parte, uma frase do tipo "o financeiro consegue fazer isso e ver aquilo". É o que você vai testar a cada entrega.
• Leia a proposta contra a especificação. Cole as duas e peça o que a proposta deixou de fora. A IA acha o buraco rápido, e a decisão sobre ele continua com você.

Guarde a especificação num documento da empresa, fora da conversa com a IA. Ela vai ser lida pelo programador de hoje e pelo próximo.

O que entra no contrato continua sendo decisão sua

Nenhuma dessas perguntas tem uma resposta certa pra todo mundo. Um sistema pequeno, usado por três pessoas, vive bem com um freelancer e um combinado simples, desde que o código e as senhas estejam com você. Os riscos de contratar um freelancer crescem quando o sistema fatura, paga ou fala com cliente, e aí a manutenção precisa estar por escrito, com alguém que responda quando parar.

Leve estas perguntas pra reunião, seja com uma pessoa, um time ou uma empresa:

• Quem atende quando o sistema parar, em quanto tempo e por qual canal?
• Isso está no contrato ou é um combinado de conversa?
• O repositório, o domínio e as contas de serviço ficam no nome da minha empresa desde o primeiro dia?
• Se você sair, o que o próximo programador recebe: regras escritas, passo a passo, um período de passagem?
• De quanto em quanto tempo eu vejo algo funcionando, e quem da operação testa?
• Existe uma especificação antes do código, e quem escreve?

A IA ajuda a montar essa lista e a ler a proposta. O advogado ajuda com a cláusula, e o programador diz o que é viável e quanto custa. Quanto risco a empresa aceita, o que construir e quem responde se der errado continua sendo decisão de quem toca a operação.

Especificação antes do código, inclusive comigo

No método que eu uso, o protocolo antivibe, os dois primeiros passos acontecem antes de qualquer código: mapear o terreno, olhando como o trabalho é feito hoje, e priorizar o problema e o caminho. Na prática, isso vira uma especificação curta, com as regras do negócio em português e o que conta como pronto. Quando a operação ainda não está clara, o ponto de partida é o mapeamento de processos.

Faço assim por um motivo prático: é a especificação que permite a outra pessoa continuar o sistema, inclusive alguém do time do próprio cliente. E as perguntas deste texto valem pra mim também. O Colaboratório é um estúdio pequeno, e estúdio pequeno depende de poucas pessoas.

A medida que eu acompanho de perto é a renovação. Até aqui, a carteira do Colaboratório tem 100% de renovação, e eu leio esse número como sinal de que o combinado do depois da entrega está funcionando.

Se a proposta na sua caixa de entrada também diz "manutenção: a combinar", escrevi uma página sobre como eu começo um projeto de software sob medida, separando o que precisa ser construído do que dá pra usar pronto. Se quiser repassar as suas perguntas com alguém antes de assinar, entre em contato.