Como escolher uma empresa de desenvolvimento de software quando você não sabe ler o código

Um guia para founders não técnicos: os sinais que de fato preveem se o seu projeto vai sair, os critérios que parecem importantes e não são, e as quatro perguntas para fazer antes de assinar qualquer coisa.

Você entrou em três reuniões comerciais esta semana. As três empresas foram simpáticas, profissionais e seguras. As três disseram que o seu projeto era totalmente viável. As três mandaram um deck com uma parede de logos, uma nota cinco estrelas no Clutch e um portfólio de apps parecidos com o seu. Na sexta você tinha três propostas na mesa, duas delas com menos de 15% de diferença de preço, e nenhuma ideia real de como escolher.

Essa é a parte difícil de escolher uma empresa de desenvolvimento de software: os dados que você consegue ver são os mesmos que todo fornecedor aprendeu a polir, e o dado que mais importa, se eles vão de fato entregar um software que funciona e que você não precisa ficar babá, fica invisível até você já ter pago. Então a resposta curta é esta. Você escolhe uma empresa de desenvolvimento de software pelo comportamento dela antes de o dinheiro trocar de mãos, não pelo que ela te mostra. Como ela escopa o trabalho, como ela discorda das suas ideias, como ela fala de custo e de risco, e o que ela faz quando você pergunta algo que ela não sabe responder direito. Esses quatro comportamentos preveem a entrega. O portfólio não.

A gente pode dizer isso porque a gente é uma empresa de desenvolvimento de software. O que vem a seguir é o guia do comprador escrito de dentro da sala, incluindo as partes que o nosso próprio mercado preferiria não publicar, porque metade do que passa por processo comercial acaba na lista de sinais de alerta.

A armadilha em que todo outro guia te coloca

Pesquise essa pergunta e você vai achar uma dúzia de artigos, quase todos escritos por empresas de software, mandando você avaliar três coisas: portfólio, expertise técnica e preço. Esse conselho não é tanto errado quanto inútil, porque os três são fáceis de maquiar e nenhum sobrevive ao contato com o seu projeto de verdade.

Um portfólio mostra o trabalho do qual a empresa tem mais orgulho, com print do melhor momento e sem nenhuma menção a quais projetos atrasaram seis meses ou foram refeitos pelo fornecedor seguinte. “Expertise técnica” é uma lista de logos: React, AWS, Python, Kubernetes. Toda empresa da sua shortlist tem a mesma lista, e você não tem como saber se eles usam essas ferramentas bem ou só sabem soletrar. E o preço, o único número que você se sente capaz de comparar, é o dado mais enganoso de todos, por motivos que já chegamos lá.

O problema mais fundo é que esse modelo te pede para julgar a empresa por artefatos. Um founder não técnico não consegue julgar um artefato de software de forma confiável. Você não lê o código, não distingue uma arquitetura limpa de uma frágil, e não sabe se aquele app lindo do portfólio é sustentável por baixo ou está preso com fita. Se o seu método de escolha exige avaliar coisas que você não consegue ver, você não tem um método. Você tem um cara ou coroa com passos a mais.

Então pare de tentar dar nota ao software. Dê nota ao comportamento. Comportamento é algo que um founder não técnico lê muito bem, porque aparece em linguagem clara, em reunião, no jeito como as perguntas são respondidas. E comportamento antes do contrato é o melhor preditor disponível de comportamento depois dele.

O que de fato prevê se o seu projeto vai sair

Quatro comportamentos, observáveis nas duas primeiras conversas, dizem mais do que qualquer portfólio.

Como eles escopam o seu projeto. Entregue a mesma ideia solta para duas empresas. Uma volta com um orçamento. A outra volta com perguntas: quem é o usuário, o que acontece no caminho que dá errado, com o que isso se conecta, qual é a única funcionalidade que precisa funcionar no dia um. A segunda empresa é mais chata de lidar na primeira semana e muito mais barata de tocar no sexto mês. Requisitos vagos são onde projetos de software morrem, e o trabalho de definir o escopo antes de contratar qualquer um é exatamente o que uma boa empresa exige. Um estúdio que pega o seu briefing pela metade e já te dá um preço está avisando que vai construir o que você mandar e te cobrar pelo retrabalho. O jeito como um estúdio escopa é uma prévia de como ele vai tocar o projeto. Um bom trata o escopo como o trabalho mais importante, não como uma formalidade antes do trabalho de verdade.

