Para escolher uma empresa de desenvolvimento de software, compare menos o preço e mais a forma de trabalhar. Avalie, nesta ordem: se ela tenta entender a sua operação antes de orçar, como divide e entrega o projeto, de quem ficam o código e os acessos depois do pagamento, o que oferece depois do lançamento e há quanto tempo mantém os clientes. É isso que separa um sistema que dura anos de um que vira dor de cabeça.

Qual é o maior risco ao contratar um sistema sob medida?

É natural começar comparando orçamentos, mas o preço raramente é o que dá mais prejuízo. Os problemas que custam caro de verdade costumam ser três:

  • Ficar preso ao fornecedor. O sistema funciona, mas o código, o servidor ou o domínio ficam nas mãos de outra empresa. Qualquer mudança depende dela, no prazo e no preço que ela definir.
  • Receber algo que não resolve o processo. O sistema faz o que estava na proposta, mas não o que a equipe precisa no dia a dia. As planilhas continuam abertas ao lado.
  • Ficar sem suporte. Depois da entrega, ninguém responde quando algo quebra ou quando a operação muda.

Sistema sob medida é mesmo o que você precisa?

Antes de comparar fornecedores, vale fazer essa pergunta. Se o seu processo é parecido com o da maioria das empresas do setor, um sistema pronto, por assinatura, pode atender com menos prazo e investimento. O sob medida faz sentido quando o jeito de trabalhar é justamente o que diferencia a empresa, quando é preciso conectar sistemas que não conversam entre si ou quando os sistemas prontos obrigam a equipe a contornar a ferramenta o tempo todo.

Ferramentas para montar sistemas sem programar também existem e resolvem tarefas simples. Elas costumam não bastar quando há regras de negócio complexas, muitos perfis de usuário, integrações com outros sistemas ou dados sensíveis. Um bom fornecedor diz com franqueza quando o sob medida não é o melhor caminho.

A empresa tenta entender sua operação antes de passar orçamento?

Esse é o primeiro filtro. Um sistema sob medida existe para resolver um processo específico, e ninguém consegue orçar isso sem conhecer o processo. Na primeira conversa, uma empresa séria pergunta mais do que fala:

  • Como o trabalho acontece hoje, passo a passo, e onde ele trava.
  • Quem vai usar o sistema e o que cada pessoa precisa ver ou fazer.
  • Quais planilhas, sistemas e documentos existem hoje e precisam ser integrados ou migrados.
  • O que precisa estar pronto primeiro e o que pode esperar.

Em projetos maiores, é comum haver uma etapa de levantamento antes da proposta final, às vezes com conversas com quem opera o processo no dia a dia. Isso não é enrolação: é o que permite estimar prazo e custo com algum fundamento.

O que faz um projeto custar mais ou menos

Entender a operação também explica o orçamento. O custo cresce com a quantidade de regras de negócio, de perfis de usuário e de telas; com integrações a outros sistemas, como o sistema de gestão (ERP), a emissão de nota fiscal ou os meios de pagamento; com a necessidade de aplicativo para celular além da versão web; e com a migração de dados antigos. Quando duas propostas parecem muito diferentes, compare item a item: muitas vezes a mais barata deixou de fora testes, hospedagem, documentação ou suporte.

Como o projeto vai ser dividido e entregue?

Projetos entregues de uma vez só, no fim, concentram todo o risco no último dia. Se algo foi mal entendido no começo, você só descobre quando o prazo e o dinheiro já acabaram.

O modelo mais seguro divide o sistema em módulos e entrega cada um em ciclos curtos. A cada entrega, você vê uma parte funcionando, testa com a equipe e aprova ou pede ajustes antes de seguir. Assim os erros de entendimento aparecem cedo, quando corrigir custa menos, e a empresa pode começar a usar as partes mais urgentes antes de o sistema ficar completo.

Isso pede algo de você também: alguém da sua equipe que conhece o processo precisa reservar tempo para validar cada entrega. Pergunte ao fornecedor quem ele espera desse lado e com que frequência.

