Resumo executivo: o Brasil tem mais de 41 mil empresas atuando em software e serviços, e 94,3% delas são micro e pequenas. Isso significa muita oferta e enorme variação de capacidade de entrega e de sustentação. Este é o roteiro para escolher sem depender de sorte.
Por que a escolha é mais arriscada do que parece
O dado de mercado. O estudo Mercado Brasileiro de Software da ABES, publicado em junho de 2026, contabilizou 41.613 empresas de software e serviços no país, com 62,5% de microempresas e 31,8% de pequenas empresas.
A consequência prática. A maior parte dos fornecedores é pequena — o que não é defeito, é a estrutura do mercado. Mas significa que capacidade de sustentação, continuidade e profundidade técnica variam muito, e que o risco de o fornecedor sumir com o conhecimento do seu sistema é real.
O que muda a conta. Você não está comprando um projeto. Está escolhendo quem vai manter, corrigir e evoluir um sistema que a sua operação vai usar todos os dias por anos.
Os quatro critérios que importam
| Critério | O que verificar | Como verificar |
|---|---|---|
| Entendimento do seu negócio | Se a conversa começa por processo ou por tecnologia | Na primeira reunião, conte quantas perguntas eles fazem sobre a sua operação antes de propor solução |
| Capacidade de sustentação | Quem atende depois da entrega, em qual horário, com qual prazo | Peça o modelo de suporte por escrito e converse com um cliente atual |
| Práticas de engenharia | Versionamento, ambientes separados, testes, documentação | Pergunte como fazem deploy e como voltariam atrás em caso de erro |
| Transparência contratual | Propriedade do código, escopo, o que fica de fora, custo de sustentação | Leia o contrato antes da proposta comercial. Se algo é vago, será vago depois |
As perguntas que revelam o fornecedor
Sobre o projeto
- Como vocês conduzem o levantamento de requisitos? Quem do meu lado precisa participar, e por quanto tempo?
- Qual é a primeira coisa que entra em produção, e em quanto tempo?
- O que não está incluído no escopo desta proposta?
- Como registramos mudanças de escopo e como isso afeta prazo e custo?
Sobre a engenharia
- Onde fica o código-fonte e quem tem acesso? Posso ter uma cópia a qualquer momento?
- Vocês têm ambiente de homologação separado da produção?
- Como é feito o backup e com que frequência a restauração é testada?
- Que testes automatizados vocês escrevem, e para quais partes do sistema?
Sobre o depois
- Como funciona o contrato de sustentação e quanto custa por ano?
- Qual o prazo de resposta para um erro que para a operação?
- Se eu quiser trocar de fornecedor daqui a três anos, o que exatamente eu levo comigo?
- Quantas pessoas da equipe conhecem o meu sistema? (A resposta “uma” é um problema.)
Sobre segurança e LGPD
- Como vocês tratam dados pessoais durante o desenvolvimento? Usam dados reais em ambiente de teste?
- Quem da equipe de vocês tem acesso ao banco de produção, e isso é registrado?
- Existe processo para aplicar correções de segurança das bibliotecas usadas?
A pergunta sobre dados reais em teste é decisiva. “Sim, copiamos a base de produção para o ambiente de testes” é uma resposta que deveria encerrar a conversa — ou, no mínimo, virar uma exigência contratual de anonimização.
Sinais de alerta
- Proposta imediata, sem levantamento. Quem precifica antes de entender está chutando ou vendendo um produto disfarçado de projeto.
- Preço muito abaixo dos demais. Em quase todos os casos, significa escopo entendido de forma diferente. Encontre onde antes de decidir.
- Recusa em falar sobre propriedade do código. Não há razão legítima para isso em desenvolvimento sob medida.
- Nenhum cliente disponível para conversar. Referência é o teste mais barato que existe.
- Foco excessivo em tecnologia da moda. Se a proposta lista dez tecnologias e não descreve o seu processo, o projeto é um portfólio, não uma solução.
- Prazo agressivo demais. Prometer em seis semanas o que os outros estimam em seis meses é sinal de subestimação — que você vai pagar em aditivo.
- Uma pessoa só. Profissional autônomo pode entregar excelente trabalho, mas o risco de continuidade precisa estar consciente e mitigado.
Como estruturar a seleção
Objetivo → Ação → Resultado → Como validar
Objetivo: comparar fornecedores por critério, não por simpatia.
Ação: escrever um briefing de uma a três páginas com o problema, o contexto, as integrações e as restrições; enviar o mesmo documento a três ou quatro fornecedores; exigir a mesma estrutura de resposta.
Resultado esperado: propostas comparáveis, com premissas explícitas.
Como validar: montar uma matriz com os quatro critérios acima, pontuar cada fornecedor e verificar se a nota bate com a percepção. Quando não bate, normalmente falta informação — busque-a antes de decidir.
Um teste barato que resolve muita dúvida
Contrate a etapa de descoberta separadamente, com valor fechado e prazo curto. Você recebe o processo mapeado e a estimativa fundamentada, e observa na prática como o fornecedor trabalha, comunica e cumpre prazo — antes de comprometer o orçamento inteiro. Se não gostar, leva o levantamento para outro fornecedor.
Contrato: as cláusulas que não podem faltar
- Propriedade intelectual. O código, a documentação e os artefatos são da contratante, sem ambiguidade.
- Acesso ao repositório. Durante todo o projeto, não apenas ao final.
- Escopo por entrega, com critérios de aceite. “Pronto” precisa ser verificável.
- Sustentação com SLA. Prazo de resposta e de solução por criticidade, e o que acontece se não cumprir.
- Confidencialidade e tratamento de dados. Incluindo proibição de uso de dados reais em ambiente de teste sem anonimização.
- Transição. O que o fornecedor entrega e por quanto tempo apoia, caso o contrato termine.
O que a Brazuca Informática coloca na mesa
Descoberta antes de proposta. Levantamos o processo antes de precificar, e o material desse levantamento é seu, mesmo que o projeto não avance conosco.
Entrega por fases com algo em produção. Cada fase termina com uso real, não com apresentação. Você decide continuar com informação concreta.
Código no seu repositório. Acesso desde o primeiro dia, documentação de arquitetura e transferência de conhecimento como parte da entrega.
Contexto de operação, não só de projeto. Como também operamos monitoramento, central de atendimento e infraestrutura, o sistema nasce pensado para ser operado — com log, alerta e chamado, não só com funcionalidade.
Como avaliar a proposta técnica sem ser técnico
Quatro leituras que qualquer gestor consegue fazer.
- A proposta descreve o seu processo? Se as primeiras páginas falam da empresa do fornecedor e de tecnologias, e não do seu problema, o entendimento foi raso.
- Existe uma seção de premissas? Proposta sem premissas explícitas é proposta que vai virar aditivo. Premissa é o fornecedor dizendo em voz alta o que ele assumiu.
- O que está fora está escrito? A lista de exclusões protege os dois lados e revela maturidade.
- A primeira entrega tem valor sozinha? Se a fase 1 é “modelagem e arquitetura” sem nada em produção, você estará pagando meses antes de ver funcionar.
Um detalhe revelador. Pergunte quem exatamente vai trabalhar no projeto e peça para conversar com essa pessoa antes de assinar. Equipe comercial e equipe técnica costumam ser mundos diferentes — e é com a segunda que você vai conviver.
Perguntas frequentes
Fornecedor local ou remoto? Para levantamento de processo operacional, presença local faz diferença real. Para desenvolvimento e sustentação, o trabalho remoto é padrão consolidado. O melhor arranjo costuma ser presença nas etapas de campo e trabalho remoto no resto.
Empresa grande é mais segura? É mais previsível em continuidade e costuma ser mais cara e menos flexível. Empresa pequena entrega mais atenção e concentra mais risco de continuidade. O critério não é o porte, é como cada risco está mitigado no contrato.
Posso trocar de fornecedor no meio? Pode, e é menos traumático do que parece se o código estiver no seu repositório e houver documentação. Se não estiver, a troca é praticamente um reinício — o que reforça por que essas cláusulas importam.
Riscos e pontos de atenção
- Decidir só pelo preço. O barato aqui costuma cobrar juros em aditivo, retrabalho e sustentação ruim.
- Não checar referência. Uma conversa de vinte minutos com um cliente atual revela mais que qualquer apresentação.
- Assinar sem ler o contrato. Propriedade do código e sustentação são as duas cláusulas que doem depois.
- Não designar responsável interno. Projeto sem dono do lado do cliente atrasa por decisão pendente, e a culpa acaba no fornecedor.
- Ignorar a etapa de transição. Todo contrato termina algum dia. Defina como, enquanto a relação está boa.
Próximos passos práticos
- Escreva o briefing de uma página: qual problema, qual resultado esperado, quais sistemas envolvidos, quais restrições.
- Selecione três ou quatro fornecedores e envie o mesmo documento a todos.
- Use as perguntas deste artigo na primeira reunião e anote as respostas.
- Contrate a descoberta separadamente antes de comprometer o orçamento total.
Quer conversar sobre o seu projeto? A Brazuca Informática atua em consultoria e desenvolvimento de sistemas corporativos em Mato Grosso, Goiás e em todo o Brasil. Fale com nosso time.
Premissas assumidas: os dados de quantidade e porte das empresas são do estudo Mercado Brasileiro de Software da ABES divulgado em junho de 2026, referentes a 2025; os critérios de seleção apresentados são referências de projeto e devem ser ponderados conforme criticidade do sistema e porte da contratante.
Continue na série
- Do MVP ao produto: validar antes de gastar o orçamento inteiro
- Sistema legado: reescrever, refatorar ou encapsular?
- LGPD by design: segurança no ciclo de desenvolvimento de software
- Desenvolvimento de sistemas corporativos — Brazuca Informática
Deixe um comentário