O desenvolvedor não entregou seu aplicativo? Veja o que fazer

Você contratou um desenvolvedor, freelancer ou empresa para criar um aplicativo. O prazo passou, as entregas ficaram aquém do combinado e o produto ainda não pode ser lançado. Em alguns casos, o fornecedor parou de responder. Em outros, entregou telas que parecem prontas, mas o aplicativo apresenta erros, não possui integrações essenciais ou não corresponde ao que foi discutido.

Esse momento costuma combinar prejuízo financeiro, frustração e insegurança. A empresa já investiu dinheiro, dedicou tempo ao projeto e talvez tenha assumido compromissos com clientes, investidores ou parceiros.

A boa notícia é que um aplicativo incompleto não precisa ser automaticamente descartado. Quando existe acesso ao código-fonte, aos ambientes e aos materiais do projeto, outra equipe pode avaliar o que foi desenvolvido, aproveitar partes úteis e organizar a continuidade.

O objetivo não deve ser condenar todo o trabalho anterior nem prometer uma recuperação simples antes de analisar a base. O caminho mais responsável é transformar o aprendizado acumulado em um plano de retomada.

Antes de tudo: sua frustração é legítima

Projetos de aplicativos envolvem incerteza. Mudanças de escopo, integrações mais complexas do que o previsto e decisões demoradas podem afetar o cronograma. Isso não significa, porém, que o cliente deva aceitar falta de transparência, ausência de entregas ou uma solução diferente do que foi contratado.

Alguns sinais de que o projeto precisa de uma intervenção são:

• o prazo foi ultrapassado sem uma nova previsão confiável;
• as entregas não podem ser testadas;
• o fornecedor apresenta sempre a mesma versão;
• as funcionalidades principais continuam incompletas;
• o aplicativo possui muitos erros recorrentes;
• o escopo contratado nunca foi detalhado;
• o desenvolvedor deixou de responder;
• o cliente não possui acesso ao código ou à infraestrutura;
• cada correção gera novos problemas;
• o produto entregue não atende ao processo real do negócio.

Reconhecer o problema não significa que tudo foi perdido. Significa que a empresa precisa recuperar o controle antes de continuar investindo.

Por que projetos de aplicativos ficam incompletos?

Há diferentes causas possíveis. Em alguns casos, o fornecedor não possuía capacidade técnica ou operacional para concluir o projeto. Em outros, o problema começou antes do desenvolvimento, com uma contratação baseada em um escopo superficial.

Entre as causas mais comuns estão:

• funcionalidades descritas de forma genérica;
• estimativa feita sem avaliar integrações;
• dependência de um único desenvolvedor;
• mudanças frequentes sem controle de escopo;
• ausência de critérios de aceite;
• falta de testes durante o projeto;
• cliente sem acesso às versões intermediárias;
• comunicação baseada apenas em mensagens informais;
• tecnologia escolhida sem considerar a evolução do produto;
• prazo comercial incompatível com o trabalho necessário.

Essa análise não serve para procurar culpados. Ela ajuda a evitar que os mesmos problemas sejam repetidos na retomada.

Quando a contratação anterior começou sem um escopo suficientemente claro, vale revisar também o que deve ser avaliado antes de contratar um projeto sob medida.

Não aceite uma condenação automática do código existente

Ao procurar outra empresa, você pode ouvir que todo o aplicativo precisa ser refeito. Em alguns casos, essa realmente será a recomendação correta. Em outros, reconstruir tudo é apenas a alternativa mais confortável para a nova equipe.

Ninguém deveria afirmar que o código não presta sem antes conseguir executá-lo, analisar sua arquitetura e entender o objetivo do produto.

Mesmo um projeto incompleto pode conter partes aproveitáveis:

• telas e fluxos já validados;
• identidade visual;
• estrutura de banco de dados;
• cadastros funcionais;
• integrações parcialmente implementadas;
• painel administrativo;
• regras de negócio descobertas durante o projeto;
• protótipos;
• conteúdo produzido;
• feedbacks de usuários.

O trabalho anterior também produziu conhecimento. Depois de acompanhar o projeto, o cliente normalmente entende melhor quais funções são prioritárias, quais exceções existem e o que realmente precisa estar na primeira versão.

Esse aprendizado pode reduzir o risco da próxima etapa.

O código-fonte é essencial para continuar

Para que outra equipe assuma o aplicativo, é necessário ter acesso ao código-fonte.

