Escolher fornecedor de software é decidir com informação incompleta sobre algo
que você não consegue avaliar tecnicamente. Por isso o método que funciona não é
tentar virar especialista — é fazer perguntas cujas respostas qualquer pessoa consegue
julgar.
O que olhar no portfólio
Portfólio bonito não diz nada. O que diz:
- Sistema no ar que você possa abrir. Apresentação e imagem de tela
provam bem menos que um endereço funcionando. - Projeto parecido em complexidade, não em setor. Quem fez um sistema
com integração e permissão por perfil sabe fazer o seu, mesmo em outro ramo. - Cliente que atende ao telefone. Peça dois contatos e ligue. É a
referência mais honesta que existe. - Tempo de relação com os clientes. Fornecedor que mantém cliente por
anos entrega sustentação; quem só tem projeto de uma vez, talvez não.
As perguntas que separam fornecedor de parceiro
- O código-fonte fica comigo? Precisa ser sim, por escrito. Sem isso,
você fica preso, e trocar significa recomeçar do zero. - Quem exatamente vai trabalhar no projeto? Em empresa, o time da
proposta às vezes não é o time da execução. Peça para conhecer as pessoas. - Como funciona a sustentação depois da entrega? Prazo de resposta e o
que está incluído — por escrito, antes de assinar. - O que acontece se o escopo mudar no meio? Todo projeto muda; o que
importa é o processo de reprecificação, não a promessa de que não vai mudar. - Qual a stack e por quê? A resposta certa envolve manutenção futura,
não moda. Tecnologia comum significa que outra pessoa consegue assumir depois. - Como acompanho o andamento? Entregas parciais a cada duas ou três
semanas, com software funcionando, evitam a surpresa no fim. - O que pode dar errado neste projeto? Quem responde “nada” nunca
entregou sistema em produção.
A última é a mais reveladora e a menos feita. Fornecedor que antecipa risco está
pensando no projeto; fornecedor que só concorda está pensando na assinatura do contrato.
Sinais de alerta numa proposta
- Nenhuma pergunta antes de orçar. Quem orça sem investigar está
chutando, ou vai descobrir o escopo às suas custas. - Prazo redondo demais. “Três meses” para um sistema que ninguém
detalhou vira aditivo. - Preço muito abaixo dos outros. Quase sempre significa que entendeu
menos do problema. - Silêncio sobre o código-fonte. Quem não menciona espontaneamente
costuma não pretender entregar. - Nada por escrito sobre sustentação. Vai virar negociação na
urgência. - Aceita tudo. Proposta que não delimita nada vai cortar depois, com o
projeto em andamento.
Como comparar propostas de valores diferentes
Comparar o número final é o erro mais comum, porque propostas quase nunca cobrem o mesmo
escopo. Monte uma tabela com uma linha para cada item e veja o que falta em cada uma:
| Item | Por que ele muda o preço |
|---|---|
| Design das telas | Algumas propostas cobrem só a programação |
| Testes e homologação | Entra ou vira “ajuste” cobrado depois |
| Painel administrativo | Quase sempre esquecido, e sempre necessário |
| Integrações | Cada sistema externo é projeto dentro do projeto |
| Migração de dados | Costuma ser a etapa mais demorada |
| Treinamento | Sem ele, o sistema não é adotado |
| Sustentação no primeiro ano | De 10% a 20% do projeto, dentro ou fora |
| Infraestrutura | Servidor e serviços, e em nome de quem ficam |
Feita a tabela, a proposta mais barata costuma deixar de ser a mais barata — e a
diferença que parecia grande vira pequena.
Freelancer ou empresa: quando cada um faz sentido
Antes do checklist vem uma decisão anterior: contratar uma pessoa ou uma empresa. As duas
opções resolvem problemas diferentes, e errar aqui custa mais caro do que errar o fornecedor
dentro da opção certa.
| Desenvolvedor autônomo | Empresa de desenvolvimento | |
|---|---|---|
| Custo | Menor por hora | Maior por hora: inclui gestão, QA e suporte |
| Se a pessoa sai do projeto | O projeto para | Outra pessoa assume |
| Férias, doença, outro cliente | Seu prazo escorrega | Coberto pelo time |
| Garantia e SLA | Raramente formalizados | Contrato com prazo de resposta |
| Escalar o time no meio do projeto | Não dá | Dá |
| Cobre várias frentes (back, front, mobile, infra) | Depende do perfil | Sim |
Autônomo faz sentido quando o escopo é fechado e pequeno, você consegue
especificar sozinho o que quer, o prazo tem folga e o sistema não é crítico para a operação.
Landing page, integração pontual, ajuste em sistema existente.
Empresa faz sentido quando o software vai sustentar a operação — se ele cair,
a empresa para. Também quando o escopo ainda vai mudar, quando há várias frentes ao mesmo tempo
ou quando existe prazo de negócio para cumprir.
O risco que quase ninguém calcula na hora de comparar orçamento é a continuidade.
Um sistema entregue por uma única pessoa que depois some é um ativo que ninguém consegue
manter: código sem documentação, senhas sem inventário, decisões sem registro. Reescrever custa
mais do que a economia de todas as horas somadas.
Se você for de autônomo mesmo assim, exija três coisas em contrato: repositório de código
em conta sua, credenciais de servidor e serviços no seu nome, e documentação mínima de
como subir o ambiente. Isso não elimina o risco, mas torna a troca possível. Para dimensionar o
investimento em cada cenário, veja
como o preço de um software sob medida é formado.
O teste que vale mais que qualquer proposta
Antes de fechar o projeto inteiro, contrate um diagnóstico pago — de
R$ 3.000 a R$ 8.000, de 1 a 3 semanas. Ele entrega escopo, prazo e orçamento definidos, mas
o valor maior é outro: você vê como o fornecedor trabalha de verdade antes de depender
dele.
Nesse período dá para observar o que nenhuma reunião comercial revela: se ele responde
no prazo, se faz as perguntas certas, se documenta o que combina e se discorda de você
quando precisa. Fornecedor que só concorda durante o diagnóstico vai continuar concordando
durante o projeto — e concordância não é o que você está comprando.
O que precisa estar no contrato
- Código-fonte de propriedade sua, sem cláusula de dependência.
- Escopo com o que está fora, explicitamente, e não só o que está
dentro. - Processo de mudança de escopo, com forma de reprecificar.
- Prazo de resposta da sustentação e o que está incluído.
- Acessos em nome da sua empresa — servidor, domínio, lojas, serviços.
- Documentação mínima para outra pessoa conseguir assumir.
- Confidencialidade e tratamento de dados, principalmente se houver dado
pessoal envolvido.
Se a conclusão for desenvolver, o passo seguinte é o processo: veja
como criar um sistema para a sua empresa, do escopo à entrega.
A Devuptime desenvolve software,
sistemas de gestão e integrações sob medida
em Guarulhos, São Paulo, desde 2008, com código-fonte sempre entregue ao cliente — e dizemos
quando o sistema pronto é a melhor escolha. Veja também a página de
software house ou fale com a gente.
Perguntas frequentes
Vale pedir um teste pago antes do projeto? Vale muito. Um diagnóstico ou
uma primeira entrega pequena, remunerada, mostra como o fornecedor trabalha de verdade — e
custa uma fração de descobrir isso no meio do projeto.
Empresa grande é mais segura? Nem sempre. Empresa grande traz processo e
continuidade, mas o seu projeto pode ser pequeno para ela e acabar com o time júnior. O que
importa é quem vai trabalhar, não o tamanho do logotipo.
Preciso de alguém técnico do meu lado? Ajuda ter um responsável seu
acompanhando, nem que seja meio período. Não precisa ser técnico; precisa conhecer o
processo e ter autonomia para decidir prioridade.
E se eu não gostar do resultado? É o que as entregas parciais existem
para evitar. Se você só vê o sistema no fim, o problema já custou o projeto inteiro.