Como eles discordam de você. Repare no que acontece quando você propõe algo que é uma má ideia. Todo founder propõe algumas. Você pede uma funcionalidade que dobra o prazo e não serve a ninguém, ou descreve uma arquitetura que ouviu num podcast. Um fornecedor otimizando para a venda concorda e adiciona ao orçamento. Um parceiro te diz que é uma má ideia e explica por quê, mesmo que discordar de você seja a jogada comercial mais arriscada. A disposição de perder um pouco de simpatia para te poupar dinheiro é o sinal mais subestimado desta lista. Uma empresa que não diz não para você antes de você pagar nunca vai dizer não depois, e um projeto onde ninguém diz não é um projeto que incha. Essa é a diferença entre um parceiro de tecnologia e uma caixa-preta: um parceiro discute com você.

Como eles falam de custo e de incerteza. Pergunte quanto tempo vai levar e quanto vai custar. A resposta honesta envolve uma faixa, algumas premissas e a admissão de que o número vai mudar conforme você aprende coisas. A resposta desenhada para ganhar o contrato é um valor único e seguro, sem ressalvas. Estimar software é genuinamente difícil, e uma empresa que finge que é fácil é inexperiente ou está mentindo para te fechar. Steve McConnell, autor de Code Complete, passou a carreira em um único ponto: estimativas no início carregam uma incerteza enorme. Um estúdio que respeita essa incerteza em voz alta vai cuidar do seu orçamento com honestidade. Um que a esconde vai descobri-la depois, na sua fatura.

O que eles fazem quando não sabem. Faça uma pergunta um pouco fora da zona de conforto deles. Repare se eles dizem “não sei, vou verificar” ou se geram uma resposta segura na hora. A frase “não tenho certeza, vou descobrir” é uma das coisas mais tranquilizadoras que um fornecedor pode dizer, porque mostra que ele distingue o que sabe do que está chutando, e essa distinção é o trabalho inteiro. As pessoas que você está contratando vão passar anos tomando decisões que você não consegue verificar. Você não está apostando se eles têm todas as respostas. Você está apostando se eles serão honestos sobre quais respostas não têm.

Os critérios que parecem importantes e não são

Alguns dos dados que te mandaram pesar muito merecem quase nenhum peso.

A parede de logos. Clientes famosos significam que a empresa consegue fechar clientes famosos. Não diz nada sobre se o seu projeto, que é menor e menos prestigioso, vai pegar os seniores deles ou a reserva. Às vezes o logo famoso é até um aviso: você vai ser a conta que pega o time júnior enquanto os craques atendem a marca grande.

Prêmios e selos de diretório. Uma nota alta num diretório de fornecedores é função de quantos clientes felizes a empresa pediu para deixar avaliação, mais, em alguns casos, quanto ela gasta com o próprio diretório. É uma saída de marketing, não uma medida de qualidade. Trate como você trataria um selo de “Melhor de” na vitrine de um restaurante: fracamente positivo, fácil de manipular, e não um motivo para escolher.

Tamanho do time. Uma empresa de 200 pessoas não é mais segura que um estúdio de 12. Casas maiores te dão processo e continuidade e, muitas vezes, mais camadas entre você e quem de fato escreve o seu código. As menores te dão acesso direto e atenção sênior e, muitas vezes, mais risco de pessoa-chave. Nenhum dos dois é a resposta certa. O tamanho certo depende do seu projeto, e uma empresa que te diz que maior é sempre mais seguro está vendendo o próprio headcount.

O pitch da stack. Se uma empresa começa pelo quanto a stack dela é moderna e nova, desconfie. As ferramentas chatas e comprovadas geralmente são a escolha certa para um produto no início, e um estúdio que corre atrás do framework mais novo às vezes está resolvendo o currículo dos engenheiros dele, não a sua manutenibilidade. Você quer uma empresa que escolhe tecnologia pelo seu problema, não pelo que está na moda. Já escrevemos sobre a diferença entre tecnologia emergente como ferramenta e como religião na nossa peça sobre auditoria de código; o mesmo teste vale na hora de escolher quem constrói.

