Como escolher uma software house pelo portfólio e pelas referências
Portfólio bonito não prova nada. Slides com logotipos de clientes qualquer um monta. O que conta é o que você consegue verificar.
Peça para ver produtos no ar: baixe o aplicativo na loja, abra o sistema, veja a data da última atualização. Um app publicado e mantido diz mais do que dez apresentações. Pergunte também qual foi o papel da empresa em cada projeto, porque muita gente mostra como seu um trabalho que foi só de design, ou só de uma parte do código.
Referências valem quando você fala com a pessoa. Peça o contato de um cliente com projeto parecido com o seu e de outro que já trabalha com eles há anos. Relacionamento longo é um dado forte: ninguém renova com fornecedor que entrega mal e some.
Perguntas úteis nessa etapa:
- Quais produtos que vocês fizeram estão no ar hoje, e posso testá-los?
- Qual foi exatamente a parte de vocês em cada um?
- Posso falar com um cliente atual e com um que já encerrou o contrato?
- Existe projeto parecido com o meu em tamanho e em tipo de problema?
Quem vai trabalhar de verdade no projeto
O erro mais comum que a gente vê é conhecer o time de vendas e só descobrir a equipe técnica depois da assinatura. Quem apresenta a proposta quase nunca é quem programa.
Peça os nomes, a experiência e o papel de cada pessoa alocada: quem decide a arquitetura, quem desenvolve, quem testa. Pergunte se são funcionários ou terceirizados, e o que acontece se alguém sair no meio do projeto. Uma boa resposta inclui documentação e revisão de código, para que a saída de uma pessoa não pare tudo.
Converse com quem vai liderar tecnicamente, não só com o comercial. Em meia hora de conversa dá para notar se a pessoa entende o seu negócio ou só repete termos técnicos.
Escopo e mudança: como a empresa lida com o que não estava no plano
Todo projeto muda. Quem promete escopo fechado sem nenhuma flexibilidade ou está subestimando o trabalho, ou vai cobrar caro por cada alteração. Você precisa saber, antes, como a mudança é tratada.
Pergunte como o escopo é descrito (funcionalidades, telas, regras de negócio, o que fica de fora), como um pedido novo é estimado e aprovado, e quem decide quando algo entra e algo sai. Modelos de preço fixo, por hora ou por equipe dedicada funcionam, cada um para um tipo de projeto, e a empresa deve saber explicar por que sugere um deles. Se quiser entender o que pesa no valor final, temos um guia sobre quanto custa um sistema ou app sob medida.
Prazo vale a mesma lógica. Desconfie de estimativa dada em cinco minutos, sem perguntas. Uma proposta séria nasce depois de entender regras, integrações e usuários.
Propriedade do código, acessos e dependência do fornecedor
Esse é o ponto que mais gera dor de cabeça anos depois, e quase ninguém pergunta. Deixe claro no contrato que o código-fonte é seu, ou em que condições passa a ser.
Verifique também onde o código fica guardado. O repositório deve estar numa conta da sua empresa, ou com você como administrador, e não só na conta do fornecedor. O mesmo vale para domínio, contas das lojas de aplicativos, servidor, banco de dados e serviços de terceiros. Se tudo está em nome da software house, a troca de fornecedor vira refém.
Pergunte ainda se existe documentação suficiente para outra equipe assumir o sistema. Você não precisa sair, mas precisa poder sair. É uma boa medida da confiança que a empresa tem no próprio trabalho.
Testes, entregas parciais, segurança e manutenção depois da entrega
Software entregue de uma vez, no fim de vários meses, é a receita para surpresa. Prefira entregas parciais a cada poucas semanas, em ambiente que você consiga abrir e usar. É assim que um mal-entendido aparece na semana três, não no mês oito.
Sobre testes, pergunte o que é testado e por quem: testes automatizados nas regras mais críticas, revisão de código, teste em dispositivos reais no caso de apps. Sobre segurança, pergunte como são tratados senhas e dados pessoais, quem tem acesso ao ambiente de produção, como são feitos os backups e se já foram restaurados de verdade. Backup que nunca foi restaurado é só uma esperança.
E há o depois. Sistema não termina na entrega: bibliotecas ficam desatualizadas, lojas mudam exigências, usuários pedem ajustes. Pergunte quem corrige erros, em que prazo, e como funciona a hospedagem e a atualização. Escrevemos um texto à parte sobre o que está incluso na manutenção de software e como contratar, que vale a leitura antes de fechar qualquer contrato.
Software house ou freelancer: e o time interno?
Não existe resposta universal. Cada opção resolve um problema diferente.
O freelancer costuma ser a escolha certa para tarefas pequenas e bem definidas: um ajuste, um site simples, uma integração pontual. Custa menos e é ágil. O risco é a dependência de uma só pessoa: se ela adoece, muda de trabalho ou fica sem tempo, o projeto para, e ninguém mais conhece o código.
A software house faz sentido quando o projeto exige várias competências (back-end, front-end, mobile, design, testes) e continuidade. Você ganha equipe, processo e alguém para responder depois da entrega. Em troca, paga mais por hora e precisa verificar tudo o que listamos acima, porque o tamanho da empresa não garante qualidade.
O time interno compensa quando o software é o centro do seu negócio e vai evoluir por muitos anos. Contratar, treinar e manter engenheiros é caro e lento. Muitas empresas começam com uma software house, aprendem o que precisam e só então montam o time próprio, já com um produto de pé.
Ao decidir entre software house ou freelancer, pergunte-se: o que acontece com esse sistema daqui a dois anos? Se a resposta importa, você precisa de mais do que uma pessoa.
Sinais de alerta antes de contratar uma software house
Alguns comportamentos, na nossa experiência, quase sempre antecipam problemas:
- Preço e prazo fechados em uma reunião, sem perguntas sobre o seu negócio.
- Recusa em mostrar produtos no ar ou em passar contato de clientes.
- Resposta evasiva sobre quem vai trabalhar no projeto.
- Contrato que não diz de quem é o código, ou que mantém repositório e contas só em nome do fornecedor.
- Promessa de entregar tudo, em tudo, rápido e barato.
- Nenhuma menção a testes, segurança ou manutenção, como se o projeto acabasse no dia da entrega.
- Desconto forte condicionado a assinar hoje.
- Recusa de qualquer etapa menor e paga antes do contrato completo.
Como reduzir o risco com uma etapa pequena antes do contrato grande
A melhor forma de avaliar um fornecedor é trabalhar com ele num recorte pequeno. Em vez de fechar o projeto inteiro, contrate uma primeira etapa de poucas semanas: um fluxo principal funcionando, um protótipo navegável ou um módulo isolado do sistema.
Em poucas semanas você vê o que a apresentação não mostra: como a equipe pergunta, como reage a uma mudança, se cumpre o que combinou, se a comunicação é clara e se o que foi entregue roda de verdade. Se o resultado agradar, o contrato maior nasce com muito menos incerteza, e a estimativa já se apoia em trabalho real.
Se o seu caso é um sistema antigo, o raciocínio é o mesmo: comece por um módulo, não pela reescrita total. É assim que fazemos na modernização de sistemas legados, de forma incremental e sem parar a operação. O guia completo de modernização de sistemas legados explica o passo a passo.
Para aplicativos, um protótipo é a etapa pequena mais barata. Dá para validar telas, fluxo e ideia antes de escrever a primeira linha do sistema final. Oferecemos um protótipo grátis do aplicativo justamente para isso.
Da nossa experiência
Na SKAD, desde 2015 em São José dos Campos, levamos produtos até o usuário final, não só entregamos código. O Eu Católico, aplicativo próprio com mais de 100 mil downloads em iOS e Android, e o Proxi, aplicativo novo feito do zero em Node.js, React e React Native, publicado na Google Play e na App Store e com uma versão web pensada para SEO, são exemplos de produtos que você pode baixar e avaliar.
Também temos relações longas. Atendemos o cliente do Inspefire há 10 anos e desenvolvemos mais de 10 módulos novos a partir das especificações que ele nos envia. No The Horus, mantemos e hospedamos o sistema e os aplicativos sob mensalidade. Por isso falamos de manutenção e continuidade como parte da escolha, não como detalhe do contrato.
O fundador, Lucas Natal da Silva, tem 13 anos de engenharia de software, com passagens por Embraer, Ericsson, Atlas Schindler, Accenture e pelas prefeituras de São Bernardo do Campo e de São José dos Campos, além de trabalho remoto para uma empresa americana. Hoje ele também é CTO de outra empresa de software.
Perguntas frequentes
Quais perguntas fazer antes de contratar uma software house?
Pergunte quais produtos estão no ar, quem vai trabalhar no projeto, como mudanças de escopo são tratadas, de quem é o código e quem controla os acessos, como são feitos testes e entregas, e o que acontece depois da entrega. Peça as respostas por escrito.
Software house ou freelancer: qual é melhor?
Freelancer serve para tarefas pequenas e bem definidas. Software house é mais adequada a projetos com várias competências e que precisam de continuidade e manutenção.
O código-fonte pertence a quem contrata?
Depende do contrato, por isso deve estar escrito. Exija a titularidade do código e que o repositório e as contas fiquem em seu nome ou com você como administrador.
Vale a pena começar com um projeto pequeno?
Sim. Uma etapa curta e paga, como um protótipo ou um módulo, mostra como a equipe trabalha antes de você assumir um compromisso grande.
Como saber se o portfólio de uma software house é confiável?
Verifique se os produtos estão no ar, qual foi o papel da empresa em cada um e converse com pelo menos um cliente atual. Portfólio que você não consegue checar vale pouco.
O que o contrato precisa dizer sobre manutenção?
Deve indicar quem corrige erros e em que prazo, como funcionam hospedagem e atualizações, e o que é cobrado à parte. Sem isso, qualquer ajuste depois da entrega vira negociação.
Conclusão
Antes de assinar com qualquer fornecedor, escreva suas dez perguntas mais importantes a partir deste texto e envie para duas ou três empresas. Compare a clareza das respostas, não só o preço. Depois, em vez de fechar o projeto inteiro, peça uma primeira etapa pequena. Se você tem uma ideia de aplicativo, o caminho mais barato é validar o fluxo num protótipo navegável antes de investir no desenvolvimento completo. É isso que oferecemos no protótipo grátis: você vê o aplicativo, a nossa forma de trabalhar e decide com evidência, não com promessa.