Exemplo de SOW desenvolvedor web: misión en forfait completa

Por que redactar un SOW sólido para unha misión de desenvolvemento web en forfait?

Cando unha empresa confia a un desenvolvedor web independente ou a unha axencia unha misión en modo forfait, a tentación é grande de apoiarse nun simple orzamento ou en intercambios de correos electrónicos. Con todo, esta é unha das principais fontes de litigios na relación cliente-prestatario tech: alcance do proxecto mal definido, entregas contestadas, dereitos sobre o código fonte non precisados. O Statement of Work (SOW) é o documento contractual que permite prevenir todos estes riscos ao formalizar, artículo por artículo, o que cada un debe facer, cando, e segundo que criterios de éxito.

Nunha misión en forfait — en oposición á rixe — o prestatario se compromete cun resultado preciso por un prezo fixo. Esta mesma natureza do contrato fai que a redacción do SOW sexa aínda máis crítica: toda zona gris se transforma nun desacordo sobre o que estaba « incluído » ou non no perímetro. En 2024, segundo o informe anual do Consello Nacional de Colexios de Avogados, os litigios comerciais vinculados aos contratos de prestación informática representaban máis do 18 % dos contenciosos B2B ante os tribunais de comercio franceses.

Nesta guía, detallamos a estrutura dun exemplo de SOW desenvolvedor web completo para unha misión en forfait, cubrindo os entregables, os criterios de aceptación, a propiedade intelectual e a cesión de código fonte. Para ir máis aló sobre os fundamentos, consulta o noso guía completo do SOW: modelo, cláusulas e sinatura electrónica.

---

A estrutura tipo dun SOW para desenvolvedor web en misión en forfait

Un SOW ben estruturado segue unha arquitectura lóxica que progresa do xeral ao específico. Aquí están as seccións indispensables para unha misión de desenvolvemento web.

1. Encabezamento e identificación das partes

O documento comeza coa identificación precisa das dúas partes: o doador de orde (empresa cliente, mencionando a forma xurídica, o número SIREN, o representante legal e o seu título) e o prestatario (desenvolvedor independente ou sociedade). Tamén se precisan:

• O número do SOW (especialmente se se inscribe nun marco de MSA — Master Services Agreement)
• A data de entrada en vigor
• A duración previsible da misión
• O referente de proxecto do lado do cliente e do lado do prestatario

Esta sección semella anodina pero é determinante en caso de litigio: fixa os interlocutores habilitados para validar os entregables e asinar os avenidos.

2. Perímetro e descrición dos entregables

Este é o corazón do documento. Para unha misión de desenvolvemento web en forfait, o perímetro debe describirse cunha precisión case técnica.

Exemplo de redacción para unha aplicación web de comercio electrónico:

> O Prestatario se compromete a diseñar, desenvolver e entregar unha aplicación web de comercio electrónico adaptable baseada en Next.js 14 (framework React), conectada a unha API REST de back-end Node.js/Express, con integración Stripe para o pagamento en liña. A aplicación incluirá os seguintes módulos: catálogo de produtos (ata 5 000 referencias), carrito de compra, túnel de conversión en 3 etapas, espazo de cliente seguro (JWT), taboleiro administrativo.

Cada entregable debe listarse individualmente con:

• O seu título (ex.: « Módulo de autenticación de usuario »)
• A súa descrición funcional (o que fai, non como se fai)
• A data de entrega prevista (ou o xalonamento por sprint/fase)
• O formato de entrega (depósito Git, URL de staging, ficheiro ZIP, documentación técnica)

Para proxectos complexos, é aconsellable anexar un caderno de cargas funcional (CDC) ou historias de usuario Agile, aos que o SOW fai referencia explícitamente.

3. Criterios de aceptación: como validar cada entregable?

Esta é a sección máis a miúdo neglixida e máis litigiosa. Os criterios de aceptación definen obxectivamente as condicións nas que o cliente recoñece que un entregable é conforme.

Exemplo de criterios de aceptación para unha aplicación web:

