¿Qué debe incluir un contrato de desarrollador freelance del Reino Unido?

Un contrato de desarrollador freelance del Reino Unido debe nombrar a las partes, el alcance del trabajo (SOW) o el backlog, la aceptación, los entornos, el control de cambios, los honorarios, de quién es el código, las prácticas de trabajo IR35, un tope de responsabilidad, y qué pasa si cancelan o pagan tarde. Fírmalo antes del primer commit.

Esta página trata primero England and Wales. Los derechos de autor conforme a la Copyright, Designs and Patents Act 1988 (Ley de Derechos de Autor, Diseños y Patentes de 1988) valen en todo el Reino Unido. El off-payroll working (IR35) es una norma fiscal británica. La vía de reclamación de dinero por una factura impagada es el procedimiento de England and Wales en Un cliente no paga una factura de freelance.

No hay una plantilla de contrato de desarrollo de software en Contracts.io. Parte de un acuerdo de freelance o de un acuerdo de contratista independiente. Un desarrollo de sitio puede partir de un contrato de desarrollo web. El trabajo recurrente cuelga un alcance del trabajo (SOW) bajo un contrato de servicios. Un hueco mensual de cuidado se sienta en una iguala. El trabajo muy estratégico puede partir de un acuerdo de consultoría. Si compartes código no publicado antes de firmar el trato, un NDA mutuo se sienta al lado. Contratos para desarrolladores es la página de audiencia más corta. ¿Qué debe incluir un contrato de diseño web del Reino Unido? es el hermano de encargos de sitio.

Diez bloques hacen el trabajo:

El depósito del 40% es un ejemplo, no un tipo legal. Escribe las cifras que usas de verdad.

Qué va en un acuerdo de freelance o de contratista compara plantillas. Cómo escribir un contrato es la lista general. Esta página es la versión para desarrolladores.

No envíes un archivo Word y esperes que v4_final sea el que firmaron. Ambas partes deben editar y firmar electrónicamente un único borrador compartido.

Tuyo, salvo que lo cedas. La CDPA 1988 s.11 hace al autor el primer titular de los derechos de autor freelance. Una cesión no es eficaz a menos que conste por escrito y esté firmada. Pagar la factura no mueve el título. Cede el código a medida con el pago íntegro. Licencia tus bibliotecas y herramientas.

CDPA 1988 s.11 es la regla del primer titular. La excepción del empleado en s.11(2) se aplica a empleados, no a un desarrollador con un contrato de servicios (contract for services). Encargar un desarrollo no transfiere los derechos de autor. Si el contrato calla, un tribunal puede hallar una licencia implícita limitada al fin del encargo. Eso no es titularidad. El silencio es cómo un cliente se lleva el repo a otro taller y dice que pensaba haberlo comprado.

CDPA 1988 s.90 es la regla de cesión. Una cesión de propiedad intelectualcesión de propiedad intelectualUna cesión de propiedad intelectual (IP assignment) es una transferencia de la titularidad del trabajo, de modo que lo posee el cliente y no quien lo hizo.Más en el glosario tiene que constar por escrito, firmada por ti o por alguien que firme en tu nombre. Una licencialicenciaUna licencia (licence) es el permiso para usar un trabajo de una forma acordada, sin quitar la titularidad a quien lo creó.Más en el glosario es permiso para usar la obra. No es una transferencia de titularidad. Consulta licencia de PI frente a cesiónlicencia de PI frente a cesiónUna cesión de PI transfiere la titularidad del copyright u otra propiedad intelectual. Una licencia es permiso para usarla; el autor sigue siendo titular. En Inglaterra y Gales no hay una regla de primer titular work-made-for-hire para freelances: Copyright, Designs and Patents Act 1988 s.11. Una cesión debe constar por escrito y firmada: s.90. Di cuál quieres, y cuándo ocurre.Más en el glosario.

