Saber como escolher uma empresa de tecnologia para uma pequena empresa é mais difícil do que parece — porque os critérios que a maioria usa são os errados. Preço, portfólio extenso e site bonito da agência são os mais comuns. Mas o que realmente determina se um projeto vai dar certo é outra coisa: se o fornecedor entende seu processo antes de propor qualquer solução, se o contrato especifica o que está incluído e o que não está, e se o código e os dados vão ficar com você ao final.
Os erros mais caros nessa decisão raramente aparecem no início. Aparecem dois meses depois da entrega: quando você precisa de uma funcionalidade que “estava subentendida” mas não estava no escopo; quando o sistema entregue não reflete como a sua operação realmente funciona; ou quando você descobre que o código ficou com o fornecedor e qualquer manutenção ou melhoria depende exclusivamente dele.
Neste post, vamos mostrar o que perguntar antes de fechar com qualquer fornecedor de tecnologia, o que um bom contrato precisa ter e os sinais de alerta que indicam que algo vai dar errado — antes mesmo de o projeto começar.
A maioria dos projetos de tecnologia que fracassam não falham na execução — falham no escopo. O cliente pediu uma coisa, o fornecedor entendeu outra, e o contrato não especificou nenhuma das duas. O resultado é um sistema entregue que não resolve o problema que motivou o investimento.
O que perguntar antes de fechar com qualquer empresa de tecnologia
Essas perguntas não são técnicas — são de processo e de relação comercial. Qualquer fornecedor sério deve ter respostas claras para todas elas. Se a resposta for vaga em algum ponto, esse ponto vai se tornar problema mais adiante.
1. “Vocês fazem diagnóstico antes de apresentar proposta?”
Um fornecedor que apresenta preço antes de entender o processo está vendendo uma solução genérica — não uma solução para o seu problema. O diagnóstico não precisa ser longo: pode ser uma reunião de 1 hora com as perguntas certas. Mas precisa acontecer antes de qualquer proposta. Sem diagnóstico, o escopo vai ser baseado no que o fornecedor sabe fazer — não no que você precisa.
2. “O código-fonte e os dados ficam com a minha empresa?”
Essa é a pergunta que muitos empresários esquecem de fazer — e lamentam depois. Se o código ficar com o fornecedor, você depende dele para qualquer manutenção, melhoria ou migração futura. Se os dados ficarem em servidor do fornecedor sem contrato que garanta acesso, você pode perder o histórico do negócio se o relacionamento terminar mal. Portanto, exija que a propriedade do código-fonte e dos dados esteja explícita no contrato — no seu nome.
3. “O que está fora do escopo — e como funciona uma mudança?”
Todo projeto tem o que está dentro e o que está fora do escopo inicial. O problema é quando o contrato não especifica o segundo. Mudanças de escopo durante o desenvolvimento são normais — o que não pode ser normal é descobrir o custo da mudança apenas quando ela se torna necessária. Um bom contrato especifica o processo de alteração de escopo: como é solicitado, em quanto tempo é orçado e como é aprovado.
4. “Quem vai dar suporte depois da entrega — e com qual prazo de resposta?”
Suporte pós-entrega sem SLA definido não é suporte — é boa vontade. Pergunte: qual é o canal de atendimento? Qual é o prazo de resposta para problemas críticos? E para melhorias? Quem é o responsável técnico pelo projeto? Essas respostas precisam estar no contrato — não em e-mail informal ou promessa verbal.
5. “Vocês têm portfólio de projetos similares ao meu?”
Portfólio extenso não significa experiência relevante para o seu caso. Uma agência que fez 50 sites e nenhum sistema de gestão não tem a mesma capacidade de uma que fez 10 sistemas de gestão para empresas do seu porte. Peça para ver projetos similares — não em tecnologia, mas em tipo de problema resolvido. Se o fornecedor não tiver exemplos, peça para falar com um cliente anterior.
Fazemos um diagnóstico do processo que você quer automatizar — e mostramos o escopo mínimo antes de qualquer proposta.
Quero o diagnóstico →Os 5 sinais de alerta que indicam que algo vai dar errado
Proposta enviada sem reunião de diagnóstico
Se o fornecedor enviou proposta de preço após uma troca de mensagens superficial, sem entender o processo em detalhe, a proposta não foi feita para o seu problema — foi feita para fechar negócio. O escopo vai ser genérico, o preço pode parecer atrativo e o resultado vai decepcionar.
Prazo prometido muito abaixo do esperado
Um sistema que deveria levar 3 meses sendo prometido em 3 semanas é sinal de que o escopo foi subestimado ou que o fornecedor vai terceirizar para quem nunca viu o projeto. Prazo irrealista quase sempre resulta em entrega incompleta, qualidade comprometida ou atraso com desculpas progressivas.
Contrato genérico sem especificação de funcionalidades
Um contrato que diz “desenvolvimento de sistema de gestão” sem listar o que o sistema precisa fazer é um contrato que protege só o fornecedor. Qualquer entrega mínima pode ser considerada cumprimento do contrato. Exija uma lista de funcionalidades — mesmo que em linguagem não técnica — como parte do documento.
Comunicação exclusivamente informal durante a negociação
Fornecedor que trata tudo por WhatsApp, sem registro escrito de decisões e combinados, está criando uma situação onde nada pode ser comprovado depois. E-mail ou sistema de tickets não é burocracia — é proteção para os dois lados.
Não fala sobre o que pode dar errado
Fornecedor sério fala sobre riscos antes de começar — integrações que podem ter instabilidade, funcionalidades que dependem de terceiros, pontos do processo que precisam de mais mapeamento. Fornecedor que só fala sobre o que vai dar certo está vendendo expectativa — não entregando realidade. Como discutimos no post sobre ERP sob medida vs sistema pronto, a transparência no processo de avaliação é o primeiro indicador da qualidade da entrega.
| Critério | Sinal de alerta | O que esperar de um bom fornecedor |
|---|---|---|
| Diagnóstico | Proposta enviada sem reunião de mapeamento | Diagnóstico do processo antes de qualquer proposta |
| Prazo | Prazo muito abaixo do esperado para o escopo | Prazo realista com etapas e marcos definidos |
| Contrato | Genérico — sem lista de funcionalidades | Escopo detalhado com funcionalidades, exclusões e processo de mudança |
| Propriedade | Código e dados ficam com o fornecedor | Código-fonte e dados em nome do cliente, explícito no contrato |
| Suporte | “Temos suporte” sem prazo ou canal definido | SLA documentado — prazo, canal e responsável definidos |
| Comunicação | Tudo por WhatsApp, sem registro formal | Decisões e combinados registrados por escrito |
Documente o processo que você quer automatizar em uma página: quais são as etapas, quem executa cada uma, quais informações entram e saem e onde estão os maiores pontos de erro ou retrabalho.
Esse documento tem dois benefícios imediatos: o fornecedor vai entender o problema real — e você vai perceber se ele está propondo uma solução para o problema real ou para um problema genérico.
Como a AbaCode conduz o processo de diagnóstico e proposta
Na AbaCode, nenhuma proposta é enviada sem diagnóstico. O diagnóstico tem um objetivo único: entender como a empresa opera hoje — os processos, os pontos de retrabalho, o que já existe e o que precisa ser construído. Só depois desse mapeamento apresentamos uma proposta com escopo detalhado, prazo realista e investimento claro.
O código-fonte de todo sistema que desenvolvemos fica com o cliente — documentado e entregue ao final do projeto. Os dados ficam em servidor de propriedade do cliente ou em ambiente contratado em nome do cliente. O suporte pós-entrega tem SLA definido no contrato e um responsável técnico que conhece cada linha do que foi desenvolvido. Essa é a abordagem que garante que o relacionamento funcione a longo prazo — não apenas no momento da entrega.
Mapeamos sua operação, definimos o escopo mínimo e apresentamos uma proposta com investimento claro. Sem pressão, sem proposta genérica.
Falar com a AbaCode →