Contrato de software não é burocracia: é o documento que decide se, daqui a dois anos, você tem um sistema ou tem um fornecedor.
A diferença aparece no dia em que você quer trocar de time, ou no dia em que o fornecedor some. Aí não adianta o sistema ser ótimo.
Estas oito cláusulas cobrem os problemas que a gente vê acontecer. Nenhuma é hostil, e um fornecedor sério aceita todas sem discussão.
1. O código é seu, por escrito
Esta é a mais importante do texto.
Sem cláusula de cessão de direitos, a autoria fica com quem escreveu. Não é malandragem do fornecedor: é o padrão legal. Ter pago não transfere a propriedade automaticamente.
O que pedir: cessão total e definitiva dos direitos patrimoniais sobre o código produzido, com entrega em repositório ao qual você tem acesso durante o projeto, não só no fim.
Acesso durante o projeto importa mais do que parece. Se você só recebe no fim, e o fim não chega, você não tem nada.
2. A documentação é entregável, não favor
Código sem documentação é código que só a pessoa que escreveu mantém. Isso é vendor lock-in por outro nome, mesmo quando ninguém quis que fosse.
O que pedir, listado como entregável com prazo:
- como subir o ambiente do zero, passo a passo
- o que cada parte faz e por quê
- as decisões que não são óbvias e o motivo delas
- como publicar uma alteração
3. As contas ficam no nome da sua empresa
Nuvem, domínio, contas de desenvolvedor da Apple e do Google, serviço de e-mail, meio de pagamento.
Quando essas contas estão no nome do fornecedor, trocar de fornecedor vira recomeçar. E, no caso das lojas de aplicativo, pode significar publicar o app de novo, do zero, perdendo avaliações e histórico.
O fornecedor pode ter acesso. O titular tem que ser você.
4. Pagamento por etapa entregue
Nem tudo adiantado, nem tudo no fim.
Parcelas ligadas a entregas que funcionam protegem os dois lados: você não paga por promessa, e o fornecedor não trabalha meses sem receber. Quando uma parcela está ligada a algo que você consegue abrir e usar, a conversa sobre andamento deixa de ser subjetiva.
5. O escopo diz o que NÃO está incluído
Escopo que só lista o que entra deixa as bordas em aberto, e é sempre na borda que nasce a discussão.
Peça que esteja escrito, explicitamente: o que fica para uma fase seguinte, quantas rodadas de revisão estão previstas, quem escreve os textos, quem fornece imagens, e como uma mudança de escopo é tratada, porque ela vai acontecer, e o problema nunca é a mudança: é não ter combinado antes como ela mexe no prazo e no preço.
6. Garantia com prazo, separada de evolução
Duas coisas diferentes que costumam ser confundidas de propósito:
- Garantia: corrigir o que foi entregue com defeito. Tem prazo, e não se cobra por ela.
- Evolução: acrescentar o que não estava no escopo. É trabalho novo, e se cobra.
Sem essa separação no papel, ou você paga para consertar defeito, ou o fornecedor entrega melhoria de graça até o relacionamento azedar. Os dois terminam mal.
7. Saída combinada, funcione ou não
A cláusula que ninguém quer discutir no começo e que todo mundo queria ter discutido no fim.
O que pedir: em caso de encerramento, por qualquer motivo, o fornecedor entrega em prazo definido o código, a documentação, as credenciais e um período de transição para quem assumir.
Um fornecedor confiante concorda sem hesitar. A reação a essa cláusula já é informação sobre com quem você está falando.
8. Confidencialidade e dados, nos dois sentidos
Seu dado de cliente vai passar pela mão de quem constrói. Precisa estar escrito o que pode ser acessado, por quem, e o que acontece com as cópias no fim do projeto.
Com a LGPD, isso deixou de ser cortesia e virou obrigação de quem trata dado pessoal, dos dois lados.
O que nunca aceitar
| Cláusula | Por que é ruim |
|---|---|
| Código permanece do fornecedor | você alugou, não comprou |
| Contas no nome do fornecedor | trocar de time é recomeçar |
| Escopo aberto sem critério de mudança | a discussão vai acontecer no pior momento |
| Mensalidade obrigatória para manter acesso | o sistema é refém |
| Sem prazo de garantia definido | defeito vira orçamento |
| Multa alta para encerrar, sem entrega de ativos | você paga para sair sem levar nada |
O teste rápido
Se você levar essas oito à mesa e o fornecedor resistir a uma delas, peça o motivo. Pode haver razão legítima, e vale ouvir.
Se resistir a três ou mais, a proposta barata tem uma condição escondida: ela só é barata enquanto você ficar.
Perguntas frequentes
O código do sistema é meu ou do fornecedor?
Depende do que está escrito. Sem cláusula de cessão de direitos, a autoria fica com quem escreveu. Isso não é armadilha do fornecedor, é o padrão legal. Por isso a propriedade precisa estar explícita no contrato, e não presumida porque você pagou.
O que é vendor lock-in e como evitar?
É ficar preso a um fornecedor porque sair custa caro demais. Evita-se com três coisas no contrato: o código é seu e fica num repositório que você acessa, a documentação é entregável, e as contas de nuvem e serviços ficam no nome da sua empresa. Faltando qualquer uma, você aluga em vez de comprar.
Preciso de contrato para projeto pequeno?
Precisa, e num projeto pequeno ele pode ser curto. O que não pode faltar é escopo, prazo, forma de pagamento, propriedade do código e o que acontece se alguém quiser encerrar. Isso cabe em duas páginas e evita a discussão que costuma aparecer justamente nos projetos pequenos.
Como pagar sem correr risco?
Parcelando por etapa entregue, não por tempo passado. Cada parcela ligada a algo funcionando protege os dois lados: você não paga por promessa e o fornecedor não trabalha meses sem receber. Pagamento integral adiantado e pagamento só no fim são ruins, cada um para um lado.
E se eu quiser trocar de fornecedor no meio?
Se o contrato previu, é transição. Se não previu, é recomeço. A cláusula que resolve exige entrega do código, da documentação e das credenciais em prazo definido, funcione a relação ou não. Ninguém gosta de negociar isso no começo, e é exatamente por isso que precisa ser no começo.