Un encabezado estadounidense de «work for hireobra por encargo (work for hire)Work for hire es una expresión, común en documentos de estilo estadounidense, que significa que el cliente se trata como autor y dueño del trabajo desde el principio.Más en el glosario» no hace ese trabajo en England and Wales. Consulta obra por encargo (work for hire). Escribe cesión o licencia en palabras inglesas.

Guarda cuatro montones:

• Código a medida — los entregables nombrados. Cedidos o licenciados con el pago íntegro.
• Tus bibliotecas — componentes, CLIs, starters anteriores. Licenciadas para este encargo, no cedidas.
• Open-source — componentes de terceros en sus propias licencias. No puedes cederlas.
• Notas de trabajo — spikes, ramas descartadas, herramientas locales. No incluidas salvo que estén presupuestadas.

En un contrato de servicios entre empresas hay un término implícito de que prestarás el servicio con cuidado y pericia razonables — Supply of Goods and Services Act 1982 s.13 (Ley de Suministro de Bienes y Servicios de 1982). Ese término no mueve los derechos de autor.

Ejemplo

A la recepción del pago íntegro el Desarrollador cede al Cliente los derechos de autor del código a medida de los Entregables. Hasta entonces el Cliente no tiene licencia para copiarlos, publicarlos, comunicarlos o adaptarlos salvo que el Desarrollador lo acuerde por escrito. Los materiales preexistentes, bibliotecas, herramientas y componentes open-source de terceros se quedan con el Desarrollador o sus licenciantes y se licencian solo como parte de los Entregables.

En lenguaje sencillo: son dueños del código a medida una vez que han pagado. No pueden publicar trabajo impagado. Tu starter kit y las bibliotecas de otros se quedan en sus propios términos.

Escríbelo en la cláusula de cesión de propiedad intelectual. Si publican trabajo impagado, consulta Cliente que usa tu trabajo sin pagar.

Guarda tres montones. El código a medida se cede o se licencia con el pago íntegro. Tus bibliotecas y herramientas preexistentes siguen siendo tuyas y se licencian para este encargo. Los componentes open-source se quedan en sus propias licencias — decláralos. No puedes ceder una licencia que no te pertenece.

Una cláusula de terceros que funciona responde a cuatro cosas:

• Qué. Bibliotecas nombradas que escribiste antes, un starter kit, paquetes de terceros que el encargo necesita.
• De quién es la licencia. Tu código sigue siendo tuyo. El open-source se queda en los términos que publicaron los autores. El cliente no compra esos derechos de autor al pagarte.
• Qué declaras. Una lista de componentes de terceros y la licencia que cada uno ya lleva. No inventes un nombre de licencia. Copia el nombre del paquete.
• Qué garantizas. Que no meterás material al que no tienes derecho. No que un paquete de origen vaya a seguir compatible para siempre.

La CDPA 1988 s.90 es la regla para tus derechos de autor. No mueve una licencia open-source de terceros. Guárdalas como materiales preexistentes o como licencias de terceros, no como finales cedidos.

Si compartes un repo no publicado antes de firmar el trato, un NDA mutuo se sienta al lado del papel del desarrollo.

Ejemplo

Los materiales preexistentes, bibliotecas y herramientas permanecen con el Desarrollador y se licencian al Cliente solo en la medida necesaria para usar los Entregables. Los componentes open-source de terceros permanecen en sus propias licencias. El Desarrollador declarará esos componentes y la licencia que cada uno ya lleva. El Desarrollador no cede esas licencias. El Desarrollador garantiza que, a su leal saber, los Entregables no incluyen material de terceros que el Desarrollador haya introducido sin derecho a ello.

En lenguaje sencillo: reciben una licencia para usar tu kit en este producto. No compran tu caja de herramientas. El open-source se queda en la licencia que ya tiene. Tú dices qué usaste.

Escribe un alcance del trabajo (SOW) o un backlog nombrado, cómo se ve «hecho», en qué entornos entregas y cómo se presupuesta un cambio. «Un producto» no es una lista. Las épicas extra son control de cambios, no una cortesía. Firma el SOW antes del primer commit.

Un alcance que funciona responde a cinco cosas:

• La lista. Épicas nombradas, historias o una fecha de congelación del backlog. Un checkout no es un marketplace. Una API no es una UI de administración.
• Aceptación. Pruebas escritas, una demo en staging, una ventana de defectos. Un defecto es no coincidir con el SOW. «Tenemos una idea nueva» es un cambio.
• Entornos. Quién hospeda dev, staging y producción. Quién tiene las cuentas cloud. Quién puede subir a producción.
• Qué queda fuera. Una segunda app, anuncios de pago, contenido, guardia continua — salvo que estén en la lista de lo incluido.
• Control de cambios. Una épica nueva se presupuesta y se firma primero. Consulta El cliente sigue pidiendo trabajo extra y control de cambios.

Un límite de revisioneslímite de revisionesUn límite de revisiones (revision limit) dice cuántas rondas de cambios están incluidas en los honorarios antes de presupuestar trabajo extra.Más en el glosario pule una pantalla acordada. No es un segundo producto a coste cero.

Si el contrato dice que las variaciones deben constar por escrito y estar firmadas, un sí en Slack no reescribe el encargo. Rock Advertising Ltd v MWB Business Exchange Centres Ltd [2018] UKSC 24 da efecto a esa cláusula.

Ejemplo

Los Entregables son los elementos del Anexo 1. El Desarrollador avisará de que un Entregable está listo en el entorno de staging. El Cliente lo probará en 10 días hábiles y o lo aceptará por escrito o listará defectos frente al Anexo 1. El silencio tras ese plazo cuenta como aceptación. Trabajo adicional, épicas extra o trabajo fuera del Anexo 1 se presupuesta y se acuerda por escrito antes de empezar. El Desarrollador entrega en staging. Subir a producción es el paso del Cliente salvo que el Anexo 1 diga otra cosa.

En lenguaje sencillo: reciben el backlog nombrado. Diez días hábiles para pinchar staging. Si no dicen nada, está aceptado. Una épica nueva es un honorario nuevo. Ellos pulsan el botón de producción salvo que también hayas presupuestado eso.

Los clientes recurrentes suelen sentarse bajo un contrato de servicios más un alcance del trabajo (SOW) por encargo. Un sitio de marketing puede partir de un contrato de desarrollo web.

La tarifa diaria paga tiempo. El precio fijo y los hitos pagan resultados nombrados. No hay un derecho británico por defecto a quedarte con un depósito ni a cobrar una tarifa de cancelación (kill feecompensación por cancelación (kill fee)Una compensación por cancelación (kill fee) es un pago debido a un creador o proveedor cuando un cliente cancela un proyecto antes de terminarlo.Más en el glosario): ambas partes tienen que acordar las sumas. Escribe un depósito antes de que empiece el trabajo. Para un cliente empresarial el cargo no debe ser una penalización.

Elige una forma de honorarios y escríbela:

Un depósito del 30–50% a la firma, con el trabajo en pausa hasta que llega, es la forma habitual de freelance. Una tarifa de cancelación se sienta al lado: trabajo hecho más una parte nombrada del resto de los honorarios si cancelan por conveniencia. Consulta cancelación y tarifa de cancelación y condiciones de pago.

Para un cliente empresarial, un cargo de cancelación acordado que en realidad es una suma por incumplimiento no debe ser una penalización. Cavendish Square Holding v Makdessi [2015] UKSC 67 pregunta si una obligación secundaria impone un perjuicio desproporcionado respecto de un interés legítimo en el cumplimiento. Ata la cifra al tiempo reservado, a los costes comprometidos y a otro trabajo rechazado. Un 100% plano desde el día que firman, sin vínculo con esos intereses, es la forma que parece un castigo.

El desglose más largo es Cliente cancelado: ¿puedes quedarte con el depósito?.

Ejemplo

