Fim de projeto com software house, o checklist de encerramento

O momento mais negligenciado de um projeto de software é o encerramento. O sistema está no ar, todo mundo quer comemorar e ninguém quer abrir planilha de pendências. Meses depois, a empresa descobre que não tem acesso ao código, que o servidor está no cartão de crédito de um sócio da fornecedora e que ninguém sabe como o sistema funciona por dentro.

Nada disso é drama raro: aparece com frequência nas conversas com contratantes na Softdex. A boa notícia é que um encerramento bem feito cabe em um checklist. Este é o roteiro do que pedir, conferir e documentar antes de dar o aceite final.

1. Código fonte completo, em repositório seu

O código é seu por contrato (se não for, o problema começou antes; veja o que verificar no contrato). No encerramento, isso precisa virar posse concreta: peça a transferência do repositório para uma conta da sua empresa (GitHub, GitLab ou Bitbucket em nome do seu CNPJ) ou, no mínimo, um arquivo com todo o código fonte e o histórico de versões.

Prefira o repositório ao zip: o histórico de commits documenta a evolução do sistema e facilita a vida de qualquer equipe futura. E confira se o pacote inclui tudo: scripts de banco de dados, arquivos de configuração de exemplo, assets de design e o código de eventuais integrações.

2. Documentação do projeto

Documentação de projeto sob medida não precisa ser um livro, precisa permitir que outro time assuma sem arqueologia. O mínimo aceitável: como rodar o projeto do zero (README), arquitetura geral e serviços usados, modelo do banco de dados, documentação das APIs e um mapa das integrações com terceiros. Se a software house usou ferramentas de documentação automática, peça o acesso ou a exportação.

Um teste prático: se um desenvolvedor externo conseguir subir o ambiente e entender o sistema em um dia usando só o que foi entregue, a documentação está boa.

3. Acessos e credenciais, tudo no nome da sua empresa

Faça um inventário: domínio e DNS, hospedagem e cloud, contas nas lojas de aplicativo, serviços de e-mail transacional, gateways de pagamento, ferramentas de monitoramento, chaves de API de terceiros. Cada item deve estar em conta de propriedade da sua empresa, com a software house como convidada (e não o contrário).

Contas no nome da fornecedora são o problema mais comum do pós-projeto: funcionam até o dia em que a relação esfria, o boleto não é repassado ou a empresa fecha. Resolver isso no encerramento custa uma reunião; resolver dois anos depois pode custar o sistema.

4. Próximos passos combinados por escrito: hospedagem, manutenção, evolução

Sistema entregue não é sistema parado: dependências desatualizam, certificados vencem, bugs aparecem com o uso real. Antes do aceite, deixe três coisas definidas por escrito: quem opera a hospedagem e quanto custa por mês, qual o período de garantia para correção de bugs (30 a 90 dias é praxe de mercado) e qual o modelo de manutenção depois disso, seja um contrato mensal com a própria software house, um banco de horas ou a transição para time interno.

Se a decisão for trocar de fornecedor ou internalizar, esse é o momento de negociar a transição de conhecimento: uma ou duas sessões de handover gravadas valem ouro.

5. Demonstração de dashboards e painéis administrativos

Se o projeto inclui painel administrativo, dashboard de métricas ou área de gestão de conteúdo, peça uma demonstração completa, gravada. É comum a equipe do cliente conhecer só o fluxo principal do produto e descobrir funcionalidades administrativas por acidente, meses depois. A gravação vira material de treinamento para quem chegar à equipe no futuro.

Aproveite a sessão para validar com dados reais: relatórios que fazem sentido em demo às vezes se comportam diferente com o volume de produção.

6. Para startups: ative os créditos de cloud antes de escalar

Se o seu produto roda em AWS, Google Cloud ou Azure, os três têm programas de créditos para startups que podem cobrir a infraestrutura do primeiro ano ou mais: AWS Activate, Google for Startups Cloud Program e Microsoft for Startups. Os valores variam com o estágio e o vínculo com aceleradoras e fundos, e costumam ir de alguns milhares a centenas de milhares de dólares em créditos.

O detalhe que importa no encerramento: os programas pedem que a conta cloud esteja no nome da startup, e algumas condições valem para contas novas ou recentes. Se a infraestrutura ficou na conta da software house durante o desenvolvimento, migre para a sua antes de solicitar o benefício, e faça a solicitação antes de a conta acumular histórico longo de faturamento. Vale a mesma lógica para créditos de outras ferramentas do stack, de bancos de dados gerenciados a plataformas de e-mail.

7. Feche o ciclo: avalie a software house

O encerramento é também o momento de registrar como foi a experiência, com a memória fresca. Uma avaliação honesta ajuda o mercado inteiro: é o que permite que os próximos contratantes escolham melhor, e é o que faz as boas software houses se destacarem. Se a empresa que atendeu você está no diretório da Softdex, a avaliação leva minutos e passa por verificação.

Perguntas frequentes

A software house pode se recusar a entregar o código fonte? Depende do contrato. Se o contrato prevê cessão de propriedade intelectual (o padrão em desenvolvimento sob medida), a entrega é obrigação. Por isso a cláusula precisa ser verificada antes de assinar, como detalhamos nos 3 pontos de contrato para revisar.

O que é um período de garantia razoável? Entre 30 e 90 dias para correção de defeitos sem custo adicional, contados do aceite. Garantia cobre bug, não funcionalidade nova; a diferença entre os dois deve estar clara no contrato.

Preciso manter a software house na manutenção? Não é obrigatório, mas nos primeiros meses costuma ser a opção mais eficiente, porque o time que construiu conhece o sistema. Se optar por trocar, faça a transição com handover estruturado e documentação em dia.

Esqueci de pedir essas coisas no encerramento. E agora? Peça agora. Quanto mais tempo passa, mais difícil fica: pessoas saem da software house, contas expiram, a memória do projeto se perde. Se a relação terminou bem, a maioria das empresas resolve as pendências sem atrito.