vocês pegam um sistema que já existe?
sim. a gente começa com uma revisão curta (o que ele faz, em que estado está, onde mora o risco) e te entrega uma avaliação por escrito antes de mexer em qualquer coisa. às vezes a resposta honesta é que reescrever sai mais barato do que consertar.
a maior parte do trabalho que chega pra gente não começa do zero. é o site que a agência anterior largou, ou um app cujo desenvolvedor original sumiu, ou um sistema que funciona e ninguém tem coragem de mexer. isso é normal, e não quer dizer reescrever tudo por padrão.
a revisão vem antes
antes de mudar uma linha, a gente lê o código, a infraestrutura e o histórico. a avaliação por escrito que você recebe cobre três coisas:
- o que ele faz: os recursos que existem de verdade, e não os que todo mundo acha que existem.
- em que estado está: dependência perto do fim da vida útil, teste que não existe, hospedagem que ninguém consegue acessar, credencial no histórico do git.
- onde mora o risco: o que vai quebrar em seguida, e as brechas que um pentest encontraria.
esse documento serve com ou sem a gente. se a resposta honesta for que reescrever sai mais barato do que consertar, a gente escreve isso lá, com o motivo, e a decisão é sua.
os três caminhos mais comuns dali pra frente
- resgate e adoção. quem construiu foi embora, então a gente documenta, estabiliza e assume dali pra frente.
- junto com os seus desenvolvedores. a gente pega o que eles não cobrem, normalmente segurança ou infraestrutura, e deixa combinado por escrito quem cuida de quê.
- só segurança. você mantém o seu time e aponta o app pra gente revisar. esse trabalho não depende do resto; veja segurança num app que não foi a gente que fez.
manda o link do repositório, ou um acesso, e conta o que está te preocupando. link ajuda mais do que descrição longa.