| Entregable | Criterio de aceptación | |---|---| | Módulo de autenticación | Conexión/desconexión funcional en Chrome, Firefox, Safari (versións N-1). Tempo de resposta < 800 ms. Probas unitarias cubrindo ≥ 80 % do código. | | Túnel de conversión | Taxa de erro JavaScript = 0 en condicións de carga simulada (200 usuarios simultáneos mediante Lighthouse). | | Taboleiro administrativo | Exportación CSV funcional. Visualización correcta en resolución 1280 × 720 px mínimo. | | Documentación técnica | Ficheiro README.md completo, esquema de arquitectura fornecido, variables de ambiente documentadas. |

O SOW tamén debe precisar:

• O procedemento de proba: quen proba, con que ferramentas, en que prazo despois da entrega (exemplo: o cliente dispón de 10 días laborais para validar ou formular reservas motivadas por escrito)
• A xestión de reservas: as reservas menores (bugs cosmétricos) non bloquean o pagamento; as reservas maiores (funcionalidade non funcional) suspenden o pagamento ata a corrección
• O silencio valida a aceptación: pasado o prazo de proba sen retorno escrito, o entregable é reputado aceptado

Este mecanismo de aceptación formal é crucial en forfait. Para automatizar a sinatura dos actas de proba, moitas DSI usan agora a sinatura electrónica en empresa, que confiere un valor probatorio equivalente á sinatura manuscrita segundo o regulamento eIDAS.

4. Condicións financeiras e xalóns de pagamento

En misión en forfait, a estrutura de pagamento está xeneralmente vinculada ao avance do proxecto máis que ao tempo gastado.

Exemplo de planificación de pagamento para un proxecto de 24 000 € sen IVA:

• 30 % á sinatura do SOW: 7 200 € sen IVA (adianto, cubre a fase de deseño/arquitectura)
• 30 % á entrega do sprint 1 (entregables 1 a 4 validados): 7 200 € sen IVA
• 25 % á entrega do sprint 2 (entregables 5 a 8 validados): 6 000 € sen IVA
• 15 % á proba final e posta en produción: 3 600 € sen IVA

O SOW precisa as penalizacións por retraso do lado do prestatario (ex.: 0,5 % do importe total por semana de retraso, limitadas ao 10 %) e as penalizacións por retraso do lado do cliente para os retornos de validación (ex.: extensión do prazo global dunha duración equivalente ao retraso de validación).

5. Propiedade intelectual e cesión do código fonte

Esta é a sección xurídicamente máis sensible para todo contrato de desenvolvemento web. Por defecto, en dereito francés (Código de Propiedade Intelectual, art. L. 111-1), o autor dunha obra do entendemento — incluído un software — conserva os dereitos aínda despois da entrega e pagamento. En outras palabras, sen cláusula de cesión explícita, o cliente paga o desenvolvemento pero non é propietario legalmente do código.

Un SOW ben redactado debe incluir unha cláusula de cesión completa. Aquí está un exemplo de redacción:

> En contrapartida do pagamento completo do prezo acordado, o Prestatario cede ao Cliente, a título exclusivo e definitivo, o conxunto dos dereitos patrimoniais sobre os Entregables orixinais desenvolvidos especificamente no marco deste SOW, incluíndo os dereitos de reprodución, de representación, de adaptación, de tradución, de modificación e de explotación comercial, para o mundo enteiro e durante toda a duración legal de protección dos dereitos de autor.

O SOW tamén debe distinguir:

• O código propietario (desenvolvido especificamente para este proxecto → cedido ao cliente)
• Os compoñentes de terceiros (frameworks, bibliotecas de código aberto → o prestatario garantiza a súa conformidade coas licenzas aplicables)
• As ferramentas e métodos do prestatario (coñecemento especializado, boilerplates → seguen sendo propiedade do prestatario)
• As dependencias de código aberto: listar os compoñentes e as súas licenzas (MIT, Apache 2.0, LGPL…) para evitar calquera violación de licenza

Para as misións que impliquen desenvolvementos innovadores susceptibles de ser patentados ou protexidos como software, consulta o noso hub INPI: sinatura, depósito e certificación para asegurar os dereitos desde a fase de desenvolvemento.