El Cliente pagará el 40% de los Honorarios a la firma y el resto a la aceptación de los Entregables. El Desarrollador no empezará hasta recibir la primera suma. Si el Cliente cancela por conveniencia una vez empezado el trabajo, el Cliente pagará el trabajo hecho hasta la fecha y una tarifa de cancelación del 25% de los Honorarios restantes. Las sumas ya pagadas se abonan a ese total. La propiedad intelectual del trabajo no pagado por completo se queda con el Desarrollador.

En lenguaje sencillo: el 40% llega antes de que empieces. Si lo llaman off una vez que estás trabajando, pagan lo hecho más un cuarto de lo que queda. No son dueños del código impagado.

Esos porcentajes son ejemplos, no un tipo legal. En un encargo a tarifa diaria, escribe la tarifa, los días mínimos, y que los días cancelados ya reservados en la agenda siguen venciendo si rechazaste otro trabajo.

Escribe un vencimiento corto, un derecho a pausar si una factura está vencida, y que ninguna licencia ni cesión muerde hasta el pago íntegro. Para un cliente empresarial del Reino Unido, el interés legal sobre un pago comercial tardío es el 8% por encima del tipo base del Bank of England, más una suma fija de recobro. No imprimimos el tipo base actual.

Las condiciones de pago deben nombrar:

• cuándo salen las facturas — a la firma, en un punto medio, a la aceptación
• cuántos días para pagar — net 14 o net 30pago a 30 días (Net 30)Net 30 significa que el cliente tiene 30 días desde la fecha de la factura para pagar.Más en el glosario gana a un «cuando compras vuelva a pasar» sin fecha
• un derecho de pausa si una factura no discutida está vencida, incluido el derecho a no subir a producción
• que los derechos de autor, o cualquier licencia para usar la obra, pasan solo con el pago íntegro

Para una deuda cualificada entre empresas, la Late Payment of Commercial Debts (Interest) Act 1998 (Ley de Intereses por Pagos Comerciales Tardíos de 1998) fija el interés legal. GOV.UK sobre pagos comerciales tardíos indica el tipo como 8% más el tipo base del Bank of England. Una vez que corre ese interés, también vence una suma fija de recobro: £40 por debajo de £1.000, £70 de £1.000 a menos de £10.000, y £100 a partir de £10.000, más los costes razonables de recobro que no cubra esa suma. Consulta intereses de demora. La ley de 1998 no se aplica a un cliente consumidor.

Un tipo contractual, si nombra uno, es el tipo al que apuntas en lugar del tipo legal. No inventes una cifra sin vínculo con la ley o con el papel.

Ejemplo

Cada factura no discutida vence a los 14 días de su fecha. El Desarrollador puede pausar el trabajo, y no está obligado a entregar el acceso de producción, mientras cualquier factura no discutida lleve más de 7 días de retraso. Los derechos de autor y cualquier licencia para usar los Entregables pasan al Cliente solo con el pago íntegro. Hasta entonces el Cliente no tiene derecho a copiar, publicar, comunicar o adaptar los Entregables.

En lenguaje sencillo: tienen dos semanas para pagar. Tras una semana de retraso, el trabajo para y la producción se queda cerrada. No son dueños del código, y no pueden publicarlo, hasta que hayan pagado.

La secuencia de reclamación — requerimiento escrito, letter before action, reclamación de dinero — es Un cliente no paga una factura de freelance.

Ninguna etiqueta decide el impuesto. Desde el 6 de abril de 2021, las autoridades públicas y los clientes medianos o grandes deben emitir una declaración de determinación de estatus (Status Determination Statement). Los clientes pequeños del sector privado dejan esa decisión a tu sociedad. Escribe autonomía, sustitución genuina y mutualidad de modo que coincidan con cómo trabajas de verdad.

Las normas de off-payroll working están en la ITEPA 2003. Desde el 6 de abril de 2021, cuando se prestan servicios a través de un intermediario a una autoridad pública o a un cliente mediano o grande con nexo en el Reino Unido, el cliente debe emitir una declaración de determinación de estatus. Esa declaración debe decir si el trabajador habría sido empleado de haber sido contratado directamente, explicar los motivos y alcanzarse con diligencia razonable.

