Continuidade de projetos de software: o que fazer quando seu fornecedor falha

Frequentemente recebemos pessoas buscando um novo fornecedor para o desenvolvimento de seus projetos, sejam apps, web apps ou integrações. A transição de fornecedor de software é uma decisão difícil, mas às vezes necessária.

Passam-se meses, as vezes mais de um ano, e o projeto não sai do papel. O fornecedor começa a ficar cada vez mais lento e as entregas cada vez mais distantes.

Segundo o Standish Group (CHAOS Report), apenas 31% dos projetos de software são considerados bem-sucedidos. Os outros 50% são 'problemáticos' e 19% falham completamente.

Mesmo no começo de projetos, alguns sinais já indicam que o projeto poderá falhar, como pagamentos feitos em parcelas (independente do percentual entregue), comunicação distante, e até mesmo alta rotatividade de equipe na empresa fornecedora.

Tecnicamente falando, algumas empresas percebem tarde demais que a escolha das linguagens e ferramentas foi errada, impactando totalmente o andamento e conclusão do projeto.

Como saber se seu projeto de software está em risco?Link direto para: Como saber se seu projeto de software está em risco?

Reconhecer esses sinais cedo pode evitar uma transição de fornecedor de software traumática no futuro.

Pesquisa da Boston Consulting Group (BCG, 2024) mostra que mais de dois terços dos grandes projetos de tecnologia não são entregues no prazo, dentro do orçamento ou com o escopo definido.

Falta de visibilidade do progresso real e transparênciaLink direto para: Falta de visibilidade do progresso real e transparência

Um projeto de software deve ter versão funcionando desde o primeiro mês. Se você pagou mas nunca conseguiu acessar e testar o sistema, é sinal crítico de risco.

O fornecedor manda prints, relatórios de progresso, diz que está "80% pronto", mas você nunca consegue acessar e testar. "Na semana que vem mostramos", e a semana que vem nunca chega. 

Mesmo que simples, pode ter só uma tela, ou as telas terem partes faltando, mas o projeto precisa estar acessível e testável. Se você não consegue abrir o sistema e usar, mesmo que parcialmente, algo está errado.

Outro sinal de alerta é quando o fornecedor culpa fatores externos pelos atrasos: a tecnologia que deu problema, a biblioteca que mudou, o servidor que caiu, o desenvolvedor que saiu da equipe, até você mesmo que "não passou as informações certas".

Transparência significa você ter acesso ao código desde o primeiro dia, conseguir ver o sistema rodando em um ambiente de testes, e receber explicações honestas sobre o que está pronto, o que está pela metade, e o que ainda nem começou.

Comunicação distante e entregas espaçadasLink direto para: Comunicação distante e entregas espaçadas

Projetos modernos de software exigem comunicação diária e entregas semanais. Se o fornecedor demora para responder, evita reuniões ou entrega apenas a cada mês ou mais, o projeto está em risco.

Quando o fornecedor não responde no mesmo dia, evita fazer reuniões, demora para dar informações sobre o andamento do projeto, sobre o que foi feito, sobre o que está na fila e o que será entregue estes dias, é sinal de alerta. Como dizem "o gato subiu no telhado".

Antigamente a gente trabalhava no formato de "cascata", fazia uma reunião com o cliente a cada mês ou dois, e fazia uma entrega a cada dois ou três meses. E funcionava bem, porque os requisitos eram mais "quadrados", o desenvolvimento ágil era uma novidade e conectividade era menor do que hoje.

Era normal contratar o desenvolvimento e só ver algo pronto daqui a dois ou três meses.

Mas hoje em dia não é mais assim. Nós nos comunicamos muito mais, com mais frequência, praticamente pra tudo. Olha seu whatsapp ai pra você ver.

O mesmo acontece com o desenvolvimento de sistemas; é preciso contato direto, acompanhamento do que está sendo feito e transparência no trabalho realizado.

Comunicação e entregas constantes, é o ideal.

Pagamentos desconectados das entregasLink direto para: Pagamentos desconectados das entregas

Pagamento deve estar amarrado às entregas: entregou X% do projeto, recebe X% do valor. Se você já pagou 80% mas não viu nem metade funcionando, o risco financeiro é altíssimo.

O momento onde boa parte das empresas percebe que o desenvolvimento de seu web/app está comprometido, é quando percebe que já pagou 80%, 90% ou até 100% do projeto, e não viu nem metade dele em funcionamento.

Se eu pudesse sugerir uma cláusula em contratos futuros, seria pagar de acordo com as entregas. Ou seja, entregou X% do projeto, recebe X% do valor.

