Projeto de software muda de escopo, isso é da natureza do trabalho. O contrato não serve para congelar o escopo, e sim para definir como ele muda: critério de aceite, aditivo, titularidade do código e onde termina a garantia.
Trial grátis · sem cartão de crédito
A maior parte dos contratos de desenvolvimento que dão errado não erra no preço, erra ao tentar fixar um escopo que ninguém consegue prever inteiro no começo. Software descobre requisito enquanto é construído. Um contrato realista aceita isso e resolve o problema no processo: define o que está fechado agora, define o que conta como entrega aceita e define o caminho pelo qual um pedido novo vira aditivo com prazo e valor, em vez de virar favor. É a diferença entre renegociar com um documento na mão e renegociar no grito.
A segunda questão é a titularidade do código. A Lei 9.609/1998 protege programa de computador no regime de direito autoral e, no artigo 4, estabelece que, salvo estipulação em contrário, os direitos sobre o programa desenvolvido durante o contrato pertencem ao empregador ou ao contratante dos serviços, quando o desenvolvimento decorre da própria natureza do trabalho contratado. Repare na expressão salvo estipulação em contrário: a regra padrão existe, mas ela cede diante do que o contrato disser. É a sua cláusula que decide, nos dois sentidos, e quem entrega sem cláusula nenhuma aceitou um padrão sem nunca ter lido.
Há ainda um ponto que quase todo freelancer aprende do jeito difícil: você não pode ceder o que não é seu. Todo projeto moderno carrega dezenas de dependências de terceiros com licenças próprias, e uma cláusula que promete transferência integral e irrestrita de tudo que foi entregue é uma promessa que o código não cumpre. Ressalvar bibliotecas de terceiros e componentes de código aberto no contrato é honestidade técnica, não letra miúda.
As cláusulas que mais evitam discussão depois da assinatura.
Cada entrega precisa de uma definição objetiva do que significa pronto. Sem critério de aceite, a etapa nunca fecha e o pagamento fica preso numa discussão sem régua.
Defina como um pedido novo entra: estimativa por escrito, aprovação e ajuste de prazo e valor. Sem esse caminho, toda mudança entra de graça pela porta dos fundos.
Diga se o código é transferido ao cliente na entrega ou licenciado, e ressalve bibliotecas de terceiros e componentes de código aberto, que seguem as licenças próprias delas.
Separe as duas: correção de defeito por um período definido é garantia; funcionalidade nova é manutenção evolutiva e se cobra à parte. Misturar as duas gera suporte vitalício.
Vincule cada parcela a um milestone aceito, com juros e suspensão de trabalho previstos em caso de atraso. Etapa aceita e não paga não deveria destravar a etapa seguinte.
Registre sigilo, a devolução ou revogação de credenciais no fim do projeto e o papel de cada parte no tratamento de dados pessoais, se o sistema lidar com eles.
O que costuma dar errado quando o combinado fica só no verbal.
Se pronto não tem definição, quem define é a expectativa do cliente no dia da entrega, e ela cresce junto com o tempo que o projeto levou para chegar lá.
Nenhum projeto é 100% autoral: há bibliotecas de terceiros com licenças próprias. Uma promessa ampla demais é impossível de cumprir e enfraquece o contrato inteiro.
Corrigir bug de algo que foi entregue é obrigação por um prazo. Atender pedido novo seis meses depois não é, mas vira, se o contrato não separar as duas coisas.
Quem paga a hospedagem, quem é dono das contas de nuvem e o que acontece com as credenciais no fim do projeto são perguntas que só aparecem quando a relação termina.
Sim, e é a cláusula que não deveria ficar em branco. A Lei 9.609/1998 traz uma regra padrão para o caso de silêncio, mas ela vale salvo estipulação em contrário: é o contrato que decide se o código é cedido ao cliente na entrega ou licenciado, sempre ressalvando as bibliotecas de terceiros, que seguem as licenças delas.
Sim. Você divide o pagamento por milestones, e cada etapa aceita pelo critério definido no contrato libera a parcela correspondente. É o formato que mais reduz risco dos dois lados em projeto longo.
Prevendo o caminho em vez de proibir a mudança: pedido novo gera estimativa por escrito, aprovação do cliente e ajuste de prazo e valor. O documento vira a referência da conversa, não o obstáculo.
Não há número obrigatório, e o que importa é delimitar. Trinta a noventa dias para correção de defeito no que foi entregue é a faixa mais comum entre freelancers, com manutenção evolutiva cobrada à parte.
Sim. Muda a cláusula de honorários e a de entregáveis: no escopo fechado você amarra milestones, na alocação você amarra horas, relatório de apontamento e limite mensal.
Se o sistema tratar dados pessoais, sim: vale registrar o papel de cada parte, as medidas de segurança e o destino dos dados no fim do projeto. Para projeto que não toca dado pessoal, a cláusula de sigilo costuma bastar.
Este conteúdo é informativo e não substitui orientação jurídica. Para contratos de valor elevado ou situações fora do comum, vale a revisão de um advogado antes do envio.
Mesmo produto, cláusulas pensadas para cada tipo de trabalho.