O formato mais adequado é o acesso ao repositório utilizado durante o desenvolvimento, como GitHub, GitLab, Bitbucket ou Azure DevOps. O repositório contém o código e, idealmente, o histórico das alterações.

Um arquivo compactado também pode ser analisado, mas oferece menos informações sobre a evolução do projeto.

Além do código, reúna:

• acessos aos repositórios;
• credenciais de hospedagem;
• banco de dados e backups;
• contas da Apple App Store e do Google Play;
• chaves e credenciais de APIs;
• domínios e configurações de DNS;
• contas de envio de e-mail e notificações;
• protótipos e arquivos de design;
• documentação disponível;
• proposta e contrato;
• lista do que foi entregue e do que está pendente.

Também é importante identificar quais contas estão em nome da empresa e quais permanecem sob controle do prestador anterior.

E se o desenvolvedor não entregar o código?

A primeira providência é verificar o contrato. O documento deve indicar quem possui os direitos sobre o código e em que momento os materiais precisam ser disponibilizados.

Alguns contratos estabelecem que o código pertence ao cliente após o pagamento. Outros concedem uma licença de uso ou utilizam componentes próprios do fornecedor.

Se houver uma disputa sobre propriedade intelectual, valores pagos ou obrigações não cumpridas, procure orientação jurídica. Uma nova empresa pode avaliar tecnicamente o material disponível, mas não deve interpretar o contrato como se fosse um escritório de advocacia.

Sem acesso ao código, ainda é possível aproveitar protótipos, dados, fluxos e regras de negócio. Porém, a chance de ser necessário reconstruir partes maiores aumenta.

O primeiro passo da retomada é um diagnóstico

Uma nova equipe responsável não deve prometer uma data definitiva depois de olhar apenas algumas telas.

Antes de apresentar um plano, ela precisa entender o estado real do aplicativo.

O diagnóstico deve responder:

• o projeto pode ser executado em outro ambiente?
• quais funcionalidades estão realmente prontas?
• quais fluxos apresentam erros?
• o aplicativo está conectado a um backend funcional?
• o banco de dados está organizado?
• as integrações estão documentadas?
• há riscos de segurança?
• as tecnologias ainda possuem suporte?
• é possível publicar novas versões nas lojas?
• quanto do trabalho pode ser aproveitado?

O objetivo do diagnóstico não é produzir um relatório extenso para justificar uma nova contratação. É reduzir a incerteza e organizar as decisões.

Como saber se é possível aproveitar o aplicativo?

A quantidade de telas prontas não é suficiente para avaliar a continuidade. Um aplicativo pode parecer quase concluído e ainda possuir problemas graves no backend, na segurança ou na infraestrutura.

A base tende a ser aproveitável quando:

• outra equipe consegue executar o projeto;
• o código possui uma organização minimamente compreensível;
• as tecnologias utilizadas continuam ativas;
• o banco de dados pode ser acessado;
• as falhas podem ser corrigidas de forma progressiva;
• as integrações principais estão acessíveis;
• não existe uma dependência impossível de substituir.

Pode ser mais seguro reconstruir uma parte quando:

• há vulnerabilidades graves;
• senhas ou dados sensíveis estão expostos;
• o aplicativo não funciona fora da máquina do desenvolvedor;
• as regras centrais não correspondem ao negócio;
• cada alteração provoca novos erros;
• a tecnologia foi abandonada;
• o custo de correção supera o de reconstrução.

Mesmo nesses casos, a reconstrução não precisa ignorar o aprendizado anterior. Protótipos, fluxos, conteúdo e feedbacks podem ser reaproveitados.

O escopo precisa ser realinhado antes de continuar

É comum que projetos frustrados tenham começado com descrições como aplicativo de delivery, plataforma de serviços ou área para clientes. Essas expressões comunicam a ideia, mas não definem o que será entregue.

Na retomada, o escopo deve ser organizado em fluxos verificáveis.

Para cada funcionalidade, defina:

• quem utiliza;
• qual problema resolve;
• quais informações são necessárias;
• quais regras precisam ser respeitadas;
• quais erros devem ser tratados;
• como a entrega será homologada;
• o que não faz parte da fase atual.

Também é importante separar três grupos:

• indispensável: necessário para lançar ou operar;
• importante: agrega valor, mas pode entrar depois;
• futuro: deve permanecer no backlog até que o produto esteja estável.

Essa priorização evita transformar a retomada em um novo projeto sem fim.

Crie uma fase de recuperação

