---
title: "Mantenimiento y propiedad del código: lo que hay que cerrar por contrato"
description: "Qué incluye el mantenimiento de un software a medida, por qué el código debe ser del cliente y cómo evitar la dependencia del proveedor."
canonical: "https://aullando.com/blog/mantenimiento-y-propiedad-del-codigo"
last-updated: "2026-08-22"
---

# Mantenimiento y propiedad del código: lo que hay que cerrar por contrato

Dos cláusulas deciden si un desarrollo a medida es un activo o una atadura: de quién es el código y qué cubre el mantenimiento. Conviene cerrarlas antes de empezar, no al terminar.

## Propiedad del código

La posición sana es simple: el código y los datos son del cliente, con acceso al repositorio desde el primer día y con la capacidad de llevárselo a otro equipo sin permiso de nadie.

Esto no protege solo frente a un mal proveedor. Protege frente a lo normal: que un estudio cierre, que cambien las prioridades o que en tres años quieras un equipo interno.

Conviene revisar también dónde se aloja la aplicación, a nombre de quién están las cuentas de los servicios y quién controla el dominio. Tener el código sin las llaves de la infraestructura resuelve la mitad del problema.

## Qué cubre el mantenimiento

Es útil distinguir cuatro cosas, porque suelen mezclarse en una sola cifra:

1. **Correctivo**: arreglar lo que falla. Debería estar cubierto durante un periodo de garantía tras la entrega.
2. **Evolutivo**: cambios y funciones nuevas. Es trabajo nuevo y se presupuesta aparte.
3. **Adaptativo**: ajustes obligados por cambios externos, como una API que cambia o una versión que se queda sin soporte.
4. **Preventivo**: actualizaciones de seguridad y de dependencias.

Los puntos tres y cuatro son los que más se olvidan y los que más problemas causan a los dos años.

## Cómo evitar la dependencia técnica

Con decisiones aburridas: tecnologías conocidas y con comunidad, sin invenciones propias donde exista un estándar, documentación mínima pero suficiente y un entorno que cualquier equipo competente pueda levantar en una tarde.

La documentación no tiene que ser un manual. Tiene que responder tres preguntas: cómo se arranca, dónde están los datos y qué hay que saber para no romper nada.

## La pregunta de comprobación

Si mañana quisieras cambiar de proveedor, ¿cuántos días tardaría un equipo nuevo en ponerse a trabajar? Si la respuesta pasa de una semana, hay dependencia y conviene arreglarla ahora.

## Sigue por aquí

- [Cómo elegir empresa de desarrollo](/blog/como-elegir-empresa-desarrollo-software-a-medida)
- [Cuánto cuesta un software a medida](/blog/cuanto-cuesta-software-a-medida)
- [Desarrollos a medida](/a-medida)