antes de assinar, pergunte isso ao seu fornecedor de sistema.

Lucas Albuquerque15 de julho de 2026 · 10 min de leitura 2.091 palavras

Contratar o desenvolvimento de um sistema sob medida não é como comprar um software pronto. Você não está pagando por uma licença de uso, está pagando pela construção de um ativo que deveria ser seu, feito por alguém que vai conhecer esse ativo melhor do que você mesmo, pelo menos no início. Essa assimetria é normal e faz parte de qualquer projeto técnico. O problema aparece quando ela vira dependência permanente, e a diferença entre as duas coisas quase sempre se decide antes de o projeto começar, no contrato e nas perguntas que você fez ou deixou de fazer na reunião de proposta.

A maioria das empresas que procura desenvolvimento de sistema chega focada em prazo e preço. São perguntas legítimas, mas resolvem só metade da equação. A outra metade, a que decide se você vai conseguir trocar de fornecedor daqui a dois anos sem reescrever tudo do zero, raramente aparece na proposta comercial. Este guia reúne as perguntas que separam um fornecedor que constrói um ativo seu de um fornecedor que constrói uma dependência disfarçada de solução.

Quem é dono do código depois que o sistema fica pronto.

Comece pelo ponto mais concreto e mais frequentemente ignorado numa negociação, quem é o dono do código depois que o sistema fica pronto. Pela Lei do Software (Lei 9.609/98) e pela Lei de Direitos Autorais, quem desenvolve por encomenda não transfere automaticamente a titularidade pra quem contratou. Isso precisa estar explícito em contrato, com cessão dos direitos patrimoniais. Sem essa cláusula, o fornecedor continua sendo dono do que criou mesmo depois de pago integralmente, e você fica numa espécie de licença de uso permanente sem nunca ter comprado de fato o que achava que tinha comprado.

Quem hospeda e quem tem as chaves da infraestrutura.

A segunda pergunta que costuma faltar é sobre infraestrutura, quem hospeda o sistema e quem, na prática, segura as chaves. É comum um fornecedor configurar tudo em nome dele por conveniência no início do projeto, a conta de nuvem, o domínio registrado, o certificado SSL, o serviço de e-mail transacional. Funciona bem enquanto a relação está boa e vira um problema sério no dia em que ela não está mais.

• Domínio. Confirme se o registro no Registro.br, ou no registrador equivalente, está no CNPJ da sua empresa, não no do fornecedor nem no CPF de um funcionário dele.
• Conta de hospedagem ou nuvem. AWS, DigitalOcean, Google Cloud, hospedagem compartilhada, o que for. A conta de cobrança precisa estar no seu nome, com o fornecedor como colaborador com acesso, não o contrário.
• Banco de dados. Peça acesso de leitura ao banco de produção desde o início do projeto, e credenciais completas de administrador no momento da entrega.
• Variáveis de ambiente e segredos. Chaves de API, tokens de integração, certificados. Tudo isso precisa estar documentado num cofre de senhas que você controla, não só na cabeça de um desenvolvedor específico.

O que acontece se a relação com o fornecedor acabar.

Toda parceria de desenvolvimento pode terminar, por decisão sua, por decisão do fornecedor, ou porque a empresa dele simplesmente fecha as portas. Isso acontece mais do que se comenta abertamente no mercado de tecnologia, e o momento de descobrir o que fazer nessa hora não pode ser o próprio momento em que ela termina.

Pergunte com detalhes o que acontece num desligamento. Existe cláusula de transição documentada no contrato? Quantos dias de aviso prévio ele prevê antes de suspender o suporte? O fornecedor se compromete a fazer handoff técnico pra outra equipe, com documentação e uma reunião de passagem, ou o contrato só fala em "entrega do sistema" sem detalhar como funciona a saída desse relacionamento? Se você já está numa situação dessas e não sabe por onde começar, converse com um fornecedor de sistemas web especializado em assumir projetos de terceiros, boa parte desse trabalho é justamente reconstruir o mapa de um sistema que perdeu a documentação.

Como funciona o suporte e a evolução depois do lançamento.

Lançar o sistema é a parte visível do projeto, mas a maior parte do ciclo de vida dele acontece depois, em manutenção, correção de bugs, pequenas evoluções e adaptação a mudanças de regra de negócio. Ainda assim, é comum a proposta comercial detalhar exaustivamente o desenvolvimento inicial e tratar o pós-lançamento numa linha genérica de "suporte incluso por 30 dias".

• O que conta como suporte e o que conta como evolução? Corrigir um bug que impede o uso do sistema é suporte. Adicionar um relatório novo é evolução, e normalmente é cobrado à parte. Peça essa fronteira por escrito.
• Qual é o tempo de resposta prometido? Fornecedores sérios trabalham com SLA definido, algo como resposta em até 4 horas úteis pra bugs críticos e até 24 horas pro resto. "A gente responde rápido" não é um SLA.
• Existe um pacote de horas mensal, e quanto custa? No mercado brasileiro em 2026, pacotes de manutenção evolutiva costumam ficar entre R$ 1.500 e R$ 6.000 por mês, dependendo da complexidade do sistema e da quantidade de horas incluídas, de 10 a 40 horas mensais em média.
• O que acontece se você não contratar o pacote de manutenção? Alguns contratos preveem suporte avulso cobrado por hora, outros simplesmente não garantem atendimento fora do plano. Vale saber qual é o caso antes de precisar descobrir na prática.

Como saber se o fornecedor entende de arquitetura ou só entrega telas.

Nem todo fornecedor que entrega telas bonitas entende de arquitetura de software, e essa é talvez a distinção mais difícil de perceber antes de contratar, porque as duas coisas parecem a mesma coisa pra quem não é da área técnica. Um sistema com boa interface e arquitetura ruim funciona igual no dia do lançamento e começa a travar assim que o volume de dados, de usuários ou de regras de negócio cresce.

Como é o processo típico de um projeto de sistema sob medida.

Conhecer as etapas típicas de um projeto de sistema sob medida ajuda a perceber, ainda na proposta, se o fornecedor tem um processo real ou só um cronograma genérico copiado de outro orçamento. Um projeto de porte médio, entre um módulo interno de gestão e uma plataforma multiusuário, costuma seguir uma sequência parecida com esta.

Somando as etapas, um MVP de porte médio costuma sair do briefing ao lançamento em 3 a 5 meses, e sistemas maiores, com múltiplas integrações ou vários perfis de usuário, podem levar de 6 a 12 meses. Se o fornecedor promete prazos muito abaixo disso pra um escopo parecido, pergunte o que exatamente vai ficar de fora da primeira entrega. Quer ver como esse processo se aplica ao seu caso? A página de sistemas web detalha como funciona por aqui, e a calculadora de orçamento estima prazo e investimento a partir do escopo que você descrever. Se ainda estiver na dúvida entre validar a ideia com protótipo antes de programar, vale ler também este outro guia, e quem ainda não decidiu entre sistema pronto e sob medida encontra o comparativo completo em sistema pronto ou sob medida, como decidir.

Antes de escrever a primeira linha de código, decida quem vai ser dono do sistema quando ele estiver pronto.

Perguntas frequentes.