Quem deve ser o proprietário do código-fonte, da nuvem e dos acessos

O proprietário do código-fonte, das contas de nuvem e dos acessos deve ser o contratante — desde o primeiro dia do projeto, não a partir da entrega final. Qualquer arranjo em que os ativos vivem em contas do fornecedor cria uma dependência que só aparece quando a relação piora: exatamente a hora em que ela custa mais caro.

Código-fonte

O repositório deve estar na organização do contratante (GitHub, GitLab ou equivalente), com o fornecedor trabalhando como colaborador convidado. O contrato deve prever cessão de propriedade intelectual do código produzido — e a prática deve refletir o contrato: commits chegando ao repositório do contratante durante a execução, não um “pacote final” prometido para depois da quitação. Condicionar a entrega do código ao pagamento é legítimo em contrato; executar o projeto inteiro em repositório do fornecedor não é a única forma de fazer isso, e é a pior para o contratante.

Nuvem e serviços

Conta de nuvem (AWS, Google Cloud, Azure), domínios, e-mail transacional, gateways de pagamento e ferramentas de monitoramento: tudo em contas criadas pelo contratante, com faturamento no cartão do contratante. O fornecedor recebe acesso, não posse. Migrar uma infraestrutura que nasceu na conta errada custa dias de trabalho e risco de indisponibilidade — criar a conta certa no primeiro dia custa uma hora.

Acessos e credenciais

Credenciais administrativas ficam em cofre de senhas do contratante, com o fundador ou alguém de confiança como proprietário. Cada pessoa do fornecedor acessa com credencial própria e revogável — nunca com a conta-raiz compartilhada. Ao fim do contrato, revogar acessos deve ser uma operação de minutos, não uma negociação.

Checklist de titularidade

• Repositório na organização do contratante, com histórico completo de commits.
• Cessão de propriedade intelectual do código no contrato.
• Nuvem, domínios e serviços em contas e faturamento do contratante.
• Credenciais em cofre do contratante; acessos individuais e revogáveis para o fornecedor.
• Documentação de ambientes e de deploy entregue junto com o código, não depois.