O 80/20 de escolher uma empresa de desenvolvimento de software

Existe uma versão do princípio de Pareto que encaixa bem nessa decisão: uma fração pequena dos sinais carrega a maior parte do peso preditivo. Se você só tivesse tempo de avaliar duas coisas, avalie estas.

Primeiro, como eles lidam com a distância entre o que você pediu e o que você de fato precisa. As melhores empresas passam a primeira conversa estreitando o seu projeto, não inflando. Elas acham a versão da sua ideia que custa metade e testa o mesmo risco. Um fornecedor que só adiciona escopo está otimizando para a fatura dele. Um parceiro que subtrai escopo está otimizando para o seu resultado, e essa orientação, uma vez que você a vê, é difícil de fingir.

Segundo, como um cliente real deles responde a uma pergunta específica. Não pergunte às referências se ficaram felizes. Todo mundo diz que sim. Pergunte: “O que deu errado, e como eles lidaram com isso?” Todo projeto real tem uma semana ruim. A referência que consegue descrever um problema e uma recuperação está descrevendo uma empresa que fala a verdade sob pressão. A referência que insiste que nunca nada deu errado ou nunca entregou nada difícil, ou não está sendo sincera. Essa única pergunta faz mais trabalho do que o resto da ligação junto.

As quatro perguntas para fazer na primeira reunião

Leve estas para a primeira conversa. As respostas, e o conforto com que são dadas, vão separar a sua shortlist rápido.

“Me conta um projeto que saiu dos trilhos e o que vocês fizeram a respeito.” Você está testando honestidade e se eles já entregaram algo difícil o bastante para sair dos trilhos.

“Se você tivesse que cortar o meu escopo pela metade para caber no orçamento, o que cortaria e por quê?” Você está testando se eles entendem o seu produto bem o suficiente para ter opinião sobre o núcleo dele, e se vão pensar em trade-offs em vez de só te vender tudo.

“Quem especificamente vai trabalhar nisso, e o que acontece se essa pessoa sair?” Você está testando o risco de pessoa-chave e se você está recebendo o time do pitch ou um outro, mais barato, depois de assinar. Depender de um único desenvolvedor é um custo real, e uma empresa séria tem resposta para isso.

“Como eu vou saber se o projeto está fora do trilho antes de ser tarde demais para consertar?” Você está testando se eles vão tornar o trabalho visível para um dono não técnico, ou se você vai ficar cego até um prazo estourar. A resposta deveria envolver algo que você de fato consegue ver toda semana, não uma cor de status numa ferramenta que você não abre.

Uma empresa que responde essas quatro com limpeza, sem se eriçar, provavelmente já teve essas conversas antes e sobreviveu a elas. Isso é a maior parte do que você está procurando.

Mais barato é um sinal, não uma economia

O orçamento que chega 40% abaixo dos outros não é um desconto. É informação. Ou aquela empresa escopou o seu projeto de forma mais rasa que as outras, e a diferença vai reaparecer como pedidos de mudança depois que você estiver preso, ou ela pretende alocar pessoas mais baratas e menos experientes na sua construção, ou ainda não entende o trabalho bem o suficiente para precificá-lo. De vez em quando um orçamento baixo reflete eficiência genuína. Mais frequentemente reflete um mal-entendido que você vai pagar para corrigir.

O orçamento caro também não está automaticamente certo. Mas quando os preços divergem muito, a reação certa não é pegar o barato. É pedir a cada empresa para explicar o número dela, porque a explicação te diz quem de fato entendeu o projeto. Preço é mais útil como pergunta, menos útil como resposta. Detalhamos a versão mais profunda disso na nossa peça sobre como projetos terceirizados são precificados e onde moram as surpresas.

Como verificar o que você não consegue ler sozinho

Você ainda não lê o código. Então embuta a verificação no contrato em vez de tentar fazê-la no processo comercial.