Cuando se prestan servicios a través de un intermediario a una persona que no es autoridad pública y que se califica como pequeña para el ejercicio fiscal, se aplica el capítulo 8. Una sociedad se califica como pequeña para un ejercicio fiscal si el régimen de pequeñas sociedades de la Companies Act 2006 (Ley de Sociedades de 2006) se aplica a su último ejercicio que sea relevante para ese año fiscal. Entonces decide el estatus la sociedad del trabajador.

Lo que el contrato sí puede hacer es describir la relación de trabajo con exactitud:

• Autonomía. Tú decides cómo entregar el resultado acordado. El cliente fija el resultado, los plazos y reglas de sitio razonables, no los métodos del día a día.
• Sustitución genuina. Puedes enviar un sustituto debidamente cualificado, pagado por ti. Un veto ilimitado del cliente hace que el derecho parezca irreal.
• Mutualidad. Cada alcance del trabajo es un encargo distinto. Ninguna parte está obligada a ofrecer o aceptar más trabajo cuando un encargo termina.

HMRC mira el contrato y las prácticas de trabajo juntos. Una cláusula de sustitución que el cliente nunca permitiría en la práctica no sostendrá el estatus. Pon la sustitución en la cláusula de cesión y subcontratación de un acuerdo de contratista independiente o un acuerdo de freelance, no en un correo al margen.

La lista más larga — capítulo 8 y capítulo 10, la declaración de determinación de estatus y un texto amistoso con «fuera de IR35» — es Cláusulas de contrato IR35 en el Reino Unido. Esta página no inventa texto más allá.

Ejemplo

El Desarrollador decide cómo entregar el resultado acordado. El Cliente puede fijar el resultado, los plazos y reglas de acceso razonables, no los métodos del día a día. El Desarrollador puede enviar un sustituto debidamente cualificado, pagado por el Desarrollador. Cada alcance del trabajo es un encargo distinto. Ninguna parte está obligada a ofrecer o aceptar más trabajo cuando un encargo termina.

En lenguaje sencillo: tú llevas el cómo. Ellos compran el qué. Puedes enviar a otra persona que sepa hacer el trabajo. Este SOW es este SOW — no una promesa del mes que viene.

Limita la responsabilidad a un múltiplo de los honorarios. En England and Wales no puedes excluir la responsabilidad por muerte o lesiones personales causadas por negligencia. Si accedes a datos personales en los sistemas del cliente, el tratamiento necesita un contrato de encargado vinculante. Consulta la guía más larga de responsabilidad.

Una limitación de responsabilidad que funciona nombra:

• el tope — a menudo los honorarios pagados bajo el SOW, o un múltiplo nombrado
• qué se queda ilimitado — la muerte o las lesiones personales causadas por negligencia no pueden excluirse ni restringirse (Unfair Contract Terms Act 1977 s.2, Ley de Cláusulas Contractuales Abusivas). Otra responsabilidad por negligencia solo puede limitarse en la medida en que el término sea razonable
• si una indemnidad se sienta dentro del tope o lo atraviesa

La página más larga es ¿Cómo debería un freelancer limitar la responsabilidad?.

Si tratas datos personales para el cliente — bases de producción, exportaciones de usuarios, acceso de soporte — el artículo 28(3) del UK GDPR exige un contrato que te vincule como encargado. Debe fijar el objeto y la duración del tratamiento, la naturaleza y la finalidad, el tipo de datos personales y las categorías de interesados, y las cláusulas de encargado del artículo 28(3)(a)–(h). Consulta protección de datos. No finjas que una línea «cumplirás la normativa de protección de datos» es ese contrato.

En un contrato de servicios entre empresas también hay un término implícito de que prestarás el servicio con cuidado y pericia razonables — Supply of Goods and Services Act 1982 s.13. Un tope se sienta al lado de ese término. No lo borra.

Ejemplo

