O que um contrato de developer freelancer do Reino Unido deve incluir?

Um contrato de developer freelancer do Reino Unido deve nomear as partes, o escopo de trabalho (SOW) ou backlog, o aceite, os ambientes, o controle de mudanças, o honorário, de quem é o código, as práticas de trabalho IR35, um teto de responsabilidade, e o que acontece se cancelar ou pagar atrasado. Assine antes do primeiro commit.

Esta página trata primeiro da England and Wales. O direito autoral pelo Copyright, Designs and Patents Act 1988 vale em todo o Reino Unido. Off-payroll working (IR35) é uma regra tributária do Reino Unido. O caminho da ação de cobrança para uma fatura não paga é o procedimento da England and Wales em O que fazer quando um cliente não paga a fatura do meu trabalho freelance.

Não há um modelo de acordo de desenvolvimento de software no Contracts.io. Comece por um contrato de freelancer ou um contrato de prestador independente. Uma construção de site pode começar por uma criação de site. Trabalho recorrente pendura um escopo de trabalho sob um contrato de prestação de serviços. Um espaço mensal de manutenção fica em um retainer. Trabalho mais pesado de estratégia pode começar por um contrato de consultoria. Se você está compartilhando código inédito antes de o acordo ser assinado, um NDA mútuo fica ao lado. Contratos para developers é a página de público mais curta. O que um contrato de web design do Reino Unido deve incluir? é a página irmã do trabalho de site.

Dez blocos fazem o trabalho:

O sinal de 40% é um exemplo, não uma taxa legal. Escreva os números que você realmente usa.

O que vai em um contrato de freelancer ou de prestador de serviços compara os modelos. Como escrever um contrato é o checklist geral. Esta página é a versão do developer.

Não envie um arquivo Word por e-mail e torça para que v4_final seja o que eles assinaram. Os dois lados devem editar e assinar eletronicamente um único rascunho compartilhado.

Você, a menos que ceda. O CDPA 1988 s.11 faz do autor o primeiro titular do direito autoral freelancer. Uma cessão só é eficaz se for por escrito, assinada. Pagar a fatura não transfere a titularidade. Ceda o código sob medida no pagamento integral. Licencie suas bibliotecas e ferramentas.

O CDPA 1988 s.11 é a regra do primeiro titular. A exceção para empregados na s.11(2) se aplica a empregados, não a um developer sob um contrato de prestação de serviços. Encomendar uma build não transfere o direito autoral. Se o contrato calar, um tribunal pode reconhecer uma licença implícita limitada para a finalidade da encomenda. Isso não é titularidade. O silêncio é como um cliente leva o repo a outra loja e alega que achava que o tinha comprado.

O CDPA 1988 s.90 é a regra da cessão. Uma cessão de PIcessão de PIUma cessão de PI é a transferência da titularidade do trabalho, para que o cliente seja dono dele em vez de quem o criou.Mais no glossário precisa ser por escrito, assinada por você ou por alguém que assine em seu nome. Uma licençalicençaUma licença é a permissão para usar um trabalho de um jeito combinado, sem tirar a titularidade de quem o criou.Mais no glossário é permissão de usar a obra. Não é uma transferência de titularidade. Veja licença de PI versus cessãolicença de PI versus cessãoUma cessão de PI transfere a titularidade do copyright ou de outra propriedade intelectual. Uma licença é permissão de uso; o autor continua dono. Na England & Wales não há regra de first owner work-made-for-hire para freelancers: Copyright, Designs and Patents Act 1988 s.11. Uma cessão precisa ser por escrito e assinada: s.90. Diga qual você quer dizer, e quando acontece.Mais no glossário.

Um título americano de “work for hireobra por encomenda (work for hire)Obra por encomenda (work for hire) é uma expressão, comum em contratos ao estilo dos EUA, que significa que o cliente é tratado como autor e dono do trabalho desde o início.Mais no glossário” não faz esse trabalho na England and Wales. Veja obra por encomenda (work for hire). Escreva cessão ou licença em palavras claras.