Comece com uma peça pequena, paga e escopada de trabalho real antes de se comprometer com a construção inteira. Um sprint de discovery, uma primeira funcionalidade, uma fatia funcional do produto de verdade. Um mês de colaboração real ensina mais sobre uma empresa do que dez horas de reunião, e é um seguro barato contra um erro de seis meses. Como eles se comportam dentro dessa pequena empreitada, se comunicam, se entregam o que disseram que entregariam, se o software funcionando bate com a demo, é a coisa mais próxima de uma garantia que você vai ter.

Depois, antes de escalar ou em qualquer marco grande, você pode ter alguém independente olhando o que foi construído. Você não precisa ler código para encomendar uma auditoria de código e receber uma leitura em linguagem clara sobre se a fundação é sólida. Uma empresa confiante recebe bem essa segunda opinião. Uma nervosa resiste, e a resistência é a resposta dela.

Escolher uma empresa de desenvolvimento de software nunca vai ser uma aposta certa, porque você está comprando algo que não consegue inspecionar por inteiro de alguém que acabou de conhecer. Mas você pode parar de tentar dar nota ao software e começar a dar nota às pessoas, à luz do dia, antes de gastar um centavo. A empresa que escopa com cuidado, discute com você, precifica com honestidade e admite o que não sabe é a que entrega. Todo o resto é parede de logo.

Perguntas frequentes

Como escolher a empresa de desenvolvimento de software certa se você não é técnico?
Julgue o comportamento, não os artefatos. Você não consegue avaliar código, arquitetura ou um portfólio polido, mas consegue avaliar como uma empresa escopa o seu projeto, se ela discorda de más ideias, com que honestidade fala de custo e incerteza, e o que faz quando não sabe uma resposta. Esses comportamentos aparecem em conversa clara e preveem a entrega melhor do que qualquer credencial técnica. Depois reduza o risco começando com uma empreitada pequena e paga antes de se comprometer com a construção inteira.

Qual é a regra do 80/20 ao escolher uma empresa de software?
Um conjunto pequeno de sinais carrega a maior parte do peso preditivo. Os dois que mais importam: se a empresa estreita o seu escopo (otimizando para o seu resultado) ou só infla (otimizando para a fatura dela), e como uma referência real responde a “o que deu errado e como lidaram com isso”. Essas duas perguntas dizem mais do que portfólios, prêmios e preço juntos.

Quais perguntas devo fazer a uma empresa de desenvolvimento de software antes de contratar?
Quatro: me conta um projeto que saiu dos trilhos e o que vocês fizeram; se tivesse que cortar meu escopo pela metade, o que cortaria e por quê; quem especificamente vai trabalhar nisso e o que acontece se sair; e como vou saber que o projeto está fora do trilho antes de ser tarde. Você está testando honestidade, entendimento do núcleo do seu produto, risco de pessoa-chave, e se o trabalho será visível para você.

Um orçamento mais barato significa qualidade menor?
Nem sempre, mas um orçamento muito abaixo dos outros é informação, não economia. Em geral significa escopo mais raso, alocação mais barata ou um mal-entendido do trabalho, e a diferença tende a reaparecer depois como pedidos de mudança. Quando os preços divergem muito, peça a cada empresa para explicar o número. A explicação revela quem de fato entendeu o projeto.

Com quantas empresas de desenvolvimento de software eu deveria conversar?
O suficiente para triangular, em geral de três a cinco. Uma não te dá referência. Uma dúzia desperdiça o tempo de todo mundo e tende a virar comparação de preço, que é o eixo menos útil. De três a cinco te deixa comparar quão diferente cada uma escopa o mesmo briefing, que é a comparação que importa.

Devo escolher uma agência grande ou um estúdio pequeno?
Nenhum dos dois é mais seguro por padrão. Casas maiores oferecem processo e continuidade, mas mais distância de quem escreve o seu código; estúdios menores oferecem atenção sênior e acesso direto, mas mais risco de pessoa-chave. O tamanho certo depende da complexidade do seu projeto e de quanta mão na roda você precisa. Desconfie de qualquer empresa que te diga que o próprio tamanho é automaticamente a escolha segura.