Finalmente, o SOW debe incluir unha cláusula de escrow do código fonte se o cliente desexxa protexerse contra unha deficiencia do prestatario: o código é depositado nun terceiro de confianza e liberado baixo condicións predefinidas (liquidación xudicial do prestatario, deficiencia nos SLA, etc.).

---

Cláusulas complementarias indispensables nun SOW de desenvolvemento web

Confidencialidade e NDA integrado

O prestatario terá acceso a información sensible: arquitectura técnica, datos de clientes, roadmap do produto. O SOW debe incluir unha cláusula de confidencialidade (ou facer referencia a un NDA asinado por separado) cubrindo:

• A duración da obriga (xeralmente 3 a 5 anos despois do fin da misión)
• A definición das informacións confidenciais
• As excepcións (informacións xa públicas, obtidas lexitimamente dun terceiro)
• As obrigas de devolución ou destrución dos datos ao final do contrato

Garantías e mantemento pós-entrega

En forfait, a garantía de defectos ocultos aplícase legalmente, pero o SOW precisa a súa alcance operacional:

• Garantía de bo funcionamento: durante X meses despois da proba final, o prestatario corrixe gratuitamente calquera bug relacionado co seu desenvolvemento (agás evolucións funcionais)
• SLA de corrección: bug bloqueante corrixido en 24 h laborais; bug maior en 72 h; bug menor integrado no próximo ciclo
• Exclusións de garantía: modificacións realizadas polo cliente no código, actualizacións de dependencias non validadas polo prestatario

Subcontratación e recursos humanos

O cliente debe saber se o prestatario pode subcontratar todo ou parte dos desenvolvementos. Se se desexxa unha cláusula de aprobación previa (nomeadamente por razóns de confidencialidade ou conformidade RGPD), debe figurar no SOW. Nas misións críticas, algúns clientes incluso esixen nomear aos desenvolvedores implicados e obter un acordo previo en caso de cambio de equipo.

Para os SOW asinados con prestatarios estranxeiros ou nun contexto multiparte, a solución de sinatura electrónica conforme eIDAS de Certyneo permite asinar a distancia cunha validade probatoria recoñecida nos 27 Estados membros da UE.

---

Boas prácticas para finalizar e asinar o teu SOW

Proceso de revisión e enmienda

Antes da sinatura, o SOW debe ser revisado por:

1. O xefe de proxecto técnico do lado do cliente (validación do perímetro funcional)
2. O xurista ou DAF (validación das cláusulas financeiras, IP e penalizacións)
3. O RSSI se se tratan datos persoais ou sensibles (conformidade RGPD)

Toda enmienda ao perímetro en curso do proxecto debe ser obxecto dun Change Order (avenido) asinado polas dúas partes, precisando o impacto no prazo e no prezo. Sen avenido asinado, toda solicitude de modificación é reputada fóra do perímetro.

Sinatura electrónica do SOW

A sinatura manuscrita dun SOW implica idas e voltas de papel cronófagas e fonte de erros (versión non actualizada asinada, sinatura faltante). A sinatura electrónica avanzada ou cualificada, conforme ao regulamento eIDAS, presenta varios beneficios decisivos para este tipo de documento:

• Validade probatoria reforzada: horodataxe cualificada, identificación certa dos sinatarios
• Rapidez: un SOW pode ser asinado en poucos minutos, mesmo cun prestatario en teletraballo ou no estranxeiro
• Arquivo automático: o documento asinado se conserva de xeito infalible
• Seguimento das versións: evita asinar unha versión antiga

O noso comparativo das solucións de sinatura electrónica axudache a escoller o nivel de sinatura adaptado á valor e á sensibilidade dos teus SOW. Para as misións superiores a 50 000 € ou que impliquen cláusulas de cesión IP extendidas, a sinatura cualificada (nivel máis alto de eIDAS) é recomendada.

Para acelerar a produción do documento propio, o noso xerador de contratos por IA permite producir un borrador de SOW personalizado en poucos minutos, a partir dos parámetros da túa misión.