Mantenha quatro pilhas:

• Código sob medida — os entregáveis nomeados. Cedidos ou licenciados no pagamento integral.
• Suas bibliotecas — componentes, CLIs, starters anteriores. Licenciadas para este trabalho, não cedidas.
• Open-source — componentes de terceiros nas próprias licenças. Você não pode cedê-los.
• Notas de trabalho — spikes, branches descartadas, ferramentas locais. Não incluídas a menos que precificadas.

Em um contrato de serviços entre empresas há uma condição implícita de que você executará o serviço com cuidado e habilidade razoáveis — Supply of Goods and Services Act 1982 (lei britânica de fornecimento de bens e serviços) s.13. Essa condição não transfere o direito autoral.

Exemplo

Mediante o recebimento do pagamento integral, o Developer cede ao Cliente o direito autoral no código sob medida dos Entregáveis. Até então o Cliente não tem licença para copiá-los, publicá-los, comunicá-los ou adaptá-los, salvo se o Developer concordar por escrito. Materiais preexistentes, bibliotecas, ferramentas e componentes open-source de terceiros permanecem com o Developer ou seus licenciadores e são licenciados apenas como parte dos Entregáveis.

Em linguagem simples: eles são donos do código customizado depois de pagar. Não podem publicar trabalho não pago. O seu starter kit e as bibliotecas de outras pessoas ficam nos próprios termos.

Escreva isso na cláusula de cessão de propriedade intelectual. Se publicarem trabalho não pago, veja Cliente usando seu trabalho sem pagar.

Mantenha três pilhas. O código sob medida é cedido ou licenciado no pagamento integral. Suas bibliotecas e ferramentas preexistentes continuam suas e são licenciadas para este trabalho. Componentes open-source ficam nas próprias licenças — divulgue-os. Você não pode ceder uma licença que não possui.

Uma cláusula de terceiros que funciona responde a quatro coisas:

• O quê. Bibliotecas nomeadas que você escreveu antes, um starter kit, pacotes de terceiros de que o trabalho precisa.
• Quem é dono da licença. Seu código continua seu. Open-source fica nos termos que os autores publicaram. O cliente não compra esses direitos autorais ao pagar você.
• O que você divulga. Uma lista de componentes de terceiros e a licença que cada um já carrega. Não invente um nome de licença. Copie o nome do pacote.
• O que você garante. Que não vai inserir material sem direito de uso. Não que um pacote upstream vá ficar compatível para sempre.

O CDPA 1988 s.90 é a regra para o seu direito autoral. Não transfere uma licença open-source de terceiro. Mantenha isso como materiais preexistentes ou como licenças de terceiros, não como finais cedidas.

Se você está compartilhando um repo inédito antes de o acordo ser assinado, um NDA mútuo fica ao lado do documento da build.

Exemplo

Materiais preexistentes, bibliotecas e ferramentas permanecem com o Developer e são licenciados ao Cliente somente na medida necessária para usar os Entregáveis. Componentes open-source de terceiros permanecem nas próprias licenças. O Developer divulgará esses componentes e a licença que cada um já carrega. O Developer não cede essas licenças. O Developer garante que, até onde o Developer sabe, os Entregáveis não incluem material de terceiro que o Developer tenha introduzido sem direito de fazê-lo.

Em linguagem simples: eles ganham uma licença para usar o seu kit neste produto. Não compram a sua caixa de ferramentas. Open-source fica na licença que já tem. Você diz o que usou.

Escreva um escopo de trabalho (SOW) ou um backlog nomeado, como é o “pronto”, em quais ambientes você entrega, e como uma mudança é precificada. “Um produto” não é uma lista. Épicos extras são controle de mudanças, não um favor. Assine o SOW antes do primeiro commit.

Um escopo que funciona responde a cinco coisas:

• A lista. Épicos nomeados, stories ou uma data de freeze do backlog. Um checkout não é um marketplace. Uma API não é uma UI de admin.
• Aceite. Testes escritos, um demo no staging, uma janela de defeitos. Um defeito é uma falha em bater com o SOW. “Temos uma ideia nova” é uma mudança.
• Ambientes. Quem hospeda dev, staging e production. Quem segura as contas de nuvem. Quem pode promover para production.
• O que fica fora. Um segundo app, anúncios pagos, conteúdo, plantão contínuo — a menos que estejam na lista do que entra.
• Controle de mudanças. Um épico novo é orçado e assinado primeiro. Veja Cliente continua pedindo trabalho extra e controle de mudanças.

Um limite de revisõeslimite de revisõesUm limite de revisões diz quantas rodadas de alterações estão incluídas no valor antes de o trabalho extra ser orçado.Mais no glossário dá o acabamento a uma tela combinada. Não é um segundo produto sem honorário.

Se o contrato diz que variações precisam ser por escrito e assinadas, um sim no Slack não reescreve o trabalho. Rock Advertising Ltd v MWB Business Exchange Centres Ltd [2018] UKSC 24 dá efeito a essa cláusula.

Exemplo

Os Entregáveis são os itens do Anexo 1. O Developer avisará que um Entregável está pronto no ambiente de staging. O Cliente o testará em 10 dias úteis e o aceitará por escrito ou listará defeitos em relação ao Anexo 1. O silêncio após esse prazo conta como aceite. Trabalho adicional, épicos extras ou trabalho fora do Anexo 1 são orçados e acordados por escrito antes de o trabalho começar. O Developer entrega no staging. A promoção para production é o passo do Cliente, salvo se o Anexo 1 disser o contrário.

Em linguagem simples: eles recebem o backlog nomeado. Dez dias úteis para cutucar o staging. Se não disserem nada, está aceito. Um épico novo é um honorário novo. Eles apertam o botão de production, a menos que você também tenha precificado isso.

Clientes recorrentes costumam ficar sob um contrato de prestação de serviços mais um escopo de trabalho por trabalho. Um site de marketing pode começar por uma criação de site.

Diária paga pelo tempo. Preço fixo e marcos pagam por resultados nomeados. Não existe um direito padrão no Reino Unido de ficar com um sinal ou de cobrar uma taxa de cancelamento (kill feetaxa de cancelamento (kill fee)Uma taxa de cancelamento (kill fee) é um pagamento devido a um criador ou fornecedor quando o cliente cancela um projeto antes de ele terminar.Mais no glossário) — as duas partes precisam combinar os valores. Escreva um sinal antes de o trabalho começar. Para um cliente empresarial a cobrança não pode ser uma cláusula penal.

Escolha um formato de honorário e escreva-o:

Um sinal de 30–50% na assinatura, com o trabalho pausado até ele cair, é o formato freelance habitual. Uma taxa de cancelamento (kill fee) fica ao lado: trabalho feito mais uma fatia nomeada do honorário restante se eles cancelarem por conveniência. Veja cancelamento e taxa de cancelamento (kill fee) e condições de pagamento.

Para um cliente empresarial, uma cobrança de cancelamento combinada que é, na prática, uma quantia devida por descumprimento não pode ser uma cláusula penal. Cavendish Square Holding v Makdessi [2015] UKSC 67 pergunta se uma obrigação secundária impõe um prejuízo totalmente desproporcional a um interesse legítimo no cumprimento. Vincule o valor ao tempo reservado, aos custos assumidos e a outros trabalhos recusados. Uma cobrança de 100% em número redondo desde o dia da assinatura, sem ligação com esses interesses, é o formato que parece punição.

A divisão mais longa está em Cliente cancelou: você pode ficar com o sinal?.

Exemplo