La responsabilidad total del Desarrollador bajo este acuerdo se limita a los honorarios pagados bajo el alcance del trabajo pertinente. Nada en este acuerdo limita la responsabilidad por muerte o lesiones personales causadas por negligencia. Cuando el Desarrollador trate datos personales para el Cliente, ese tratamiento se rige por las cláusulas de encargado del Anexo 2.

En lenguaje sencillo: si sale mal, respondes hasta los honorarios de ese encargo. No puedes contratar fuera de matar a alguien por descuido. Si tocas los datos de sus usuarios, escribe el papel de encargado, no un vibe.

Nombra quién tiene acceso, a qué repos y cuentas cloud, con qué privilegio y cuándo termina el acceso. Usa cuentas nombradas, no una contraseña compartida. Al terminar, tú devuelves las credenciales y ellos revocan las tuyas. Escríbelo como práctica, no como una cláusula de estatuto penal.

Una cláusula de acceso que funciona responde a cinco cosas:

• Qué. Hosts Git, consolas cloud, CI, rastreadores de errores, analítica, DNS del dominio.
• Quién. Personas nombradas, en cuentas nombradas. Nada de una contraseña root compartida en un DM de Slack.
• Privilegio. El menor privilegio para el encargo. Acceso de escritura a producción solo si el SOW dice que tú subes.
• Secretos. Dónde viven las claves de despliegue y los tokens. Quién los rota.
• Fin. Devuelves o destruyes las credenciales. Ellos revocan tu acceso en la fecha de fin, o ante un incumplimiento material.

No retengas las claves de producción como rehén de una factura impagada. El derecho de pausa y la línea de PI ya hacen ese trabajo: ninguna cesión, y ningún deber de subir, mientras una factura no discutida esté vencida. Una pelea de bloqueo es cómo una deuda pequeña se convierte en una disputa mayor.

Si compartes un repo no publicado antes de firmar el trato, pon un NDA mutuo al lado de la lista de acceso.

Ejemplo

El Cliente concederá al Desarrollador acceso a los repositorios y cuentas cloud listados en el Anexo 1, en cuentas nombradas y con el privilegio allí fijado. El Desarrollador no compartirá esas credenciales. Al terminar, o a petición escrita del Cliente, el Desarrollador devolverá o destruirá las credenciales bajo su control, y el Cliente revocará el acceso del Desarrollador.

En lenguaje sencillo: te dejan entrar con un login nombrado. No pasas las llaves. Cuando termina, das las llaves y ellos cierran la puerta.

Solo si el contrato lo dice. Una cesión del código no te da, por sí sola, derecho a poner el producto en tu sitio. Escribe una licencia de vuelta: canales nombrados, si puedes nombrar al cliente, y si el trabajo confidencial se queda fuera del portafolio hasta que lancen.

Una cláusula de portafolio que funciona responde a cuatro cosas:

• Dónde. Tu web, redes, showreel impreso, charlas.
• Qué. El producto público, no ramas no publicadas ni la arquitectura rechazada.
• Cuándo. Tras el lanzamiento, o tras un embargo nombrado.
• Crédito. Si nombras al cliente, y si ellos te nombran. El crédito por el código es una promesa contractual.

Consulta publicidad y uso en portafolio. Si el encargo es confidencial — un producto no lanzado, un desarrollo aún en stealth — escribe que la licencia empieza en su lanzamiento público, o con consentimiento escrito. El silencio es cómo un caso de estudio se publica la semana antes de su anuncio.

Ejemplo

El Desarrollador podrá reproducir el producto público en el portafolio del Desarrollador y en el sitio web y canales sociales del Desarrollador, y podrá nombrar al Cliente como comitente, tras el lanzamiento, o antes con el consentimiento escrito del Cliente. Esta licencia no se extiende a ramas no publicadas, URL de staging ni información confidencial.

En lenguaje sencillo: una vez que es público, puedes mostrar el producto en vivo y nombrarlos. No puedes mostrar las rutas que mataron, ni filtrar el lanzamiento.

Si se niegan a cualquier uso en portafolio, eso es una cuestión de precio. Mételo en el papel antes de empezar.

