Contratação de software
O que perguntar antes de contratar uma software house
Dez perguntas, o que conta como boa resposta em cada uma e o que fazer quando a resposta vem vaga. Com as nossas respostas junto, pra você comparar.
8 min de leitura
Contratar uma software house é decidir com pouca informação: você vai avaliar um trabalho que ainda não existe, feito por gente que acabou de conhecer. As dez perguntas abaixo servem pra diminuir essa distância. Nenhuma exige que você entenda de programação. Todas exigem que o fornecedor entenda do seu projeto.
Um critério vale por todos: boa resposta é específica. Se você pergunta prazo e ouve "depende", a conversa acabou. Se ouve "depende do login corporativo: se for Microsoft Entra ID a gente já fez, se for outro provedor eu preciso ler a documentação antes de prometer data", tem alguém pensando no seu caso. Resposta vaga não te ajuda a decidir nada.
Quem exatamente vai escrever o meu código?
Você conheceu quem vende. Pergunte quem senta pra construir. É a mesma pessoa? É um time interno? É alguém terceirizado com quem você nunca vai falar? Nenhuma dessas respostas é errada por si só. Ruim é descobrir no primeiro problema.
Pergunte também quem atende quando dá ruim numa sexta à noite. Casa pequena costuma ter o sócio no telefone. Casa grande costuma ter processo. As duas coisas funcionam. O problema aparece quando ninguém sabe dizer.
Na App.co são dois sócios e são os dois que tocam o trabalho. Gustavo Arcolezi é mestre em Física, desenvolvedor Flutter e professor de Programação para Dispositivos Móveis na UNICIVE, em Maringá. Antonio Almeida cuida de arquitetura, code review e escolha de stack, com backend em .NET e Node.js.
Sinal de alerta
Resposta que fala em "nosso time de especialistas" e não cita uma pessoa. Você vai trabalhar com gente, não com organograma.
O que entra na primeira versão, e o que fica de fora?
Escopo mal definido é a causa número um de projeto que estoura, e quase nunca por má-fé. As duas partes saem da reunião com listas diferentes na cabeça, e a diferença só aparece três meses depois, quando já custa caro.
Peça a lista do que fica de fora. Ela revela mais que a lista do que entra. Quem consegue escrever o que não vai fazer entendeu o produto. Quem só sabe dizer sim ainda está vendendo.
A gente combina o escopo da primeira versão antes de escrever a primeira linha: o que entra, o que fica pra depois e o que cada corte desses muda no prazo. Se o seu produto ainda está nessa fase, essa conversa já é o serviço.
Sinal de alerta
Proposta que descreve o produto em adjetivos, tipo "plataforma completa" ou "sistema robusto", sem uma lista de telas e de regras.
Quanto tempo leva, e o que faz esse prazo mudar?
Prazo confiável vem sempre com o que pode movê-lo. Pergunte qual parte do projeto é a mais incerta e por quê. Se essa resposta não existir, o número que veio antes dela também não vale.
As faixas que a gente usa como referência: primeira versão enxuta, com as telas essenciais e publicação nas lojas, de 6 a 12 semanas. App médio, com backend próprio e painel administrativo, de 3 a 5 meses. Quando entra integração com equipamento ou operação sem internet, de 4 a 6 meses, porque parte do trabalho é testar em campo e não só programar. E some até 30 dias entre o build finalizado e o app disponível pra baixar: a revisão da App Store e da Google Play tem tempo próprio, e cada uma reprova por motivos diferentes.
Repare que nenhuma dessas faixas é um número único. Fornecedor que responde "noventa dias" na primeira conversa, sem ter visto escopo, não está estimando. Está tentando fechar.
Sinal de alerta
Prazo cravado antes de existir uma lista de escopo. E prazo que ignora a revisão das lojas, que não depende de nenhum dos dois lados.
De quem é o código quando o projeto acabar?
Quase ninguém pergunta, e é a resposta que decide todas as outras. Se o código não é seu, trocar de fornecedor deixa de ser uma decisão e vira uma refação. Isso dá ao fornecedor atual um poder que nenhum contrato equilibra depois.
Pergunte três coisas concretas: o código-fonte é meu no fim do projeto, o repositório é entregue, e as contas de nuvem, de loja e o domínio ficam em nome de quem.
Na App.co o código é do cliente e o repositório é entregue. É isso que permite você levar o produto pra outro time se quiser. E é por isso que a gente escreve pensando em quem vai ler depois: código limpo e arquitetura sólida desde o primeiro commit, sem o atalho que economiza uma semana agora e cobra um mês daqui a um ano.
Sinal de alerta
Resposta que empurra a pergunta pro contrato sem dizer qual é a política. Política boa se explica em uma frase.
Como eu acompanho o andamento sem depender de reunião?
Projeto de software passa semanas sem nada visível acontecendo, e é aí que a confiança quebra. Pergunte o que você vai ver, com que frequência, e se dá pra abrir e mexer.
A resposta que interessa é ambiente de teste no ar desde as primeiras semanas. O produto rodando, mesmo feio, mesmo pela metade. Relatório qualquer um escreve; produto no ar mostra o que existe de verdade.
É o que a gente chama de transparência total: você acompanha cada etapa, sem surpresa e sem letra miúda.
Sinal de alerta
Fornecedor que só mostra o produto no fim. "A gente te apresenta quando estiver pronto" é o pior arranjo possível pros dois lados.
O que acontece quando o escopo muda no meio?
Vai mudar. Todo projeto muda: o mercado se mexe, você entende melhor o próprio produto, a loja altera uma regra. A pergunta não é se muda, é qual o procedimento quando mudar.
Quem tem processo descreve um caminho: a mudança é avaliada, recebe estimativa própria, e você decide entre entrar agora empurrando o resto ou entrar na versão seguinte. Quem não tem responde "a gente ajusta". Isso vira conta-surpresa ou atraso sem explicação, e às vezes os dois.
Sinal de alerta
Contrato calado sobre mudança de escopo. O silêncio ali não é flexibilidade, é ambiguidade, e ambiguidade sempre cobra no fim.
Vocês já fizeram algo parecido com o meu problema?
Portfólio bonito não responde isso. O que responde é o fornecedor descrever a decisão técnica difícil de um projeto anterior. Não a tela: a decisão.
Um exemplo do que a gente considera resposta. No Farm Tracker, o cliente já tinha um hardware proprietário com GPS e RFID acoplado ao trator, e lavoura quase não tem sinal. Faltava a camada de software: app em Flutter lendo o hardware por Bluetooth, arquitetura offline-first que grava tudo no dispositivo e sincroniza quando a rede volta, dashboard em Flutter Web pro gestor e uma API em C# / .NET sobre PostgreSQL costurando as pontas. A decisão difícil não foi o Bluetooth. Foi de modelo de dados: definir quem é a fonte da verdade quando as duas pontas mudaram enquanto estavam separadas.
Outros três cases, outros três problemas. O Rural Imóveis separa corretor de comprador com Row-Level Security no Supabase, e modera anúncio antes de publicar. O Agrária Ortssippenbuch fica atrás do login corporativo da cooperativa, com Microsoft Entra ID e hospedagem em Azure. O Doxys é um SaaS por assinatura em produção, em espanhol, construído ao lado de dois médicos fundadores.
Sinal de alerta
Case apresentado só por screenshot e logo de cliente. Peça o problema e a decisão. Quem viveu o projeto conta em dois minutos.
Quem coloca o produto no ar, e em nome de quem?
Parece detalhe e é onde muito projeto morre a cinco por cento do fim. Se for app, publicar não é subir arquivo: é ficha na loja, política de privacidade, permissão justificada uma por uma, build assinado e a revisão da App Store e da Google Play. Se for web, é servidor, domínio, certificado e o dia em que alguém precisa reverter às onze da noite.
Pergunte quem faz isso e em nome de quem ficam as contas. Na App.co a publicação entra no escopo desde a conversa inicial, com data no cronograma. O Doxys está em produção em doxys.co e você pode abrir agora. O Agrária Ortssippenbuch roda em Azure, dentro do ambiente da cooperativa e atrás do login corporativo dela.
Sinal de alerta
Ouvir "a publicação fica com vocês" depois de fechado. Isso precisa estar escrito na proposta.
Depois da entrega, quem mantém?
Software não fica pronto. Sistema operacional atualiza, loja muda regra, dependência ganha falha de segurança, o negócio cresce e pede coisa nova. Pergunte o que acontece no dia seguinte ao aceite.
Quem já passou por isso separa três coisas antes de você precisar delas: o que é correção de defeito, o que é evolução, e como se pede cada uma. Definir isso no calor da urgência é a pior hora possível.
A gente entrega e fica por perto depois. O Rural Imóveis está no ar com corretor cadastrando imóvel e comprador falando direto com o vendedor.
Sinal de alerta
Proposta que termina no go-live. Se não há uma linha sobre o depois, o depois vai ser negociado do zero, com você sem alternativa.
Em que caso vocês diriam que este projeto não é pra vocês?
É a melhor pergunta da lista e a que mais constrange. Fornecedor que nunca recusou nada ou é muito novo, ou aceita o que não sabe fazer e aprende no seu orçamento.
A gente tem resposta pronta pra essa. Quando o produto vive de um recurso muito específico de uma plataforma só, ou de um SDK que o fabricante só publica em nativo, multiplataforma vira remendo. A gente fala isso na conversa de escopo, não no meio do projeto, mesmo quando a resposta honesta é que o projeto não é pra gente.
Sinal de alerta
"A gente faz tudo." Ninguém faz tudo. Quem diz que faz está te vendendo o próprio aprendizado.
Os dez sinais de alerta, numa lista só
Se você levar só uma coisa daqui, leve esta lista. Cada item é a versão curta de uma das perguntas acima.
- Fala em "time de especialistas" e não cita uma pessoa.
- Crava prazo antes de existir lista de escopo.
- Descreve o produto em adjetivos, sem telas nem regras.
- Não tem política clara sobre quem fica com o código.
- Só mostra o produto quando estiver pronto.
- Tem contrato calado sobre mudança de escopo.
- Apresenta case por screenshot, sem o problema nem a decisão.
- Trata a publicação como assunto seu, e avisa depois de fechado.
- Termina a proposta no go-live, sem uma linha sobre manutenção.
- Diz que faz tudo.
Como a gente responde a essas dez
Você não precisa acreditar em nada do que está escrito aqui, dá pra conferir uma por uma. Os cinco cases estão no portfólio com o problema que o cliente trouxe, o que foi construído e a stack usada. Quem toca o trabalho está na página sobre, com nome e LinkedIn. O que cada serviço cobre está nas páginas de serviço, com os cases que sustentam cada afirmação.
Se for conversar com a gente, traga as dez perguntas. Faça as mesmas com os outros fornecedores: a lista só vale se for igual pros dois lados. E se alguma resposta nossa não te convencer, isso também é informação útil antes de assinar.