De quem fica o código e os acessos depois de pagar?

Esse é o ponto que mais protege a empresa de ficar presa a um fornecedor, e ele precisa estar no contrato, não só na conversa. O contrato deve dizer, por escrito, que o código desenvolvido sob medida passa a ser da sua empresa e a partir de quando, por exemplo, após a conclusão e a quitação do projeto.

Além do código, confira quem vai controlar:

  • O repositório, o lugar onde o código fica guardado com o histórico de todas as alterações. Você deve ter acesso a ele ou recebê-lo completo na entrega.
  • O servidor ou a conta de nuvem onde o sistema roda, de preferência em nome da sua empresa.
  • O domínio, registrado no CNPJ da sua empresa, não no de quem desenvolveu.
  • As contas de serviços usados pelo sistema, como envio de e-mails, lojas de aplicativos e ferramentas pagas.

Pergunte também o que não será seu: bibliotecas de terceiros, componentes que o fornecedor reaproveita entre projetos e licenças pagas. Isso é normal, desde que esteja claro. E peça documentação suficiente para que outra equipe consiga continuar o trabalho, se um dia for preciso.

O que acontece depois do lançamento?

Todo sistema precisa de ajustes depois que entra em uso de verdade, porque usuários reais encontram situações que nenhum teste previu. Por isso, avalie duas coisas separadas:

  • Garantia: um período, definido em contrato, em que erros do que foi entregue são corrigidos sem custo adicional. Pergunte quanto tempo dura e o que ela cobre, porque correção de erro é diferente de funcionalidade nova.
  • Manutenção evolutiva: um plano contínuo para atualizar o sistema, manter a segurança em dia e incluir melhorias conforme a empresa muda. Pergunte como funciona, por qual canal você pede ajuda e em quanto tempo costuma ter resposta.

Um fornecedor que não tem nada a dizer sobre o depois está, na prática, entregando um sistema que vai envelhecer sozinho.

Há quanto tempo a empresa mantém seus clientes?

Tempo de mercado conta, mas diz pouco sozinho. O sinal mais forte é a permanência dos clientes: ninguém fica anos com um fornecedor que não entrega ou que some quando algo dá errado.

Peça para conversar com um ou dois clientes antigos, além de ver o portfólio. Pergunte como foi quando algo deu errado, se os prazos foram cumpridos e se eles contratariam de novo.

Perguntas para levar à primeira reunião

  1. O que vocês precisam saber sobre a nossa operação antes de passar um orçamento?
  2. Como o projeto será dividido? O que veremos funcionando na primeira entrega?
  3. Quem da nossa equipe precisa validar cada entrega, e com que frequência?
  4. Como são tratados os pedidos de mudança no meio do projeto?
  5. O contrato diz que o código será nosso? A partir de quando?
  6. Em nome de quem ficam o repositório, o servidor, o domínio e as demais contas?
  7. Qual é a garantia depois do lançamento e o que ela cobre?
  8. Como funciona a manutenção depois da garantia?
  9. Posso falar com clientes que estão com vocês há vários anos?

Sinais de alerta

  • Orçamento fechado sem conhecer o processo. Se ninguém perguntou como a sua empresa trabalha, o valor foi chutado, para mais ou para menos.
  • Contrato que não fala de propriedade do código. O silêncio aqui costuma virar dependência mais tarde.
  • Nenhum plano para depois da entrega. Sem garantia e sem manutenção definidas, o primeiro problema vira negociação.
  • Uma única entrega no fim do projeto. Os erros de entendimento só aparecem quando já não há tempo para corrigir com calma.
  • Acessos sempre em nome do fornecedor. Servidor, domínio e repositório ficam fora do seu controle.

Esses critérios valem para qualquer fornecedor, inclusive para nós. É o tipo de projeto de software sob medida que fazemos na OMS: sistemas complexos entregues em módulos a cada 15 dias, código que passa a ser do cliente após a conclusão e a quitação do projeto, garantia de 30 dias para correções e planos de manutenção evolutiva. Muitos clientes estão com a gente há mais de uma década.