El encargo termina cuando se aceptan los entregables nombrados, o cuando vence el preaviso. Entrega repos, credenciales y docs. El código impagado sigue siendo tuyo. Después, el soporte se sienta en una iguala, o con el cliente. No dejes «le echaremos un ojo» como una promesa abierta.

Una entrega que funciona responde a cinco cosas:

• Cuándo termina el desarrollo. Aceptación en staging, o una fecha de fin nombrada.
• Qué se mueve. Repos, admin cloud, CI, DNS, logins de terceros, runbooks.
• Qué se queda. Tus herramientas locales, spikes no usados, bibliotecas que no cediste.
• La garantía. Defectos frente al SOW durante un número nombrado de días. Es una ventana contractual, no un añadido legal a la CDPA.
• La iguala. Horas al mes, tiempos de respuesta, si las horas no usadas se arrastran, cómo termina. Consulta iguala.

Si te quieren de guardia tras el lanzamiento y no hay iguala, eso es un encargo nuevo. Cómo terminar un contrato de freelance es la página más larga de cierre.

Ejemplo

El encargo termina con la aceptación de los Entregables, o con el preaviso del Anexo 1. El Desarrollador entregará los repositorios, el acceso de administrador cloud, CI, registros DNS y logins de terceros listados en el Anexo 1. Los defectos frente al Anexo 1 comunicados en los 30 días siguientes a la aceptación se corrigen sin cargo. El alojamiento, la guardia y los cambios posteriores a esa ventana son una iguala aparte, o se presupuesta como trabajo extra. La propiedad intelectual del trabajo no pagado por completo se queda con el Desarrollador.

En lenguaje sencillo: entregas, das las llaves, arreglas bugs de verdad durante un mes. Después pagan el cuidado, o lo llevan ellos. El código impagado sigue siendo tuyo.

En Contracts.io ambas partes redactan, negocian y firman electrónicamente un único contrato de desarrollador compartido, así que el SOW, la línea de PI y la tarifa de cancelación son la versión que ambos firmasteis. Describe el trabajo en una frase. Lex, nuestro asistente de IA, redacta. Compartes un enlace. Nadie se manda v4_final.docx de ida y vuelta por correo.

El cliente abre ese enlace. Puede Aceptar, Contraofertar o Rechazar sobre esa misma versión, y después ambos firmáis electrónicamente. La otra parte nunca paga y no necesita una cuenta.

Parte de un acuerdo de freelance o de un acuerdo de contratista independiente. Un desarrollo de sitio puede partir de un contrato de desarrollo web. El trabajo recurrente puede colgar un alcance del trabajo (SOW) bajo un contrato de servicios. Tras el lanzamiento, una iguala cubre el cuidado. También puedes partir del generador de contratos con IA o del generador de contratos. Si compartes código no publicado antes de firmar el trato, el generador de NDA o un NDA mutuo se sienta al lado.

Eso no emite una determinación de estatus IR35 para el cliente. Sí significa que el alcance del trabajo, la cesión de propiedad intelectual o la licencia, el depósitodepósitoUn depósito (deposit) es dinero que se paga por adelantado, antes del trabajo principal o de la factura final.Más en el glosario, la tarifa de cancelación y el tope de responsabilidadlímite de responsabilidadUn límite de responsabilidad (liability cap) es el importe máximo que se puede pedir a una parte que pague a la otra en virtud de un contrato.Más en el glosario son las palabras que ambos firmasteis, no una línea perdida en un correo.

Free £0, después planes de pago desde £15 al mes — consulta /pricing.

Pruébalo en contracts.io: describe el desarrollo en una frase, comparte un enlace y firmad electrónicamente antes del primer commit.

Contratos para desarrolladores es el conjunto más amplio de términos alrededor de este papel. Contratos para diseñadores web es el hermano de sitio. Cláusulas de contrato IR35 en el Reino Unido es la página de estatus. ¿Debo empezar el trabajo antes de que se firme el contrato? es la regla del día uno.