Qué debe llevar el contrato de un desarrollo a medida: propiedad del código, garantía y mantenimiento

Estás a punto de firmar un presupuesto para tu desarrollo a medida. El documento describe lo que se va a construir y cuánto cuesta, y hasta ahí lo entiendes. Lo que no sabes es si eso es todo lo que debería poner, ni qué falta que tú ni siquiera echarías de menos hasta que un día lo necesites: el código, un fallo que aparece tres meses después, o qué pasa el día que quieras cambiar de proveedor.

Es una situación incómoda, porque estás firmando algo caro que no sabes leer del todo, y las cláusulas que más te protegen no son las que hablan de la tecnología. Son las que hablan de qué pasa cuando el proyecto termina.

¿Qué cláusulas de verdad me protegen?

Antes de entrar una por una, esta es la foto de las que importan y de cómo se nota cuando una falta:

Las tres primeras son las que casi nunca vienen bien cerradas y las que más caro salen luego. Si al leer tu presupuesto ves que solo describe funcionalidades y precio, aquí es donde conviene parar y hablar del alcance real antes de firmar, porque el contrato es donde se decide qué pasa el día después de la entrega.

¿De quién es el código cuando el proyecto termina?

Esta es la que más sorprende: que pagues por un desarrollo no significa automáticamente que el código sea tuyo. Depende de lo que diga el contrato. Si no lo aclara, es perfectamente posible que el proveedor conserve la propiedad del software y que tú solo tengas permiso para usarlo. Suena a detalle legal menor, pero es lo que decide si mañana puedes llevarte el proyecto a otro sitio o te quedas atado.

Lo que quieres ver en el contrato son dos cosas juntas: la cesión de los derechos sobre el software a tu nombre cuando termines de pagar, y la entrega del código fuente de verdad, no solo la app funcionando. El código fuente es el "plano" del edificio; sin él tienes la casa pero no puedes reformarla sin llamar a quien la construyó. Entra aquí también quién se queda con los accesos: el repositorio donde vive el código, el dominio, la base de datos.

No hace falta que te conviertas en experto en propiedad intelectual para exigir esto. Basta con que la cláusula exista y diga con claridad que, pagado el trabajo, el código y sus accesos son tuyos. Si el tema te genera dudas de verdad —hay matices según cómo se redacte—, es exactamente el tipo de punto que conviene que revise un abogado antes de firmar. Lo que no puede pasar es que el contrato simplemente no lo mencione.

¿Qué cubre la garantía y cuánto dura?

Ninguna entrega de software sale perfecta. Aparecen fallos que no se vieron en las pruebas, casos raros que nadie previó. La garantía es la cláusula que dice quién paga por arreglar eso y durante cuánto tiempo.

No hay un plazo oficial ni una cifra que valga para todos; se pacta. Como orientación, es habitual ver periodos de entre 3 y 12 meses tras la entrega en los que el proveedor corrige sin coste los fallos que sean suyos. Lo importante no es solo el número de meses, sino que el contrato distinga bien dos cosas que es fácil confundir a propósito: un fallo es algo que se entregó y no funciona como se acordó, y eso entra en garantía; un cambio es algo nuevo que quieres añadir, y eso se paga aparte. Un contrato honesto separa las dos; uno que quiere cobrarte de más las mezcla, para que cualquier arreglo pueda presentarse como un evolutivo nuevo.

Fíjate en que la garantía no es lo mismo que mantener la app viva con el tiempo. Cubre corregir lo que ya estaba mal, no acompañarte durante los meses y años siguientes. Eso es la tercera cláusula, y es la que más gente confunde con la garantía.

¿Qué es el mantenimiento y por qué va aparte?

Una app a medida no es una compra que termina el día de la entrega. Hay que mantenerla: actualizaciones de seguridad, el hosting donde vive, adaptarla cuando cambia algo de lo que depende (una pasarela de pago, una normativa, el navegador de tus clientes), y los pequeños ajustes que siempre surgen con el uso real. Eso es el mantenimiento, y es un servicio continuo y de pago, distinto del precio de construir.

Lo que quieres del contrato aquí es que no te lo escondan hasta que ya dependes de ellos. Debería decir qué incluye (¿solo arreglos de seguridad? ¿también pequeños cambios? ¿en cuánto tiempo responden si algo se cae?) y qué cuesta. Como orientación muy amplia, el mantenimiento anual suele calcularse como un porcentaje del coste de construcción —a menudo se manejan cifras del orden del 15-20% al año—, pero es un rango para que no te pille de nuevas, no una tarifa: depende de cuánto haya que cuidar. La misma lógica de que el precio lo decide el alcance y no la tecnología la tienes, aplicada a construir, en la guía de cuánto cuesta una app a medida.

Lo esencial: que el mantenimiento sea una cláusula propia con su precio, no una nebulosa que se aclara "cuando llegue el momento". Cuando llega el momento, ya no tienes poder de negociación.

Un caso con números

Un negocio de 15 personas encarga una herramienta de gestión interna por 6.000 €. El presupuesto describe muy bien las pantallas y las funciones, y lo firman contentos. No dice nada del código ni del mantenimiento.

Un año después quieren añadir una integración y piden precio a otro proveedor, más barato. Descubren dos cosas: que el código nunca se les entregó —estaba en un repositorio del primer proveedor a nombre de este— y que sin él, el nuevo tiene que reconstruir buena parte para poder tocarlo, lo que dispara el presupuesto. Acaban quedándose donde estaban, no porque fuera lo mejor, sino porque cambiar salía carísimo.

El mismo proyecto con dos cláusulas más en el contrato —cesión del código a su nombre y entrega del código fuente— habría costado lo mismo de construir y les habría dejado libres de mover el proyecto cuando quisieran. Son cifras de ejemplo, no una tarifa, pero el patrón es real: lo que te ata casi nunca es la tecnología, es lo que el contrato dejó sin decir.

¿Cómo leo el contrato sin ser abogado?

No necesitas entender la parte técnica para juzgar un contrato de desarrollo a medida. Necesitas comprobar que responde a cuatro preguntas de sentido común: ¿de quién es el código cuando termine de pagar?, ¿quién arregla los fallos y hasta cuándo sin coste?, ¿qué cuesta mantener esto vivo?, ¿qué me llevo si un día nos separamos? Si el documento contesta a las cuatro con claridad, está bien encaminado. Si esquiva alguna o la deja en "ya lo veremos", ahí tienes tu conversación pendiente antes de firmar.

Y si el proveedor se incomoda cuando preguntas por estas cosas —sobre todo por de quién es el código—, esa reacción ya te dice bastante. Es la misma señal que verías en las preguntas que conviene hacer antes de contratar un desarrollo a medida: quien trabaja de forma limpia no tiene problema en poner por escrito qué pasa después, porque no vive de que te quedes atado.

Si tienes un presupuesto sobre la mesa y no sabes si el contrato te protege o solo describe lo que vas a comprar, escríbenos a contact@easybyte.es. Ante cualquier duda legal concreta, revísalo también con tu abogado o asesoría: el contrato es lo que te va a acompañar mucho después de que la app esté hecha.