Contratar desenvolvedor de app sem saber avaliar código: 5 perguntas antes de assinar

Cinco perguntas que não exigem ler código e mostram no primeiro mês se o desenvolvedor de app vai entregar, mais o que muda entre freelancer, preço fechado e time dedicado.

A primeira pergunta é a mais simples: o que você consegue abrir no celular ao fim da sprint

Antes de assinar com um desenvolvedor de app, seja um freelancer ou uma empresa que aluga desenvolvedores, você precisa de cinco respostas que não exigem ler uma linha de código. O que você consegue abrir no celular ao fim de cada sprint. Em nome de quem ficam o repositório e as contas das lojas. Quem de fato vai escrever o código. Como vem a estimativa de prazo. E o que acontece com o que ficou de fora de cada ciclo. Se o fornecedor enrola em qualquer uma delas na conversa de venda, vai enrolar na execução.

Essas perguntas cabem em uns 90 minutos de reunião e mostram no primeiro mês o que eu só entendi quando já era tarde. Eu contratei desenvolvedores para uma startup sem saber avaliar o que eles me diziam, e a conta chegou sprint depois de sprint.

A startup que morreu com as sprints quase prontas

A startup era de locação de equipamento para obra, e o app nunca acompanhou o cronograma

Antes da Revin, fundei uma startup de locação de equipamento para construção civil, no estilo Uber: quem precisava de uma máquina na obra encontrava quem tinha uma parada. Eu vinha da engenharia mecânica e da montagem industrial. Sabia ler cronograma de obra, sabia cobrar empreiteiro. Contratei desenvolvedores para construir o app achando que software seria parecido.

Não foi. O que me faltava era julgar o que eles diziam. Quando alguém explicava por que a funcionalidade não tinha ficado pronta, eu não tinha como separar um problema técnico real de uma explicação bem montada. Não sabia dizer se o prazo pedido era apertado ou folgado. A sprint terminava, a entrega esperada não aparecia, e a seguinte começava com a mesma promessa.

Voltei a programar para entender o que estava acontecendo por dentro. Ajudou a enxergar, mas não salvou a empresa. A startup morreu.

O que ficou foi uma lista de perguntas que teria mostrado o problema no primeiro mês. Nenhuma delas é técnica.

Por que tanta gente está procurando desenvolvedor de app agora

Nos Estados Unidos, a busca por "app developers for hire" fica na faixa de mil a 10 mil pesquisas por mês no Google e subiu 900% em três meses, segundo o Keyword Planner. Quem anuncia nesse termo paga entre US$ 84 e US$ 392 por clique. Esse preço diz quem está do outro lado da busca: gente com orçamento e com pressa para começar.

A resposta que o mercado dá a essa pressa é curta. Um dos anúncios que mais tempo rodam no setor, há mais de 300 dias, diz basicamente "contrate desenvolvedores especialistas, vamos conversar". Ninguém explica como você, que não é técnico, descobre se o especialista é especialista. É esse buraco que as perguntas abaixo tapam.

As cinco perguntas antes de assinar

Quem escreve o código precisa estar na reunião em que o prazo é prometido

• "O que eu vou conseguir abrir no meu celular no fim da primeira sprint?" A resposta boa é concreta: um link de teste no TestFlight ou um APK instalável, com duas ou três telas funcionando, mesmo feias. A resposta ruim é "a base do projeto" ou "a arquitetura". Base existe, só que duas sprints seguidas sem nada que você consiga tocar é exatamente o sinal que eu deixei passar.
• "Em nome de quem ficam o repositório, a conta da Apple, a do Google Play e a da nuvem?" Tudo no seu nome desde o primeiro dia, com o fornecedor entrando como convidado. Se o código mora na conta dele, quem decide a saída é ele, e você descobre isso justamente no dia em que quiser trocar.
• "Quem vai escrever o código, e essa pessoa está nesta reunião?" Peça nome, senioridade e quanto do tempo dela é do seu projeto. O sênior que brilha na venda e desaparece depois do kickoff é a frustração mais comum de quem contrata desenvolvimento.
• "Me dá o prazo em faixa e me diz o que ainda não foi medido." Uma data única e redonda na primeira conversa é chute com confiança. O jeito honesto de estimar é a faixa, a lista do que ainda é incerto e a data em que o número fica mais apertado, e isso está detalhado no texto sobre como responder um pedido de estimativa de prazo.
• "O que ficou de fora desta sprint, e por quê?" Essa você faz no fim de cada ciclo, não na venda. A resposta boa nomeia o item, o motivo e o que muda no próximo. "Está quase pronto" repetido duas vezes seguidas é o som de um projeto sem controle.

