Contrato de desarrollo de software: lo que un founder no técnico está comprando en realidad cuando firma
La primera vez que una founder con la que trabajamos nos mostró el contrato que su abogada le había redactado, el documento tenía treinta y ocho páginas. Abría con doce páginas de definiciones, recorría cláusulas de indemnización copiadas de un acuerdo de licenciamiento de SaaS de 2012 y terminaba con fuero arbitral en Delaware. No tenía ningún ingeniero en su equipo. Estaba comprando un build a medida de seis meses a un estudio de cuatro personas en São Paulo. Su abogada le había dicho que el documento era “estándar”. Cuando le preguntamos qué pasaría si el estudio fallaba en un milestone, tuvo que pasar tres secciones para encontrar la respuesta, y la respuesta estaba equivocada.
Ese contrato es el artefacto más común que vemos en deals de software a medida en etapa temprana. Parece responsable. No lo es. Un contrato de desarrollo de software para un founder no técnico que compra la primera versión de un producto a un estudio chico no es un documento de cuarenta páginas. Es un documento de cuatro a seis páginas que hace cinco cosas bien. El resto es teatro.
Esta es la guía, desde el lado del founder, sobre cuáles son esas cinco cosas, las tres trampas que se esconden dentro de los templates estándar, las cinco preguntas para hacer antes de firmar, y los tres casos estrechos en los que la versión de cuarenta páginas sí es el instrumento correcto.
Qué es realmente un contrato de desarrollo de software
Un contrato de desarrollo de software es un acuerdo escrito entre un cliente y un desarrollador o estudio de desarrollo que define qué se va a construir, cómo se va a pagar, quién es dueño y qué pasa cuando algo sale mal. No es un brief, no es un statement of work aislado, y no es un NDA, aunque normalmente hace referencia a los tres.
Para un founder no técnico que compra software a medida, el contrato es el documento que sobrevive a la conversación. Cada promesa hecha en Zoom, cada mensaje de Slack que dice “probablemente podemos agregar eso”, cada oferta de “después lo vemos” vive fuera del contrato. El contrato es lo que queda cuando alguien está insatisfecho. En eso tiene que ser bueno.
Los templates estándar disponibles online no fueron escritos para un founder en esta situación. Notar para quién fueron escritos es la primera jugada que te protege.
Por qué los templates estándar fallan con founders no técnicos
La mayoría de los templates viene de uno de dos mundos. El primero es la compra corporativa (PandaDoc, ktslaw, los filings de la SEC, las guías de estudios jurídicos). Estos asumen que el comprador es un departamento de IT de una Fortune 500 con asesoría legal interna y el vendedor es un proveedor con equipo comercial. Las cláusulas son largas porque los montos son grandes. La mayoría es inadecuada para un build de seis meses con un estudio chico. Hacen el documento hostil, alargan la negociación por semanas y señalan que no entendés el trabajo que estás por comprar.
El segundo es el lado freelance: boilerplate de Justia, contratos en markdown de GitHub, generadores de templates gratuitos. Son demasiado delgados. Asumen que el trabajo es un logo de un mes, dejan el IP ambiguo, no abordan aceptación y no tienen mecanismo para qué pasa si el build se extiende.
No existe un tercer mundo de templates escritos para el founder de una empresa en etapa temprana que compra un build a medida de seis meses a un estudio de cuatro a ocho personas. Entonces el founder paga cinco mil dólares a un abogado para adaptar el template corporativo, firma el delgado y reza, o firma la versión del estudio porque ellos lo sugirieron.
La solución no es un template mejor. La solución es saber qué cinco cláusulas sí funcionan en cualquier versión del documento e insistir en que esas cinco estén correctas.
Las cinco cláusulas que deciden si vas a poder dormir tranquilo
Este es el corazón del documento. El resto es acabado. Si estas cinco cláusulas están correctas, el contrato funciona. Si cualquiera de ellas está mal, ninguna otra cláusula te salva.
Referencia al alcance, no el alcance completo
Los contratos malos meten el alcance completo del proyecto dentro del cuerpo del contrato, congelado al momento de firmar. Es el error más caro del documento. En la semana tres de cualquier build a medida el alcance ya cambió: una sesión de discovery sacó algo a la luz, una entrevista con cliente movió las prioridades, una restricción técnica obligó a un workaround. Ahora tu contrato ya no coincide con lo que se está construyendo, y cada cambio exige una adenda.
Un contrato fit para founder trata al contrato y al alcance como dos documentos. El contrato nombra la referencia al alcance: “El Desarrollador entregará el trabajo descrito en el Alcance de Trabajo adjuntado como Exhibit A, que podrá ser revisado por acuerdo escrito de ambas partes sin enmendar este Contrato”. El alcance vive como documento separado, puede ser revisado por escrito a medida que el trabajo avanza, y está gobernado por el contrato encima de él. El alcance cambia; la gobernanza no.
Pago atado a la aceptación, no al calendario
La mayoría de los templates usa una de dos estructuras: precio cerrado pagado en cuotas mensuales iguales, o T&M facturado semanalmente sin cap. Ambas fallan de manera previsible. Precio cerrado con pagos por calendario premia al estudio por mandar facturas en fecha, no por entregar software que funciona. En el mes cuatro pagaste el 67% del proyecto por el 30% del producto funcionando. T&M sin cap elimina cualquier previsibilidad de costo, y vimos a founders cerrar un build a tres veces el presupuesto original porque ninguna cláusula obligó al estudio a parar y explicar por qué.
La estructura que recomendamos para casi todo build a medida en etapa temprana está en nuestro comparativo de precio cerrado vs tiempo y materiales para software a medida: T&M facturado semanalmente con cap por sprint y milestone gates que liberan el presupuesto del siguiente sprint. El contrato lo impone atando cada pago a un evento de aceptación, no a una fecha. Cap del Sprint Uno, liberado al aceptar el entregable del Sprint Uno por los criterios del Exhibit A. Cap del Sprint Dos, liberado al aceptar el Sprint Dos. Y así.
El evento de aceptación es la pieza que sostiene la estructura. El contrato debe definir qué es aceptación, quién tiene el derecho de aceptar (vos, no ellos) y cuántos días tenés para aceptar o rechazar. Si la aceptación no está definida, el pago no es exigible, y el estudio puede argumentar que el tiempo de calendario es el disparador.
Cesión de IP con grace previo al pago final
Casi todo template estándar cede la propiedad intelectual al cliente “al pago final”. Hasta que la última factura se acredite, el estudio es dueño del código que estuvo escribiendo para tu negocio. Si se abre un dispute en el mes cinco de un build de seis meses, el estudio es legalmente el titular del IP y puede negarse a entregar el repositorio hasta que el dispute se resuelva. Lo vimos pasar dos veces. En ambos casos la founder pagó todo para recuperar el código y después demandó por daños.
La solución es una cláusula de IP en dos partes. Primero, el IP se transfiere al cliente de forma incremental al pago de cada factura, no al pago final. Cualquier código que ya pagaste ya es tuyo. Segundo, el contrato otorga al cliente una licencia perpetua, irrevocable y gratuita para usar cualquier código entregado a la fecha, incluso durante un dispute. El estudio está protegido porque sigue cobrando el trabajo aceptado. Vos estás protegido porque ningún dispute puede dejarte afuera de código que ya existe.
Source code escrow no es un sustituto de esta cláusula. El escrow es un instrumento mediado por terceros, diseñado para software licenciado de enterprise donde el proveedor puede quebrar. Para un build a medida con un estudio chico, la defensa correcta es acceso al repositorio y cesión incremental de IP.
Acceso al repositorio en el día uno
Una cláusula que no aparece en la mayoría de los templates y debería: el estudio le otorga al cliente acceso de lectura al repositorio de código fuente el día uno del engagement. El repositorio puede vivir en el GitHub o GitLab del estudio por conveniencia, pero el cliente tiene acceso de lectura desde el inicio y la opción de hacer fork o migrar en cualquier momento, sin consentimiento ni cargo.
Esto no es desconfianza. Es asegurar que el día treinta y uno, noventa y uno o ciento ochenta y uno, el producto del trabajo es observable. Podés ver los commits. Si un desarrollador del estudio se va y el estudio dice que el build necesita tres semanas más “por la transición”, podés juzgar por tu cuenta. Si el estudio deja de entregar en silencio, tenés algo para pasarle al próximo equipo. El costo para el estudio es aproximadamente cero. El valor para el founder es aproximadamente el valor del codebase entero.
Una salida que no lleve 90 días
La última cláusula que sostiene el contrato es la de terminación. Casi todo template usa un aviso previo de 60 o 90 días para terminación sin causa. Es razonable para una relación enterprise con un master agreement de cinco años. Es hostil para un build de seis meses.
Una cláusula de terminación fit para founder hace tres cosas. Permite que cualquiera de las partes termine con 14 días de aviso escrito, sin causa, después de un cliff designado (en general después de la aceptación del Sprint Dos, para que ninguna de las partes se baje en el primer mes). Define la terminación con causa (falla en entregar un sprint aceptado, ruptura de confidencialidad, apropiación indebida de IP) con 7 días de derecho a cura. Y especifica qué pasa en la terminación: todo el IP ya cedido queda con el cliente, el estudio cobra el trabajo aceptado a la fecha de la terminación, sin kill fee, con obligación de handover de 5 días hábiles y un entregable definido.
La forma de esta cláusula corre el poder del supuesto de que la relación va a seguir a la realidad de que cualquier build a medida puede terminar antes por buenos motivos.
Tres trampas en los templates estándar
Las cinco cláusulas también te permiten detectar las tres formas más comunes en que los templates estándar fallan en silencio.
La primera trampa es T&M sin cap. Los templates de T&M estándar contienen frases como “El Desarrollador facturará a las tarifas horarias acordadas por el tiempo dedicado al Proyecto”. Sin restricción de costo total. Cada cláusula de T&M debe estar emparejada con un cap por sprint o por fase que el estudio no puede exceder sin tu aprobación escrita. Si se alcanza el cap y el sprint no se entregó, eso es una conversación, no una factura por default.
La segunda trampa es entrega definida por fecha en vez de por aceptación. Los templates del mundo enterprise dicen cosas como “El Software será entregado en o antes del 31 de diciembre”. Eso se satisface en el momento en que el estudio publica un release tagueado en el repositorio, sin importar si funciona. Reemplazá cada entrega basada en fecha por “El Software se considerará entregado cuando sea aceptado por el Cliente conforme a los criterios del Exhibit A”. El calendario es un objetivo. La aceptación es el disparador.
La tercera trampa es IP que se transfiere “al pago final” sin grace. La mayoría de los founders pasa por encima de la cláusula de IP y asume que “recibimos el código cuando lo pagamos” alcanza. “Al pago final” está haciendo el mismo trabajo que un rehén. Cualquier versión de la cláusula de IP que no transfiera los derechos de forma incremental, factura paga por factura paga, está creando uno. Leé la cláusula con atención o pedile a alguien que la lea por vos.
Cinco preguntas para hacerle al contrato antes de firmar
Una vez que tenés el documento adelante, la forma más rápida de evaluarlo es hacerle estas cinco preguntas en voz alta.
Primera: si firmo esto y el estudio falla la aceptación del Sprint Dos, qué pasa específicamente. El contrato debería responder en una o dos frases. Si requiere pasar tres secciones, es demasiado largo y demasiado vago.
Segunda: si se abre un dispute en el mes cuatro de un build de seis meses, quién es dueño del código escrito hasta entonces. La respuesta debería ser “el cliente es dueño de todo lo que se pagó”. Si es “el estudio, hasta el pago final”, la cláusula de IP está mal.
Tercera: puedo ver el repositorio hoy. Si la respuesta es “después de que armemos el scaffolding inicial el mes que viene”, la cláusula de acceso al repositorio está mal.
Cuarta: si quiero salir después del Sprint Tres, qué me cuesta, cuánto tiempo lleva, con qué me voy. La respuesta debería ser 14 días, sin kill fee, todo el trabajo aceptado, handover de 5 días. Si es 60 a 90 días más una tarifa de terminación, la cláusula de salida está mal.
Quinta: qué documento prevalece si el Exhibit A y el contrato entran en conflicto. La respuesta debería ser que el Exhibit A es la fuente operacional de la verdad y el contrato es la gobernanza por encima de él. Si el contrato anula al Exhibit A, la cláusula de referencia al alcance está mal.
Un contrato que da respuestas limpias y rápidas a estas cinco preguntas va a funcionar. Un contrato que no las da necesita edición antes de firmar, sin importar cuántas páginas de definiciones haya al frente.
Cuándo la versión de 40 páginas sí es el instrumento correcto
Hay tres situaciones en las que un contrato más grueso y más formal es el instrumento correcto.
La primera es cuando el comprador es una entidad regulada (un banco, una aseguradora, un proveedor de salud, un comprador del sector público) y el contrato tiene que incluir términos de compliance no opcionales: lenguaje de HIPAA, referencias a SOC 2, adendas de protección de datos GDPR, boilerplate de compras públicas. El contrato hace dos trabajos, gobernar el build y cumplir obligaciones regulatorias. El segundo trabajo es lo que lo hace largo.
La segunda es cuando el engagement es un master agreement de varios años bajo el cual se van a emitir muchos statements of work. Acá el contrato gobierna una relación, no un proyecto. La mayoría de los founders no técnicos firmando su primer contrato de software a medida no está en esa categoría. Está comprando un proyecto.
La tercera es cuando el build mismo involucra IP licenciado significativo del desarrollador (una plataforma existente, un modelo existente, un framework propietario) que el contrato tiene que licenciar al cliente en términos específicos. Ese híbrido sí necesita la estructura extra. Los builds a medida desde cero normalmente no.
Si tu situación no es ninguna de esas tres, el documento de cuarenta páginas no te está haciendo ningún favor. La versión fit para founder de cuatro a seis páginas, con las cinco cláusulas correctas, te protege mejor que la de treinta y ocho cuyos términos tu abogado tampoco entiende del todo.
Contrato de desarrollo de software: FAQ
¿Qué es un contrato de desarrollo de software? Un contrato de desarrollo de software es un acuerdo escrito entre cliente y desarrollador o estudio de desarrollo que define qué se va a construir, cómo se va a pagar, quién es dueño del IP resultante y qué pasa cuando algo no sale como estaba planeado. Para un founder no técnico, es el documento que sobrevive a la conversación cuando la conversación se pone difícil.
¿Cuáles son las cuatro formas de contrato de desarrollo de software que te van a ofrecer? Los templates estándar vienen aproximadamente en cuatro formas. Acuerdos de proyecto a precio cerrado (un precio, una fecha de entrega, un documento). Acuerdos de T&M (tarifa horaria, facturas semanales, en general sin cap). Master service agreements con statements of work adjuntos (relaciones de plazo más largo, varios proyectos bajo un mismo paraguas). Y acuerdos de equipo dedicado (vos pagás por la capacidad de un equipo, no por un entregable). La mayoría de los builds a medida en etapa temprana funciona mejor como un híbrido del segundo con una estructura de cap por milestone. Mirá nuestro comparativo de precio cerrado vs T&M para saber qué forma encaja en tu situación.
Contrato de desarrollo de software vs SOW vs MSA: cuál es la diferencia. El MSA (master service agreement) gobierna cómo se va a manejar todo el trabajo entre dos partes a lo largo de múltiples proyectos. El SOW (statement of work) es el documento específico de proyecto adjuntado o referenciado por el MSA, que define qué se está construyendo, con qué timeline, con qué presupuesto. “Contrato de desarrollo de software” es el término paraguas y, según el contexto, se refiere al MSA, al SOW o a un documento combinado de proyecto único que hace los dos. Para un build temprano único, la versión combinada suele ser la forma correcta, pero debería mantener separados, dentro de su propia estructura, el alcance (equivalente al SOW) y la gobernanza (equivalente al MSA).
¿También necesito un NDA? Generalmente sí, pero no como documento separado. Una cláusula mutua de confidencialidad dentro del contrato alcanza para casi todo build en etapa temprana. Un NDA aislado es el instrumento correcto cuando estás intercambiando información sensible antes de haber acordado trabajar juntos: una conversación de venta, una evaluación, una semana de discovery. Una vez firmado el contrato de desarrollo, la cláusula de confidencialidad dentro hace el mismo trabajo.
¿Puedo redactar este contrato yo mismo? Podés redactar la estructura, las prioridades, las cláusulas que querés incluir, y el lenguaje de las cinco cláusulas que sostienen el documento. No deberías firmar el documento final sin que un abogado lo revise. Un contrato fit para founder de cuatro a seis páginas lleva a un abogado una o dos horas de revisión, no una semana. Un documento más corto también es un documento más barato de revisar. Es un motivo más por el cual la versión fit para founder se paga sola.
Antes de empezar a redactar, asegurate de haber hecho el trabajo descrito en el artículo sobre RFP sobre escribir un partner brief, la evaluación de estudio de la guía de software house, y la decisión de estructura de pago en el comparativo de precio cerrado vs T&M. El contrato es el artefacto que captura decisiones que ya tomaste. No es el lugar donde se toman.