# Contratar programador: o que perguntar antes de assinar > O teste técnico diz se a pessoa sabe programar. As perguntas antes de assinar dizem se você fica na mão depois da entrega, e elas dão mais trabalho na primeira reunião. Por Alexandre Leite, Colaboratório. Publicado em 2026-10-14, atualizado em 2026-10-14. Fonte: https://colaborato.rio/blog/contratar-programador/ ## Em 30 segundos - Contratar programador é combinar com uma pessoa, um time ou uma empresa a construção do sistema da sua operação. O teste técnico mostra se a pessoa sabe programar. Quem mantém depois, de quem são o código e as senhas, como você vê o andamento e o que acontece quando alguém sai, isso se pergunta 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](https://colaborato.rio/blog/o-que-e-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 só estava na cabeça de alguém vai embora com ele.](https://colaborato.rio/_emdash/api/media/file/01M4WRYVN8V3WPXZB28GR5RM0S.webp) 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](https://legis.senado.leg.br/norma/551485/publicacao/15651457), 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. ![Andamento se mede no que dá para clicar.](https://colaborato.rio/_emdash/api/media/file/01M4WRYWX3R8ZNBXR1MHCXXHV8.webp) 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](https://colaborato.rio/blog/o-que-e-mvp/). 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](https://colaborato.rio/blog/o-que-e-vibe-coding/). ![O que não foi escrito vira palpite.](https://colaborato.rio/_emdash/api/media/file/01M4WRYZ9KMQ9SJMW1D0DZJ9TA.webp) 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](https://colaborato.rio/blog/sai-dessa-vibe-errada/), 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](https://colaborato.rio/blog/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](https://colaborato.rio/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](https://wa.me/5521992438381?text=Oi!%20Li%20o%20artigo%20%22Contratar%20programador%3A%20o%20que%20perguntar%20antes%20de%20assinar%22%20no%20site%20e%20queria%20conversar.). ## Perguntas frequentes ### Quais são os riscos de contratar um freelancer? O maior risco é depender de uma pessoa só: se ela pega um emprego ou outro projeto, o conhecimento do sistema vai junto. Também é comum o código e as senhas ficarem na conta pessoal dela. Dá pra reduzir os dois combinando repositório e acessos no nome da empresa e pedindo as regras do negócio por escrito. ### Como contratar um desenvolvedor de aplicativos? Comece escrevendo o que o app precisa fazer, para quem e o que conta como pronto, antes de pedir orçamento. Depois compare as propostas pelo que vem depois da entrega: quem publica as atualizações na loja, quem mantém o app e em nome de quem ficam a conta da loja e o código. O teste técnico mostra se a pessoa sabe programar, e essas perguntas mostram se você vai ficar bem atendido. ### Qual profissional cria apps? Quem cria apps é o desenvolvedor de software, que pode ser especializado em aplicativo de celular, em sistema web ou nos dois. Em projeto de empresa costuma entrar mais gente: alguém que desenha as telas, alguém que decide o que construir primeiro e alguém que testa. Para testar uma ideia, também dá pra montar um app simples com IA, sem programar. ### Quanto um desenvolvedor cobra por hora? O valor da hora varia com a experiência, a tecnologia, o tipo de contrato e a região, e por isso faixa genérica ajuda pouco. Mais útil é comparar o que está incluído: duas propostas com hora parecida podem tratar manutenção, documentação e acessos de jeitos bem diferentes. Pergunte o que você recebe no fim de cada mês, além das horas. ### Com IA, ainda vale a pena contratar um programador? Vale quando o sistema vai rodar a operação e precisa durar, com login, pagamento, dado que não pode sumir e alguém que responda quando parar. Para testar uma ideia, montar sozinho com IA funciona bem e custa pouco. Na hora de contratar, a IA também ajuda do seu lado, escrevendo a especificação e lendo a proposta contra ela.