Parece simples, mas muitas empresas não conseguem acompanhar o desenvolvimento dos projetos com um percentual, por falta de prática mesmo em medição do trabalho.

Alta rotatividade na equipe do fornecedorLink direto para: Alta rotatividade na equipe do fornecedor

Troca constante de desenvolvedores causa perda crítica de contexto e conhecimento do projeto. Quando quase ninguém na equipe conhece bem o projeto, a qualidade despenca.

O desenvolvimento de sistemas é algo que exige uma carga cognitiva relativamente grande. Não tem como anotar tudo, e outro desenvolvedor ler e continuar. Exige no dia a dia muita conversa, compreensão, planejamento do projeto, e a maior parte dessa informação fica na cabeça das pessoas mesmo.

Em alguns casos o fornecedor passar por muita troca de gente, e pode acontecer de em algum momento quase ninguém conhecer bem o projeto, saber qual a razão dele existir, saber quais pontos estavam mais bugados no desenvolvimento, saber de partes que foram feitas parcialmente ou que seria refeitas, acarretando na queda significativa da qualidade.

Problemas técnicos comuns em projetos que falhamLink direto para: Problemas técnicos comuns em projetos que falham

Você precisa fazer uma cirurgia, você prefere um médico especializado naquela cirurgia, ou um que nunca fez ela antes?

Vejo muitas pessoas chegando com projetos que não avançam, por exemplo um aplicativo, e então eu pergunto "o fornecedor já fez outros aplicativos" e o cliente diz "ele nunca fez, mas falou que sabia fazer"...

A distância entre achar que sabe, saber, e fazer, no que tange o desenvolvimento de sistemas, é imensa!

A falta da prática, da expertise mesmo em já ter realizado algumas vezes projetos daquele tipo, é a causa raiz da maior parte dos problemas técnicos a seguir.

Débito técnico acumuladoLink direto para: Débito técnico acumulado

Débito técnico é código mal feito que se acumula e trava a evolução do projeto. Cada gambiarra, cada "depois a gente arruma", vira uma bomba-relógio que impede novas funcionalidades e aumenta bugs.

Segundo a McKinsey, o débito técnico pode consumir mais de 20% da capacidade produtiva de um time de desenvolvimento, funcionando como um 'imposto oculto' sobre cada nova entrega.

Arquitetura mal planejada desde o inícioLink direto para: Arquitetura mal planejada desde o início

Usar a tecnologia errada desde o início condena o projeto ao fracasso. É como construir uma casa de dois andares com fundação para casa térrea — não aguenta.

A empresa trabalha com uma ou duas linguagens principais, com as quais consegue implementar soluções bem feitas. Dai chega o cliente com uma demanda diferente das que a empresa costuma desenvolver. Ela decide então usar a mesma tecnologia de sempre para fazer o novo projeto, causando um problema de arquitetura.
Você pode construir um casa pequena com uma fundação menor sem problema, mas se a casa tiver uma piscina, ou for ter um segundo andar, a fundação precisará ser outra.

Otimização prematura de programador brincando de programarLink direto para: Otimização prematura de programador brincando de programar

Otimização prematura é gastar tempo preparando o sistema para milhões de usuários quando você ainda não tem nenhum. É uma das maiores armadilhas que travam projetos.

Algumas empresas tentar preparar o projeto para aguentar milhões de usuários acessando, implementam kubernetes, várias camadas de cache, otimizações sem fim, para um projeto que não tem nenhum usuário ainda.
A otimização prematura é gastar tempo em coisas que não são necessárias agora, e quando falando em desenvolvimento de sistemas, é uma falácia.
Conheço um empreendedor que ficou anos otimizando prematuramente o projeto dele, e quando lançou, já era uma solução velha, sem sentido para o contexto do momento. Perdeu o timing.
Outro ponto crítico, ligado mais a gestão de pessoas, é que programadores gostam mesmo de programar, e tendem a ficar entretidos com o código. Ficam querendo melhorar, refazer, fazer de outro jeito, sem que isso faça qualquer diferença para o cliente que está lá esperando uma versão que funcione.
Nesse caso a gestão do time de desenvolvedores precisa ser atenta para não deixar os programadores esquecerem das entregas, deixarem de enviar seus códigos e concluir tarefas todos os dias.
O foco precisa ser implementar e entregar, o mais rápido possível.

Falta de testes e qualidadeLink direto para: Falta de testes e qualidade

Todo projeto em desenvolvimento terá bugs — testar é responsabilidade compartilhada entre fornecedor e cliente. Sem testes constantes, bugs se acumulam e o sistema vira uma bomba-relógio.

