# Seu sistema interno depende de uma pessoa só? > Quando o sistema interno depende de uma pessoa, o risco não é ela sair. É o que só existe na cabeça dela. Veja as quatro camadas a tirar de lá antes da saída. - Autor: Marlon Trettin - Publicado: 2026-10-18 · Atualizado: 2026-10-18 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/sistema-interno-depende-de-uma-pessoa --- Se o sistema interno depende de uma pessoa só, o risco não é ela sair. É o que só existe na cabeça dela: as senhas, o código que ninguém mais abriu, o jeito de subir uma correção e o motivo de cada regra. Decidir que tudo isso more na empresa é arquitetura, e a decisão vem antes do aviso prévio. ## TL;DR - Num estudo com 133 projetos populares de código aberto, [65% dependiam de no máximo duas pessoas](https://arxiv.org/abs/1604.06766) para não travar. Concentrar conhecimento em poucas pessoas é comum em software, mesmo quando o código é público. - Num levantamento com mais de 36 mil projetos, [89% perderam o time central ao menos uma vez](https://arxiv.org/abs/2412.00313), e, entre os projetos abandonados, só 27% conseguiram atrair um novo desenvolvedor central. - A dependência tem quatro camadas: acesso, código, ambiente e decisões. Cada uma pode ser tirada da pessoa e posta no nome da empresa. - Contratar CLT, PJ ou um studio não resolve isso sozinho. O que resolve é definir, por escrito, o que precisa ficar com a empresa quando qualquer um deles for embora. ## Por que a saída de uma pessoa trava um sistema inteiro? Porque, na maior parte das PMEs, o sistema interno nasceu pela mão de alguém que fazia tudo. Escreveu o código, contratou o servidor, registrou o domínio, criou as integrações e decidiu as regras de negócio conversando com o dono no corredor. Funcionou. É por isso que ninguém mexeu. O problema aparece no dia em que essa pessoa pede para sair, adoece ou simplesmente para de responder rápido. Nesse momento a empresa descobre que o sistema é dela no contrato e de outra pessoa na prática. O mercado brasileiro deixa esse cenário mais provável, não menos. Segundo o relatório da Brasscom, [noticiado pela Teletime em julho de 2026](https://teletime.com.br/07/07/2026/tic-33-mil-vagas-formais-2026-brasscom/), o setor de tecnologia ganhou 111,1 mil profissionais entre 2023 e 2025, e 55,6% dessas vagas foram ocupadas por MEIs e trabalhadores informais. Mais da metade de quem entrou nesse mercado no período trabalha, portanto, sem vínculo empregatício. E quem trabalha assim pode trocar de cliente com um aviso curto. ## O que os dados mostram sobre concentração de conhecimento? Que ela é o estado normal de um projeto de software, mesmo onde tudo está à vista. A medida usada pela engenharia de software se chama truck factor: o número mínimo de pessoas que precisam sair para o projeto travar. Pesquisadores da UFMG calcularam esse número para [133 projetos populares hospedados no GitHub](https://arxiv.org/abs/1604.06766). Em 65% deles, ele era de uma ou duas pessoas. Um estudo divulgado em dezembro de 2024 ampliou a amostra para [mais de 36 mil projetos de código aberto](https://arxiv.org/abs/2412.00313). Os autores encontraram que 89% perderam o time central ao menos uma vez, que 70% dessas perdas aconteceram nos três primeiros anos do projeto e que a maioria dos projetos depende de um único desenvolvedor central. Dos projetos abandonados, só 27% conseguiram atrair alguém para ocupar esse lugar. Esses números vêm de código aberto, e isso importa. São projetos em que o código está publicado, o histórico é visível e qualquer pessoa pode estudar o que foi feito. Não existe medição pública equivalente para sistemas internos de PME. O que dá para afirmar é o sentido da diferença: no sistema interno, o código costuma estar fechado, o histórico às vezes nem existe e o único leitor possível é quem escreveu. ## A dependência é da pessoa ou do que ela carrega? Do que ela carrega. E o que ela carrega se divide em quatro camadas, cada uma com uma pergunta objetiva. ### Acesso Em nome de quem estão o domínio, a conta do servidor, o repositório de código, o banco de dados e as chaves das integrações? Se a resposta é o CPF ou o cartão de crédito de uma pessoa, a empresa não controla o próprio sistema. Essa é a camada mais barata de corrigir e a mais cara de descobrir tarde. ### Código O código está num repositório da empresa, com histórico de alterações, ou numa máquina pessoal e numa pasta compartilhada? Código sem histórico mostra o que o sistema faz hoje e esconde tudo o que já foi tentado e desfeito. ### Ambiente Outra pessoa consegue colocar uma correção no ar sem ligar para quem escreveu? Se o processo de publicação depende de um passo que só uma pessoa sabe fazer, o sistema pode estar perfeitamente documentado e mesmo assim ficar parado. ### Decisões Por que o desconto é calculado daquele jeito? Por que aquele campo é obrigatório? A pesquisa ["Bus Factor In Practice"](https://arxiv.org/abs/2202.01523), apresentada no ICSE 2022 com respostas de 269 engenheiros, mostrou que o conhecimento de um projeto circula também por revisões de código e reuniões, não só pelo código. Numa PME, esse canal costuma ser a conversa no corredor. Ela não fica registrada em lugar nenhum. As quatro camadas têm uma ordem. Acesso vem primeiro porque sem ele as outras três não servem para nada. Decisões vêm por último porque são as mais demoradas, e é justamente a camada que faz um sucessor entender o sistema em vez de só conseguir abri-lo. ## Um exemplo, e ele é uma hipótese Imagine uma distribuidora com faturamento na casa de R$ 600 mil por mês. Há três anos, um desenvolvedor PJ construiu o sistema de pedidos. Ele atende bem, conhece a operação, e o sistema roda sem incidentes relevantes. Ele avisa que aceitou uma proposta e sai em 30 dias. Na primeira reunião de transição, a empresa descobre que o domínio está no CPF dele, que o servidor é pago no cartão pessoal dele, que o código está num repositório da conta dele e que a regra de comissão dos vendedores foi combinada por mensagem com um diretor que já saiu. Nada disso é má-fé. É o resultado natural de três anos em que ninguém perguntou em nome de quem as coisas estavam. Os 30 dias vão para transferir contas, e não sobra tempo para transferir entendimento. A situação é inventada. O que acontece depois dela, não. A [Colo Saúde](/cases/colo-saude) chegou à Yowpi com uma plataforma construída por um fornecedor anterior, sem dono técnico e sem ninguém do time que a conhecesse por dentro. O primeiro projeto foi um resgate: auditoria de segurança e ajuste de performance, antes de qualquer evolução. Na [Stella e Farias](/cases/stella-farias), o sistema tinha sido escrito pelo próprio fundador, e o trabalho foi corrigir bugs e integrar um novo frontend ao sistema existente, sem reescrever do zero. ## Contratar ou terceirizar muda esse risco? Muda a forma, não a existência. Um CLT pode sair com aviso de 30 dias. Um PJ pode sair com menos. Um studio pode encerrar o contrato ou trocar a equipe alocada. Em todos os casos, a pergunta que protege a empresa é a mesma: o que fica com ela no dia seguinte? A diferença está no que dá para exigir. De um funcionário, a empresa exige por política interna. De um fornecedor, exige em contrato: contas no CNPJ do cliente desde o primeiro dia, código no repositório do cliente, processo de publicação descrito e decisões de negócio registradas junto com o código. O [artigo sobre contratar dev ou terceirizar](/blog/contratar-dev-ou-terceirizar-pme) discute a escolha em si. Aqui, o ponto é que qualquer uma das escolhas precisa dessa cláusula para não virar dependência. ## Quatro perguntas para fazer esta semana Não precisa de auditoria para começar. Precisa de uma conversa de uma hora com quem mantém o sistema hoje, com estas quatro perguntas: 1. Quais contas o sistema usa, e em nome de quem está cada uma? 2. Onde está o código, e alguém além de quem mantém o sistema tem acesso a ele? 3. Se quem mantém o sistema ficasse fora por duas semanas, quem conseguiria publicar uma correção, e como? 4. Quais são as três regras do sistema que mais geram dúvida, e onde está escrito o motivo delas? As respostas mostram em qual das quatro camadas a sua empresa está exposta. Se a primeira pergunta já mostrar uma conta no CPF de alguém, você tem motivo suficiente para a segunda conversa. ## Perguntas frequentes **Não tenho ninguém técnico para conferir as respostas. Por onde começo?** Comece pela camada de acesso, que não exige conhecimento técnico. Peça a lista de contas e confira se o titular é o CNPJ da empresa. Isso você verifica sozinho, olhando faturas e cadastros. As outras camadas pedem alguém que leia código, e aí vale uma avaliação externa. **Terceirizar para um studio não troca uma dependência por outra?** Troca, se o contrato não disser o que fica com você. A dependência de um fornecedor é administrável quando as contas estão no seu CNPJ, o código está no seu repositório e as decisões estão registradas. Nesse cenário, trocar de fornecedor é trabalhoso, mas possível. Sem isso, é recomeço. **O sistema funciona e a pessoa não tem planos de sair. Vale mexer agora?** Vale, justamente porque agora a conversa é tranquila. Com a pessoa disponível, transferir contas e registrar decisões é um trabalho curto e feito em colaboração. Depois que ela sai, o mesmo trabalho vira engenharia reversa, mais lenta, que nem sempre recupera o motivo das regras. ## O próximo passo Se as respostas mostraram camadas que ainda estão com uma pessoa, o [Diagnóstico de Arquitetura Operacional](/contato) é uma conversa de 30 minutos para mapear essas camadas e a ordem de transferência.