O Cliente pagará 40% do Honorário na assinatura e o saldo no aceite dos Entregáveis. O Developer não iniciará até receber a primeira quantia. Se o Cliente cancelar por conveniência depois de o trabalho ter começado, o Cliente pagará pelo trabalho feito até a data e uma taxa de cancelamento de 25% do Honorário restante. Quantias já pagas são creditadas nesse total. A propriedade intelectual em trabalho não integralmente pago permanece com o Developer.

Em linguagem simples: 40% caem na conta antes de você começar. Se eles desistirem depois que você já está trabalhando, pagam pelo que está feito mais um quarto do que resta. Não são donos do código não pago.

Esses percentuais são exemplos, não uma taxa legal. Num trabalho por diária, escreva a taxa, o mínimo de dias, e que dias cancelados já reservados na agenda ainda vencem se você recusou outro trabalho.

Escreva um vencimento curto, um direito de pausar se uma fatura estiver atrasada, e que nenhuma licença ou cessão vale até o pagamento integral. Para um cliente empresarial do Reino Unido, os juros legais sobre pagamento comercial em atraso são 8% acima da taxa básica do Bank of England, mais um valor fixo de recuperação. Não publicamos a taxa básica atual.

As condições de pagamento devem nomear:

• quando as faturas saem — na assinatura, num ponto médio, no aceite
• quantos dias para pagar — net 14 ou net 30Net 30Net 30 significa que o cliente tem 30 dias a partir da data da fatura para pagar.Mais no glossário vence um “quando compras rodar da próxima vez” em aberto
• um direito de pausar se uma fatura não contestada estiver atrasada, inclusive o direito de não promover para production
• que o direito autoral, ou qualquer licença de uso do trabalho, só passa no pagamento integral

Para uma dívida empresarial elegível, o Late Payment of Commercial Debts (Interest) Act 1998 (lei britânica de juros por atraso em dívidas comerciais) fixa os juros legais. O GOV.UK sobre pagamentos comerciais em atraso indica a taxa como 8% mais a taxa básica do Bank of England. Depois que esses juros correm, também é devido um valor fixo de recuperação: £40 abaixo de £1,000, £70 de £1,000 a menos de £10,000, e £100 a £10,000 ou mais, mais quaisquer custos razoáveis de cobrança não cobertos por essa quantia. Veja juros por atraso no pagamento. A lei de 1998 não se aplica a um cliente consumidor.

Uma taxa contratual, se você nomear uma, é a taxa a que você aponta em vez da taxa legal. Não invente um valor sem ligação com a lei ou com o documento.

Exemplo

Cada fatura não contestada vence em 14 dias da respectiva data. O Developer poderá pausar o trabalho, e não está obrigado a entregar acesso de production, enquanto qualquer fatura não contestada estiver atrasada há mais de 7 dias. O direito autoral e qualquer licença de uso dos Entregáveis passam ao Cliente somente com o pagamento integral. Até então o Cliente não tem direito de copiar, publicar, comunicar ou adaptar os Entregáveis.

Em linguagem simples: eles têm duas semanas para pagar. Depois de uma semana de atraso, o trabalho para e a production fica fechada. Não são donos do código, e não podem publicá-lo, até pagar.

A sequência de cobrança — exigência escrita, carta prévia à ação (letter before action), ação de cobrança — está em O que fazer quando um cliente não paga a fatura do meu trabalho freelance.

Nenhum rótulo decide o imposto. A partir de 6 de abril de 2021, autoridades públicas e clientes médios ou grandes devem emitir uma Status Determination Statement. Clientes pequenos do setor privado deixam essa decisão com a sua empresa. Escreva autonomia, substituição genuína e mutualidade para que batam com o jeito em que você de fato trabalha.

As regras de off-payroll working estão no ITEPA 2003. A partir de 6 de abril de 2021, quando serviços são prestados por um intermediário a uma autoridade pública ou a um cliente médio ou grande com vínculo com o Reino Unido, o cliente deve emitir uma Status Determination Statement. Essa declaração deve dizer se o trabalhador seria empregado se contratado diretamente, explicar as razões e ser alcançada com cuidado razoável.