Precisamos ser sinceros, testar, é critico! E por mais que o desenvolvedor faça tudo com muita atenção, todo projeto em desenvolvimento irá apresentar falhas.
Testes automatizados, ajudam a erros acontecerem menos, mas não os eliminam totalmente, e na maioria dos casos em projetos no Brasil, não são implementados porque aumentam muito o tempo para implementar cada tarefa.

Além dos desenvolvedores testarem, é essencial que cliente use e teste cada versão, com paciência, e até com "vontade de estragar".
Quando se desenvolve um software, acontece um tipo de "cegueira de atenção", onde o foco em desenvolver faz o time repetir sempre as mesmas ações da mesma forma, não testando de maneiras não óbvias. O cliente tem mais facilidade em testar de formas mais aleatórias.

No nosso contrato o cliente concorda em validar cada versão entregue e nos dar feedback. É uma obrigação também dele, junto conosco.

Código "legado" mesmo sendo recenteLink direto para: Código "legado" mesmo sendo recente

Um projeto criado há apenas um ano pode já estar obsoleto se não for atualizado constantemente. No ecossistema moderno (React, Flutter, Python), atualizações acontecem semanalmente — código não atualizado vira legado rapidamente.

A tecnologia avança rápido, e as linguagens e frameworks atuais avançam ainda mais rapidamente. Lembro quando eu trabalhava com Delphi, uma nova versão da linguagem acontecia com anos de distância entre elas, os pacotes também só recebiam atualizações um ou duas vezes ao ano.
Nos dias de hoje, pensando em React, Flutter, Python, as atualizações acontecem numa base semanal ou mensal.
Um projeto criado um ano atrás, pode ser que nem consiga mais ser executado, em função das novas versões das bibliotecas, pacotes e dependências. Já vimos isso acontecer.
O código em um projeto moderno é vivo, precisa ser atualizado, melhorado constantemente, ou acaba virando legado mesmo sendo relativamente novo.
O ecossistema de desenvolvimento hoje é assim.

Questões contratuais que geram problemas de continuidadeLink direto para: Questões contratuais que geram problemas de continuidade

Quando o cliente pega o contrato pra ler durante o andamento do projeto, é sinal que a coisa não vai bem.
Quando reune com o fornecedor pra discutir estes detalhes, e não conseguem concordar em tudo, é porque a coisa está complicada mesmo.
E é difícil lidar com isso se o projeto já não está indo bem, porque o contrato já foi assinado e os termos definidos.

Escopo mal definido e expectativas desalinhadasLink direto para: Escopo mal definido e expectativas desalinhadas

Contrato sem escopo definido gera frustração constante — ninguém sabe exatamente o que será entregue. O escopo protege tanto cliente (garante o que será feito) quanto fornecedor (evita requisitos infinitos).

Um contrato sem o escopo definido, complica muito as coisas. O escopo é o que diz o que deverá ser feito.
Para o cliente é bom que o escopo esteja definido no contrato o projeto, para que o fornecedor não deixe de fazer o que foi definido.
Para o fornecedor é bom para evitar que o cliente surja com requisitos novos e que aumentem o tempo estimado do projeto.

Escopo abertoLink direto para: Escopo aberto

O escopo aberto é quando o projeto será desenvolvido sem um detalhamento total do que será feito. É um jeito de permitir o projeto ir mudando ao longo do caminho, se ajustando ao que surgir, mas sem sair do objetivo principal.
Mesmo nestes casos, é bom que se tenha no contrato uma descrição mínima do esperado, um esqueleto, um esboço do objetivo final e das partes essenciais, para evitar de ouvir um "não sabia que tinha isso".
Neste tipo de contrato normalmente se paga por hora, e o acompanhamento do percentual desenvolvido é um pouco mais complexo, demandando mais gestão do fornecedor.

Escopo fechadoLink direto para: Escopo fechado

É quando no contrato já vem descrito tudo o que será feito, como irá funcionar, quais os recursos, telas, ações e detalhes técnicos.
Durante o projeto as mudanças podem (e vão) surgir, mas toda mudança de rota deve ser medida, verificar o impacto que dará no prazo e preço, e um termo aditivo deve ser assinado, concordando com a mudança e com os impactos da mesma.
Este tipo de projeto normalmente se paga um preço fechado, a não ser quando existe muita complexidade oculta no projeto, ou tecnologias que precisarão ser aprendidas.

Ausência de prazos e SLALink direto para: Ausência de prazos e SLA

Se o fornecedor diz que prazos não podem ser estimados, você está em maus lençóis. Todo projeto precisa de prazos, periodicidade de entregas e regras claras sobre o que fazer em caso de atrasos.