Marco legal aplicable aos SOW de desenvolvemento web

Código Civil e forza obrigatoria do contrato

O SOW é ante todo un contrato no sentido do artigo 1101 do Código Civil francés: « O contrato é un acordo de vontades entre dúas ou máis persoas destinado a crear, modificar, transmitir ou extinguir obrigas. » A súa forza obrigatoria está establecida no artigo 1103: « Os contratos legalmente formados fanse lei para aqueles que os fixeron. » Desde que é asinado polas dúas partes, o SOW é xurídicamente vinculante, incluíndo as súas anexos técnicos e as súas táboas de entregables.

A sinatura electrónica do SOW rexítrase polos artigos 1366 e 1367 do Código Civil, que recoñecen á escritura electrónica a mesma forza probatoria que a escritura de papel, baixo condición de que a identidade do sinatario sexa debidamente identificada e que a integridade do documento sexa garantida.

Regulamento eIDAS nº 910/2014 e norma ETSI

Para os SOW asinados electronicamente entre empresas europeas, o regulamento eIDAS (nº 910/2014 do Parlamento Europeo e do Consello) define tres niveis de sinatura electrónica: simple, avanzada e cualificada. A sinatura electrónica avanzada (SEA) repousa nas normas ETSI EN 319 132 (XAdES) e ETSI EN 319 122 (CAdES), que garantizan a integridade do documento e a identificación do sinatario. Para compromisos contractuais con gran impacto financeiro ou que conteñan cláusulas de cesión de dereitos de autor, a sinatura cualificada (SEQ), baseada nun certificado outorgado por un provedor de servizos de confianza cualificado (PSTQ) inscrito na lista de confianza europea (TSL), é recomendada.

Código de Propiedade Intelectual (CPI)

A cesión de dereitos sobre o código fonte rexítrase polo Código de Propiedade Intelectual. O artigo L. 111-1 CPI consagra o dereito moral e os dereitos patrimoniais do autor sobre calquera obra do entendemento, incluíndo os softwares (art. L. 112-2, 13º). A cesión de dereitos patrimoniais debe, segundo o artigo L. 131-3 CPI, mencionar explicitamente cada dereito cedido, o territorio, a duración e o modo de explotación. Calquera SOW que omita algunha destas mencións arrisca ver a cláusula de cesión invalidada por un tribunal, deixando os dereitos ao prestatario.

Ademais, os softwares creados por un traballador no exercicio das súas funcións pertencen ao empregador (art. L. 113-9 CPI). Esta regra non se aplica aos prestatarios independentes, dende onde a imperiosa necesidade dunha cláusula de cesión contractual.

RGPD (Regulamento nº 2016/679) e tratamento de datos

Se o prestatario trata datos persoais en nome do cliente (ex.: acceso a unha base de datos de clientes para desenvolver un CRM), é cualificado como subcontratista no sentido do artigo 28 do RGPD. O SOW debe entón integrar ou facer referencia a un acordo de tratamento de datos (DPA) precisando: a natureza e finalidade do tratamento, as categorías de datos afectados, as medidas de seguridade técnicas e organizacionais, e as obrigas do prestatario en caso de violación de datos. A falta diso, o cliente e o prestatario exponse ás sancións da CNIL, que pode chegar ao 4 % do volume de negocios anual mundial.

Dereito comercial e responsabilidade contractual

En caso de incumprimento dos entregables ou dos prazos, a responsabilidade contractual do prestatario está comprometida sobre a base dos artigos 1231-1 e seguintes do Código Civil (antigos artigos 1147 e s.). As cláusulas limitativas de responsabilidade (tope a X meses de facturación) son válidas entre profesionais, baixo a condición de non baleirar o contrato da súa substancia (art. 1170 do Código Civil).

Escenarios de uso: o SOW desenvolvedor web na práctica

Escenario 1 — Unha scale-up SaaS encarga un módulo de facturación á medida

Unha scale-up B2B editora dun software de xestión RH, contando aproximadamente 40 colaboradores e 500 clientes activos, desexxa externalizar o desenvolvemento dun módulo de facturación automática integrado no seu produto principal. O orzamento en forfait é de 35 000 € sen IVA para 4 meses de desenvolvemento.