Quando serviços são prestados por um intermediário a uma pessoa que não é autoridade pública e que se qualifica como pequena no ano fiscal, aplica-se o Capítulo 8. Uma empresa se qualifica como pequena num ano fiscal se o regime de small companies da Companies Act 2006 (lei britânica de sociedades) se aplica ao seu último exercício financeiro relevante para aquele ano fiscal. A empresa do trabalhador então decide o status.

O que o contrato ainda pode fazer é descrever a relação de trabalho com precisão:

• Autonomia. Você decide como entregar o resultado combinado. O cliente define o resultado, os prazos e regras razoáveis do local, não os métodos do dia a dia.
• Substituição genuína. Você pode enviar um substituto devidamente qualificado, pago por você. Um veto ilimitado do cliente torna o direito irreal.
• Mutualidade. Cada escopo de trabalho é um engajamento separado. Nenhum dos lados é obrigado a oferecer ou aceitar mais trabalho quando um engajamento termina.

A HMRC olha o contrato e as práticas de trabalho em conjunto. Uma cláusula de substituição que o cliente nunca permitiria na prática não carrega o status. Coloque a substituição na cláusula de cessão e subcontratação de um contrato de prestador independente ou contrato de freelancer, não num e-mail à parte.

O checklist mais longo — Capítulo 8 e Capítulo 10, a Status Determination Statement e a redação favorável a “fora” — é checklist de cláusulas contratuais IR35. Esta página não inventa redação além disso.

Exemplo

O Developer decide como entregar o resultado combinado. O Cliente pode definir o resultado, os prazos e regras razoáveis de acesso, não os métodos do dia a dia. O Developer pode enviar um substituto devidamente qualificado, pago pelo Developer. Cada escopo de trabalho é um engajamento separado. Nenhum dos lados é obrigado a oferecer ou aceitar mais trabalho quando um engajamento termina.

Em linguagem simples: você toca o como. Eles compram o quê. Você pode mandar outra pessoa que dê conta do trabalho. Este SOW é este SOW — não uma promessa do mês que vem.

Limite a responsabilidade a um múltiplo dos honorários. Na England and Wales você não pode excluir responsabilidade por morte ou lesão corporal causada por negligência. Se você acessa dados pessoais nos sistemas do cliente, o tratamento precisa de um contrato vinculante de operador. Veja o guia mais longo de responsabilidade.

Uma limitação de responsabilidade que funciona nomeia:

• o teto — em geral os honorários pagos sob o SOW, ou um múltiplo nomeado
• o que fica ilimitado — responsabilidade por morte ou lesão corporal causada por negligência não pode ser excluída nem restringida (Unfair Contract Terms Act 1977 s.2, lei britânica de cláusulas contratuais abusivas). Outra responsabilidade por negligência só pode ser limitada na medida em que a cláusula seja razoável
• se uma indenização fica dentro do teto ou o fura

A página mais longa é Como um freelancer deve limitar a responsabilidade?.

Se você trata dados pessoais para o cliente — bancos de production, exportações de usuários, acesso de suporte — o artigo 28(3) do UK GDPR exige um contrato que o vincule como operador. Deve indicar o objeto e a duração do tratamento, a natureza e a finalidade, o tipo de dados pessoais e as categorias de titulares, e os termos de operador do artigo 28(3)(a)–(h). Veja proteção de dados. Não finja que uma linha “você cumprirá a lei de proteção de dados” é esse contrato.

Num contrato de serviços empresariais também há uma condição implícita de que você executará o serviço com cuidado e habilidade razoáveis — Supply of Goods and Services Act 1982 s.13. Um teto fica ao lado dessa condição. Não a apaga.

Exemplo