Depois do diagnóstico, a próxima contratação não precisa tentar concluir todo o plano original de uma vez.

Uma fase de recuperação pode ter objetivos como:

• colocar o aplicativo em um ambiente controlado;
• recuperar acessos;
• corrigir falhas críticas;
• proteger dados e credenciais;
• concluir a jornada principal;
• estabilizar o backend;
• corrigir uma integração essencial;
• publicar uma versão de homologação;
• criar um backlog confiável.

Essa abordagem devolve previsibilidade ao projeto. Em vez de trabalhar novamente com uma promessa distante, a empresa acompanha entregas menores e verificáveis.

Por que um único desenvolvedor pode representar risco?

Um profissional independente pode executar projetos excelentes. O problema não é contratar um freelancer. O risco aparece quando todo o conhecimento, todos os acessos e todas as decisões ficam concentrados em uma única pessoa.

Se esse profissional fica indisponível, muda de prioridade ou encerra a atividade, o projeto pode parar completamente.

Em uma equipe estruturada, o conhecimento tende a ser distribuído entre diferentes funções, como:

• gestão de projeto;
• análise de produto;
• desenvolvimento mobile;
• backend;
• infraestrutura;
• qualidade e testes;
• design.

Nem todo aplicativo precisa de muitas pessoas trabalhando ao mesmo tempo. O ponto é existir uma organização capaz de preservar o conhecimento e substituir profissionais sem interromper toda a operação.

Experiência e continuidade importam na nova escolha

Depois de uma experiência frustrante, é natural ficar mais cauteloso. Nesse momento, o histórico do novo parceiro deve fazer parte da avaliação.

A Clicksoft atua no mercado desde 2001 e já participou de mais de 600 projetos. Isso não elimina os riscos naturais de desenvolvimento, mas representa uma estrutura construída ao longo de décadas, com processos, equipe e continuidade operacional.

O projeto não depende de uma única pessoa que pode simplesmente deixar de responder. Há uma empresa responsável pela gestão, pela documentação e pela continuidade do trabalho.

Ao avaliar uma nova parceira, pergunte:

• há quanto tempo a empresa atua?
• quem será responsável pelo projeto?
• quem terá conhecimento sobre a base?
• como ocorre a substituição de profissionais?
• onde o código ficará armazenado?
• como as entregas serão demonstradas?
• como os riscos serão comunicados?
• qual será o modelo de suporte após o lançamento?

O artigo sobre como escolher uma empresa para desenvolver seu aplicativo aprofunda esses critérios.

Como um squad por assinatura pode assumir o projeto

Um projeto herdado possui incertezas que nem sempre aparecem no primeiro diagnóstico. Por isso, um contrato fechado com escopo rígido pode não ser a melhor opção para a retomada.

Um squad por assinatura disponibiliza uma capacidade contínua para:

• compreender o código existente;
• corrigir falhas;
• concluir funcionalidades;
• organizar infraestrutura;
• publicar novas versões;
• documentar a solução;
• reduzir débitos técnicos;
• evoluir o produto depois do lançamento.

As prioridades são organizadas em um backlog e executadas por ciclos. Quando um problema oculto aparece, ele pode ser avaliado e comparado com as demais necessidades.

Esse modelo costuma ser adequado quando o aplicativo não precisa apenas ser finalizado, mas também mantido e melhorado ao longo do tempo.

O conteúdo sobre squad para manutenção e evolução de sistemas explica como uma equipe contínua pode assumir uma base existente sem exigir a formação imediata de um time interno.

Quando contratar por horas pode ser melhor

Em situações mais delimitadas, a contratação por horas pode ser utilizada para realizar o diagnóstico ou corrigir um conjunto específico de problemas.

Esse modelo pode fazer sentido quando:

• o cliente ainda não sabe se continuará com a nova equipe;
• o primeiro objetivo é avaliar a qualidade do código;
• há uma lista curta de erros;
• é necessário recuperar uma publicação nas lojas;
• o projeto precisa de uma integração pontual;
• a empresa quer começar com um ciclo menor.

Quando o estado da base ainda é incerto, um pacote inicial pode ser usado para entender o projeto. Depois disso, a equipe apresenta cenários de continuidade.

Veja também quando um contrato por horas para desenvolvimento faz sentido.

Como evitar ficar refém do próximo fornecedor

A retomada deve corrigir não apenas o aplicativo, mas também a forma como o projeto é controlado.

Algumas práticas reduzem a dependência:

• manter o repositório em uma conta da empresa;
• manter contas das lojas em nome da empresa;
• centralizar acessos e credenciais;
• receber versões frequentes;
• registrar decisões de escopo;
• participar das homologações;
• manter backups;
• documentar integrações críticas;
• garantir que mais de uma pessoa conheça a solução.

O cliente não precisa saber programar. Precisa ter visibilidade e acesso aos ativos que sustentam o produto.

Não tente recuperar o prejuízo aumentando o escopo

Depois de perder tempo, algumas empresas tentam compensar incluindo mais funcionalidades na nova etapa. Essa reação é compreensível, mas perigosa.

A prioridade deve ser colocar o fluxo principal em funcionamento.

Antes de adicionar recursos, responda:

• o usuário consegue concluir a jornada principal?
• os dados são armazenados corretamente?
• os pagamentos ou integrações funcionam?
• o aplicativo pode ser publicado?
• os erros críticos foram eliminados?
• há monitoramento e backup?

Depois que a base estiver estável, o produto pode voltar a evoluir.

Sinais de que a retomada está funcionando

Uma recuperação saudável não é aquela em que a nova equipe promete resolver tudo rapidamente. É aquela em que a incerteza diminui a cada ciclo.

Alguns sinais positivos são:

• o aplicativo pode ser executado por mais de uma pessoa;
• os acessos estão centralizados;
• os problemas foram classificados por prioridade;
• há uma versão disponível para testes;
• as decisões ficam registradas;
• os riscos são explicados com transparência;
• o backlog começa a diminuir;
• os usuários participam da homologação;
• a próxima entrega possui um objetivo claro.

O que levar para a primeira conversa

Não espere organizar todo o projeto antes de procurar ajuda. Reúna o que estiver disponível:

• contrato e proposta;
• links para as versões existentes;
• código-fonte;
• acessos disponíveis;
• protótipos;
• prints e vídeos dos erros;
• lista de funcionalidades esperadas;
• integrações utilizadas;
• principais prejuízos causados pelo atraso;
• prioridade atual do negócio.

A nova equipe poderá ajudar a organizar o restante durante o diagnóstico.

Perguntas frequentes

Outra empresa pode continuar o aplicativo desenvolvido por um freelancer?

Sim. Para isso, a nova equipe precisa ter acesso ao código-fonte, aos ambientes, ao banco de dados e aos serviços externos. Antes de assumir prazo e orçamento, ela deve avaliar a qualidade e o estado da base.

É sempre necessário refazer o aplicativo?

Não. Muitas bases podem ser aproveitadas integral ou parcialmente. A reconstrução deve ser indicada quando existem riscos técnicos, problemas de segurança ou um custo de correção maior do que o de uma nova implementação.

O que fazer quando o desenvolvedor não responde?

Organize todas as comunicações, revise o contrato e solicite formalmente os acessos e materiais previstos. Quando houver disputa contratual ou de propriedade, procure orientação jurídica.

É possível retomar o projeto sem documentação?

Sim, mas o diagnóstico tende a exigir mais tempo. A nova equipe pode reconstruir parte do conhecimento analisando o código, o banco de dados, as telas e as conversas com os usuários.

Um squad por assinatura consegue finalizar um aplicativo?

Sim. O squad pode diagnosticar a base, corrigir falhas, concluir funcionalidades, publicar o aplicativo e continuar sua evolução. O modelo é especialmente útil quando o esforço exato ainda não é conhecido.

Como evitar que o problema aconteça novamente?

Mantenha o código e as contas sob controle da empresa, acompanhe versões frequentes, registre o escopo, defina critérios de aceite e escolha uma equipe com estrutura de continuidade.

Conclusão

Quando um desenvolvedor não entrega o aplicativo, a frustração pode levar à sensação de que todo o investimento foi perdido. Nem sempre é assim.

Com acesso ao código-fonte, aos ambientes e aos materiais do projeto, uma nova equipe pode avaliar o que existe, preservar as partes úteis e organizar uma retomada progressiva.

O trabalho anterior não precisa ser tratado como lixo. Ele contém decisões, aprendizados e componentes que podem encurtar o caminho até uma versão funcional.

A Clicksoft atua desde 2001, já participou de mais de 600 projetos e trabalha com uma estrutura que não depende de um único desenvolvedor. Se seu aplicativo ficou incompleto, conheça o modelo de squad por assinatura da Clicksoft para avaliar a base existente, recuperar o controle do projeto e dar continuidade ao desenvolvimento.