Na minha startup, as cinco teriam falhado no primeiro mês. Eu só não sabia que eram as perguntas certas.

"Mas eu sou de negócio, não vou saber avaliar a resposta"

É a objeção mais comum, e ela mistura duas coisas. Avaliar código exige conhecimento técnico. Avaliar comportamento, não. Você não precisa saber o que é um build para perceber que não recebeu nenhum em quatro semanas, nem entender de Git para exigir que o repositório esteja no seu nome.

Tem outro teste simples: peça ao desenvolvedor que explique uma decisão técnica em termos do seu negócio. Uma vez me perguntaram se subir do MySQL 5 para o 7 era a mesma coisa que trocar para o Postgres. Respondi com fruta. MySQL 5 é banana prata, o 7 é banana nanica, o Postgres é maçã. Tudo é fruta, tudo é banco SQL, mas a maçã é outra fruta. Quem domina o assunto consegue traduzir. Se a pessoa não consegue explicar a escolha de um jeito que você entenda, o problema de comunicação é dela, e vai aparecer de novo quando o prazo apertar.

Agora, o limite honesto: nenhuma dessas perguntas diz se o código está bom. Um app pode passar nas cinco e ainda estar montado de um jeito que trava no sexto mês. Para isso, a saída é pagar algumas horas de alguém técnico e independente do fornecedor para ler o repositório. Se o seu produto está sendo feito com muita ajuda de IA, o risco é maior, e o texto sobre desenvolvimento de software com IA sem saber arquitetura lista as checagens que pegam esse tipo de problema cedo.

Freelancer, preço fechado ou time dedicado

A pergunta de fundo aparece em qualquer fórum. "Por que contratar desenvolvedores próprios em vez de terceirizar o produto?" tem mais de 7 mil visualizações e oito respostas no Software Engineering do Stack Exchange, e nenhuma delas fecha a questão, porque a resposta depende do tipo de contrato que você assina.

O freelancer costuma ser o caminho mais barato por hora e o mais frágil. Tudo depende de uma pessoa. Antes de fechar, pergunte o que acontece se ela ficar doente três semanas ou pegar um projeto maior. Se a resposta for "não vai acontecer", já aconteceu com alguém.

O projeto de preço fechado parece o mais seguro, e é onde eu tenho mais desconfiança. O modelo incentiva o fornecedor a entregar o mínimo que o contratante não sabe avaliar e virar as costas depois da última fatura. A empresa que aceita bater o preço do concorrente tira esse desconto de algum lugar, e o lugar costuma ser justamente o que você não consegue ver: teste, monitoramento, a documentação que permitiria outra pessoa continuar.

O time dedicado custa mais por mês e resolve a pergunta três da lista, porque a pessoa da reunião é a mesma que está no código. É o formato que a Revin adotou depois de viver os dois lados do balcão: squad sênior embarcado no projeto do cliente, com repositório e contas no nome de quem paga. Não é o certo para todo mundo. Para um protótipo de duas semanas, um bom freelancer resolve.

Para ter uma régua de custo antes da conversa comercial, o levantamento de salário de desenvolvedor de software no Brasil em 2026 mostra quanto custa cada nível de senioridade. E se você está nos Estados Unidos avaliando um time aqui, as 7 perguntas que founder americano deveria fazer antes de contratar squad fora dos EUA completam esta lista com o que muda na distância.

O sinal que aparece em quatro semanas

Se você já assinou, ainda dá tempo. Conte quantas coisas você consegue abrir no celular desde o início do contrato. Se o número é zero depois de quatro semanas, pare de aceitar a próxima sprint como está e faça as cinco perguntas em uma reunião só, por escrito, com resposta por escrito.

E uma checagem que vale para qualquer contrato: se o seu fornecedor sumisse amanhã, você conseguiria entregar o repositório e as contas das lojas para outra pessoa até sexta-feira?