A responsabilidade total do Developer sob este acordo fica limitada aos honorários pagos sob o escopo de trabalho relevante. Nada neste acordo limita a responsabilidade por morte ou lesão corporal causada por negligência. Quando o Developer tratar dados pessoais para o Cliente, esse tratamento será regido pelos termos de operador do Anexo 2.

Em linguagem simples: se der errado, você responde até os honorários daquele trabalho. Não dá para se eximir de matar alguém por descuido. Se tocar nos dados dos usuários deles, escreva o papel de operador, não um clima.

Nomeie quem ganha acesso, a quais repos e contas de nuvem, com qual privilégio, e quando o acesso termina. Use contas nomeadas, não uma senha compartilhada. No encerramento, você devolve as credenciais e eles revogam as suas. Escreva isso como prática, não como cláusula de estatuto penal.

Uma cláusula de acesso que funciona responde a cinco coisas:

• O quê. Hosts Git, consoles de nuvem, CI, rastreadores de erro, analytics, DNS do domínio.
• Quem. Pessoas nomeadas, em contas nomeadas. Sem senha root compartilhada num DM do Slack.
• Privilégio. Least privilege para o trabalho. Acesso de escrita em production só se o SOW disser que você promove.
• Segredos. Onde vivem deploy keys e tokens. Quem os rotaciona.
• Encerramento. Você devolve ou destrói credenciais. Eles revogam o seu acesso na data final, ou num descumprimento material.

Não segure chaves de production como refém de uma fatura não paga. O direito de pausar e a linha de PI já fazem esse trabalho: sem cessão, e sem dever de promover, enquanto uma fatura não contestada estiver atrasada. Uma briga de bloqueio é como uma dívida pequena vira uma disputa maior.

Se você está compartilhando um repo inédito antes de o acordo ser assinado, coloque um NDA mútuo ao lado da lista de acesso.

Exemplo

O Cliente concederá ao Developer acesso aos repositórios e contas de nuvem listados no Anexo 1, em contas nomeadas e no privilégio ali indicado. O Developer não compartilhará essas credenciais. No encerramento, ou a pedido escrito do Cliente, o Developer devolverá ou destruirá credenciais sob o controle do Developer, e o Cliente revogará o acesso do Developer.

Em linguagem simples: eles te deixam entrar num login nomeado. Você não passa as chaves adiante. Quando acaba, você devolve as chaves e eles trancam a porta.

Só se o contrato disser isso. Uma cessão do código, por si só, não lhe dá o direito de pôr o produto no seu site. Escreva uma licença de volta: canais nomeados, se você pode nomear o cliente, e se trabalho confidencial fica fora do portfólio até o lançamento.

Uma cláusula de portfólio que funciona responde a quatro coisas:

• Onde. Seu site, redes, showreel impresso, palestras.
• O quê. O produto público, não branches inéditas nem a arquitetura rejeitada.
• Quando. Depois do lançamento, ou depois de um embargo nomeado.
• Crédito. Se você nomeia o cliente, e se eles nomeiam você. Crédito por código é uma promessa contratual.

Veja publicidade e uso no portfólio. Se o trabalho é confidencial — um produto ainda não lançado, uma build ainda em sigilo — escreva que a licença começa no lançamento público deles, ou com consentimento escrito. O silêncio é como um case study vai ao ar na semana anterior ao anúncio.

Exemplo

O Developer poderá reproduzir o produto público no portfólio do Developer e no site e nos canais de redes sociais do Developer, e poderá nomear o Cliente como o encomendante, depois do lançamento, ou antes com o consentimento escrito do Cliente. Esta licença não se estende a branches inéditas, URLs de staging nem informação confidencial.

Em linguagem simples: depois que estiver público, você pode mostrar o produto no ar e nomeá-los. Não pode mostrar os caminhos que eles mataram, nem vazar o lançamento.

Se recusarem qualquer uso em portfólio, isso é uma questão de preço. Coloque isso no documento antes de começar.