Se o fornecedor tentar te convencer de qualquer maneira que prazos não são possíveis de ser estimados, você está em maus lençóis.
É preciso ter prazos, e é preciso ter regras sobre o que fazer em caso de atrasos. Em linhas gerais é definir de quanto em quanto tempo terão versões, e quando o projeto será entregue.
Cado algo inesperado aconteça, o contrato já deve ditar o que deve ser feito; reuniões, novos acordos e novos documentos assinados com o novo combinado.
Se um problema surgir durante o uso do sistema, em quanto tempo o fornecedor deve atender e em quanto tempo resolverá?

Problemas de propriedade do códigoLink direto para: Problemas de propriedade do código

Todo contrato de desenvolvimento deve garantir que o código é propriedade do cliente. Sem isso, você fica refém do fornecedor — não pode nem trocar de empresa se quiser.

Um caso preocupante é quando o cliente quer repensar se continuará ou não com o fornecedor, porém o contrato não dá ao cliente a propriedade sobre o código. O cliente fica "refém" do fornecedor porque o código sequer é dele.
Não sou advogado mas imagino que se o contrato é o desenvolvimento de um projeto, e que o código está sendo feito só para este caso, é praticamente garantido que o cliente tenha direito sobre o código.
Então é importante que todo contrato de desenvolvimento inclua a clausula de propriedade do código, sempre do cliente.

Contrato sem "amarrações" de sucessoLink direto para: Contrato sem "amarrações" de sucesso

Do ponto de vista do cliente, o contrato deve amarrar pagamento a entregas, e deve ter bem definido o que é o sucesso e o objetivo a ser alcançado.
Deve falar dos direitos dos dois lados que vão além do pagamento, deve falar quantas entregas serão, se devem ser aceitas, o que deve ser feito caso o entregue esteja fora do combinado, ter definições de prazos para correções, ajustes e garantia.
Na pior das hipóteses, o contrato deve dizer como o fornecedor deve passar o projeto para outro fornecedor em caso de quebra, incluindo um tempo mínimo para explicar o andamento e pontos críticos.

O que tenho feitoLink direto para: O que tenho feito

O que eu tenho feito aqui nos contratos da App Masters, muito além de querer só amarrar o cliente e os pagamentos, tento amarrar ao máximo o sucesso do projeto ao contrato.
Da mesma forma que temos deveres, o cliente também deve testar todas as versões e nos dar feedback do que recebeu. Não pode deixar acumular para na reta final testar tudo e complicar o ritmo do projeto.
Uma clausula em especial diz que o final do projeto é crítico, e nas últimas semanas o cliente irá validar e dar feedback de quantas versões forem necessárias, bem como trazer alguns usuários para usar as versões finais, antes de consideramos concluído o projeto. No final do projeto é onde tudo se junta e onde os erros são mais chatos de se lidar.

Seu fornecedor de software falhou: o que fazer agora?Link direto para: Seu fornecedor de software falhou: o que fazer agora?

Antes de tomar qualquer decisão, avalie objetivamente a situação atual do seu projeto.

Criamos uma ferramenta de diagnóstico que funciona como um checklist completo: você responde perguntas sobre comunicação, entregas, qualidade técnica e questões contratuais, e recebe uma análise clara sobre se deve continuar, renegociar ou trocar de fornecedor.

👉 Diagnóstico de projeto de software

Converse com o fornecedor atual (quando possível)Link direto para: Converse com o fornecedor atual (quando possível)

O primeiro passo é ter uma conversa aberta e sincera com o fornecedor e verificar se existe o interesse sincero de dar andamento no projeto, e comprometimento real com o sucesso.
É possível definir um novo prazo e periodicidade nas entregas? É possível assinar um termo aditivo com multas em caso de não cumprimento do acordado?
Se isso já foi feito, se o fornecedor já quebrou sua confiança algumas vezes, talvez seja a hora de seguir em frente.

Documente tudo antes de tomar decisõesLink direto para: Documente tudo antes de tomar decisões

Antes de sair buscando outros fornecedores, você precisará saber algumas coisas essenciais.
O mais importante é a stack de desenvolvimento.
A stack é a coleção de linguagens, frameworks, ferramentas e infra estrutura que o projeto exige.
Empresas diferentes trabalham com stacks diferentes, e sem saber "do que o seu projeto é feito" fica difícil encontrar um novo fornecedor.
Além disso é bom ter descrito de forma clara quais problemas foram enfrentados, qual a razão (técnica) do projeto não estar onde deveria estar?
Se puder juntar imagens das telas, documentos que foram usados para criar o sistema e descrição do que ele faz, tudo isso ajuda.