Sen un SOW formalizado, as primeiras semanas revelen divergencias maiores: o prestatario considera que a integración coa API Stripe está fóra do perímetro, mentres que o cliente a estima implicitamente incluída. Un litigio sobre 8 000 € de exceso de orzamento estalina no sprint 2.

Con un SOW estruturado incluíndo unha táboa de entregables, uns criterios de aceptación precisos e unha lista das integracións de terceiros explicitamente incluídas, este tipo de conflito evítase. A cláusula de Change Order obriga a asinar un avenido para todo engadido de perímetro. Resultado constatable en contextos similares: redución dos litigios en curso do proxecto do 70 ao 85 % e ganancia de 2 a 3 semanas no prazo de posta en produción, segundo datos publicados pola SYNTEC Numérique no seu barómetro 2023.

Escenario 2 — Un grupo industrial asegura a cesión de dereitos nun ERP á medida

Un grupo industrial de tamaño intermedio (aproximadamente 800 empregados, 3 sedes de produción) encarga a unha axencia de desenvolvemento web un ERP de xestión de produción á medida por 180 000 € sen IVA. A misión dura 18 meses. Ao final do proxecto, a axencia é comprada por un competidor. O grupo realiza entón que a cláusula de propiedade intelectual do seu contrato inicial non cubría a cesión dos dereitos sobre os módulos desenvolvidos en subcontratación por dous freelances que interviñeron no proxecto.

Un SOW ben redactado tería previsto: unha cláusula de cesión cubrindo todos os entregables incluíndo aqueles producidos pola subcontratación por parte do prestatario, unha obriga do prestatario principal de obter cesións equivalentes dos seus propios subcontratistas, e un mecanismo de escrow do código fonte activable en caso de cambio de control. En situacións similares documentadas por despachos de avogados especializados en dereito da tecnoloxía, os custos de litigio e de re-desenvolvemento parcial superan regularmente o 30 % do orzamento inicial do proxecto.

Escenario 3 — Unha axencia dixital estandariza os seus SOW para acelerar as súas vendas

Unha axencia web de 15 persoas realiza en media 25 proxectos en forfait ao ano, por orzamentos que van de 8 000 a 60 000 € sen IVA. A dirección constata que a negociación e a sinatura dos SOW movilizan en media 4 horas por proxecto do lado do comercial e xurídico, é dicir aproximadamente 100 horas anuais perdidas.

Ao adoptar un modelo de SOW estandarizado, completado por un xerador de cláusulas adaptado a cada tipo de misión (sitio exposición, aplicación web, comercio electrónico, API), e ao desplegar a sinatura electrónica para finalizar os documentos a distancia, a axencia reduce este prazo a 45 minutos por SOW. En 25 proxectos anuais, son aproximadamente 55 horas recuperadas, é dicir unha ganancia equivalente a máis dunha semana-home. A sinatura electrónica reduce tamén o prazo entre envío e sinatura efectiva de 8 días en media a menos de 24 horas, acelerando o comenzo dos proxectos e mellorando a tesorería.

Conclusión

Redactar un SOW desenvolvedor web completo para unha misión en forfait non é unha formalidade administrativa: é o documento fundacional da relación contractual, aquel que prevén os litigios sobre os entregables, garante a cesión efectiva do código fonte e protexe as dúas partes en caso de desacordo. Ao estruturar o teu SOW arredor de cinco pilares — identificación das partes, perímetro dos entregables, criterios de aceptación obxectivos, condicións financeiras xalonadas e cláusulas de propiedade intelectual detalladas — lle das ao teu proxecto as mellores oportunidades de desenrolar tranquilamente.

Certyneo te acompaña en cada etapa: desde a xeneración do borrador mediante o noso xerador de contratos por IA ata a sinatura electrónica conforme eIDAS na nosa plataforma, pasando polo arquivo seguro dos teus documentos asinados. Descubre as nosas fórmulas en a páxina de prezos de Certyneo e comeza a asegurar as túas misións dende hoxe.