A sua aplicação já existe. Foi desenvolvida por uma agência, um freelancer ou uma equipa interna — e hoje, por uma razão ou outra, procura outra pessoa para a retomar. O prestador original já não está disponível, os prazos alongam-se, a comunicação degradou-se, ou simplesmente sente que paga cada vez mais por cada vez menos.
É uma situação muito comum, e bastante mais gerível do que parece. Eis como a abordamos.
«É arriscado confiar o meu código a quem não o escreveu?»
É o primeiro receio, e é legítimo. A resposta honesta: o risco não é mudar de prestador, é escolher alguém que se precipita.
Retomar código é, antes de mais, aceitar viver com decisões que não tomámos. Um bom sucessor começa por compreender, não por julgar. Põe a aplicação existente a funcionar, lê o código, identifica o que funciona — e distingue o que realmente atrapalha daquilo que apenas lhe desagrada. Um prestador que, logo no primeiro dia, propõe refazer tudo ainda não o compreendeu: está a vender o seu próprio conforto, não o seu interesse.
O que fazemos antes de tocar no código
Uma retoma séria passa por uma fase de enquadramento:
- Assumir o existente: recuperar o código, os acessos, a documentação (mesmo incompleta) e voltar a pôr a aplicação a funcionar do nosso lado.
- Mapear o que lá está: as funcionalidades, as dependências, os pontos frágeis, a dívida técnica real.
- Entregar uma primeira vez sem partir nada. O primeiro valor que um sucessor traz é demonstrar que domina o terreno — uma pequena correção, uma atualização aguardada, uma colocação em produção limpa.
Só depois desta fase podemos dizer-lhe, com provas, o que merece ser mantido, corrigido ou refeito.
É preciso reescrever tudo?
Quase nunca. Recomeçar do zero é tentador — é mais confortável para o programador — mas é muitas vezes a pior decisão para si: volta a pagar o que já funcionava e reintroduz erros que tinham sido corrigidos ao longo dos anos.
A abordagem certa é cirúrgica. Numa aplicação móvel de uma mútua de saúde que retomámos, o esforço concentrou-se nos 20% da app onde o nativo mudava realmente a experiência — o resto, que funcionava, foi conservado. Numa plataforma de reservas, primeiro retomámos o existente e depois reformulámos apenas o front-end, enquanto o back-end permanecia no lugar. E numa plataforma médica que trata dados de saúde, dois anos depois, a questão de saber quem escreveu que parte já nem se coloca: o código passou a ser nosso pelo facto de o mantermos, sem nunca ter sido preciso reescrevê-lo.
Uma reformulação proposta no primeiro dia é uma opinião. A mesma reformulação proposta depois de ter posto o existente a funcionar em produção é um diagnóstico — e só uma das duas é que um cliente tem razão em financiar.
Sinais de que a retoma é o momento certo
- As evoluções demoram cada vez mais para cada vez menos resultado.
- Já não sabe bem o que faz a sua aplicação nem como está construída.
- Uma só pessoa detém todo o conhecimento, e já não está disponível.
- Cada atualização do iOS ou do Android torna-se um stress.
- Não tem a certeza de possuir realmente o seu código.
Este último ponto merece verificação: o seu código deve pertencer-lhe. Connosco, pertence-lhe sempre, sem exceção.
Como começar
Uma retoma começa sempre por uma conversa e um acesso de leitura ao existente. A partir daí, entregamos-lhe um diagnóstico claro: o que está bem, o que está bloqueado e o que recomendamos — sem jargão e sem o empurrar para uma reescrita de que não precisa.
É o cerne do nosso trabalho de desenvolvimento à medida. Tem uma aplicação para retomar? Vamos falar: a primeira conversa é gratuita e sem compromisso.