O trabalho termina quando os entregáveis nomeados são aceitos, ou quando o aviso se esgota. Entregue repos, credenciais e docs. Código não pago continua seu. Depois disso, o suporte fica num retainerretainerUm retainer é um acordo em que o cliente paga uma taxa regular para garantir uma quantidade de horas ou acesso contínuo a um fornecedor.Mais no glossário, ou fica com o cliente. Não deixe “a gente vai acompanhando” como uma promessa aberta.

Uma entrega que funciona responde a cinco coisas:

• Quando a build termina. Aceite no staging, ou uma data final nomeada.
• O que passa. Repos, admin de nuvem, CI, DNS, logins de terceiros, runbooks.
• O que fica. Suas ferramentas locais, spikes não usados, bibliotecas que você não cedeu.
• A garantia. Defeitos em relação ao SOW por um número nomeado de dias. É uma janela contratual, não um acréscimo legal ao CDPA.
• O retainer. Horas por mês, tempos de resposta, se horas não usadas rolam, como termina. Veja retainer.

Se quiserem você de plantão depois do lançamento e não houver retainer, isso é um trabalho novo. Como encerrar um contrato freelance é a página mais longa de encerramento.

Exemplo

O engajamento termina no aceite dos Entregáveis, ou no aviso do Anexo 1. O Developer entregará os repositórios, o acesso de administrador de nuvem, CI, registros DNS e logins de terceiros listados no Anexo 1. Defeitos em relação ao Anexo 1 reportados em 30 dias do aceite são corrigidos sem custo. Hospedagem, plantão e mudanças posteriores a essa janela são um retainer separado, ou são orçados como trabalho extra. A propriedade intelectual em trabalho não integralmente pago permanece com o Developer.

Em linguagem simples: você entrega, passa as chaves, conserta bugs reais por um mês. Depois eles pagam pelo cuidado, ou tocam sozinhos. Código não pago continua seu.

No Contracts.io os dois lados redigem, negociam e assinam eletronicamente um único acordo de developer compartilhado, então o SOW, a linha de PI e a taxa de cancelamento (kill fee) são a versão que vocês dois assinaram. Descreva o trabalho em uma frase. A Lex, nossa anfitriã de IA, redige. Você compartilha um link. Ninguém fica mandando v4_final.docx de lá para cá por e-mail.

O cliente abre esse link. Pode Aceitar, Contrapropor ou Recusar na mesma versão, e depois os dois assinam eletronicamente. A outra parte nunca paga e não precisa de conta.

Comece por um contrato de freelancer ou um contrato de prestador independente. Uma construção de site pode começar por uma criação de site. Trabalho recorrente pode pendurar um escopo de trabalho sob um contrato de prestação de serviços. Depois do lançamento, um retainer cobre o cuidado. Você também pode começar pelo gerador de contratos com IA ou pelo gerador de contratos. Se você está compartilhando código inédito antes de o acordo ser assinado, o gerador de NDA ou um NDA mútuo fica ao lado.

Isso não emite uma determinação de status IR35 para o cliente. Mas significa que o escopo de trabalho, a cessão de PI ou a licença, o sinalsinalUm sinal é um dinheiro pago adiantado, antes do trabalho principal ou da fatura final.Mais no glossário, a taxa de cancelamento (kill fee) e o teto de responsabilidadelimite de responsabilidadeUm limite de responsabilidade é o valor máximo que uma parte pode ser obrigada a pagar à outra sob um contrato.Mais no glossário são as palavras que vocês dois assinaram, não uma linha perdida no e-mail.

Free £0, depois planos pagos a partir de £15 por mês — veja /pricing.

Experimente no contracts.io: descreva a build em uma frase, compartilhe um link e assine eletronicamente antes do primeiro commit.

Contratos para developers é o conjunto mais amplo de termos que cerca este documento. Contratos para web designers é a página irmã de site. Checklist de cláusulas contratuais IR35 é a página de status. Devo começar o trabalho antes de o contrato ser assinado? é a regra do primeiro dia.