Realize uma auditoria técnica inicialLink direto para: Realize uma auditoria técnica inicial

Você certamente não é capacitado para avaliar o projeto, então busque quem possa fazê-lo. E neste caso é conectar com a equipe de desenvolvimento e olhar (compartilhando a tela mesmo) e fazer uma análise por alto da arquitetura e situação do código.
Oferecemos isso como serviço, portanto se precisar, pode falar conosco.

Escolha um novo fornecedorLink direto para: Escolha um novo fornecedor

Busque um fornecedor que tenha experiência comprovada no desenvolvimento de projetos iguais ao seu, que tenha disponibilidade e interesse em dar andamento ao projeto.
Boa parte das empresas não aceitam assumir projetos de terceiros, porque realmente é bem complicado, em função da carga cognitiva que é perdida ao passar o projeto, e o volume de código e entendimento que é necessário absorver de uma só vez.
Verifique as sugestões que falei aqui neste post, tanto sobre a prática da empresa quanto questões de contrato, prazos, comunicação e entrega constante de versões. Não siga sem isso.

Planeje a transição de fornecedor de desenvolvimentoLink direto para: Planeje a transição de fornecedor de desenvolvimento

Os dois fornecedores devem se falar, devem concordar sobre os termos da passagem e os detalhes de como será feito.
No mundo ideal o fornecedor anterior passa tudo de boa vontade, e dá um suporte inicial a nova equipe para entender o projeto, acessar os recursos necessários (códigos, servidores, anotações, documentos), para minimizar a dificuldade de retomada do projeto.
Mas se isso não for possível, é "jogar" tudo no novo fornecedor e deixar ele ver como se vira pra fazer acontecer.
Mas, no geral, é bom que haja tratativa de respeito com o fornecedor anterior, mesmo que com a relação já desgastada.

Como fazemos na App MastersLink direto para: Como fazemos na App Masters

Não posso dizer que sou o fornecedor perfeito, mas temos feito o máximo para concluir os projetos com sucesso.
Eu (Tiago Gouvêa) trabalho exclusivamente desenvolvendo sistemas há cerca de 25 anos, e pela App Masters vamos comemorar em 2026, 9 anos de empresa, com muitos projetos feitos para clientes no Brasil e mundo afora.
Mas posso falar o que temos feito para maximizar a chances de sucesso nos projetos.

• Acompanhamento pelo cliente em tempo real do trabalho sendo realizado: através de uma ferramenta nossa é possível ver quem está programando o que, quais as tarefas feitas dia a dia, tempo dedicado em cada uma delas e se o comparativo do percentual do projeto versus o prazo do contrato;
• Comunicação direta com o cliente: incluindo as equipes (daqui e de lá) através do slack para validarmos os detalhes sempre que necessário, antes mesmo da próxima entrega;
• Entregas todas as semanas (sem excessão): desde a primeira semana de trabalho o cliente já acessa o sistema e valida o que foi feito;
• Acesso ao projeto todo: acesso ao código fonte desde o primeiro dia, e criação de uma conta de email que vincula todos os serviços envolvidos no projeto;
• Cobrança por hora ou por escopo fechado: dependendo do tamanho e nível de detalhe do projeto, trabalhamos com o formato que o cliente preferir;
• Acompanhamento de erros em tempo real: utilizamos um serviço que nos avisa de cada erro que acontece com cada usuário, literalmente, nos permitindo fazer correções em tempo recorde;

Buscamos manter uma relação de parceria com os clientes, além do contrato. Sucesso no projeto do cliente significa o nosso sucesso também.

Conclusão: tome a decisão certaLink direto para: Conclusão: tome a decisão certa

Projetos de software que não avançam são mais comuns do que deveriam, infelizmente. Passam meses, o dinheiro vai embora, e o sistema não sai do papel. Mas espero que agora você saiba identificar os sinais de risco antes que seja tarde demais.

Sei que a decisão de trocar de fornecedor não é fácil, envolve dinheiro, tempo, desgate nas relações e principalmente a incerteza se o próximo será melhor.

Por isso criamos uma ferramenta de diagnóstico que ajuda você a avaliar objetivamente a situação do seu projeto. Responda algumas perguntas para nosso Agente de IA e receba uma análise clara sobre o que fazer.

👉 Diagnóstico de projeto de software

Se preferir conversar diretamente, oferecemos auditoria técnica inicial para avaliar o código, arquitetura e viabilidade de continuidade. Entre em contato.

Seu projeto não precisa ficar parado. Tome a decisão certa.