Hay una situación que se repite más de lo que debería: una empresa paga por un sistema a medida, lo usa durante años y un día necesita cambiar algo. El proveedor ya no responde, subió sus precios o cerró. Y ahí descubre que no tiene el código, no sabe en qué servidor está funcionando el sistema y el dominio ni siquiera está a su nombre. El sistema sigue funcionando, pero nadie más puede tocarlo.
Evitarlo no depende de la suerte, sino de algo que se decide antes de firmar: quién será dueño de qué. En este artículo te explicamos qué significa realmente ser dueño de un software, qué modelos existen y qué deberías pedir por escrito.
Ser dueño de un software son varias cosas, no una
Cuando decimos "el sistema es mío" solemos pensar en una sola cosa, pero en la práctica son cinco:
- El código fuente: los archivos con los que se construyó el sistema. Sin ellos, nadie puede corregirlo ni mejorarlo.
- Los derechos sobre ese código: quién puede usarlo, modificarlo, venderlo o entregarlo a otro proveedor.
- Los datos: clientes, ventas, inventario, documentos. Es lo más valioso y lo más difícil de reconstruir.
- Los accesos e infraestructura: servidores, base de datos, dominio, repositorio y cuentas de servicios como pagos, correo o facturación electrónica.
- El conocimiento: documentación que explique cómo está construido, cómo se instala y cómo se opera.
Puedes tener el código y aun así quedar atado a un proveedor si los servidores y el dominio están a su nombre. Por eso conviene revisar las cinco.
Los modelos más comunes
No todos los proyectos tienen que funcionar igual. Lo importante es que el modelo esté claro desde el inicio.
| Modelo | Qué obtienes | Riesgo si no está claro | Cuándo tiene sentido |
|---|---|---|---|
| Cesión del código desarrollado | El código hecho para ti pasa a ser de tu empresa | Que no se entregue el código actualizado | Sistemas estratégicos, propios de tu operación |
| Licencia de uso | Derecho a usar el sistema; el proveedor conserva la propiedad | Quedar atado a sus precios y a su continuidad | Plataformas estándar o productos SaaS |
| Mixto | Tu desarrollo es tuyo, pero usa componentes del proveedor o de terceros | No saber qué partes podrías llevarte | La mayoría de proyectos modernos |
Ninguno es malo en sí mismo. Un producto SaaS, por ejemplo, funciona con licencia de uso y es razonable, porque pagas por un servicio que el proveedor mantiene para muchos clientes. El problema aparece cuando crees que tienes un modelo y en realidad tienes otro.
En Perú, como en la mayoría de países, el software está protegido por derechos de autor. En un desarrollo por encargo, la titularidad depende en buena medida de lo que se pacte, así que conviene dejarlo por escrito y, en proyectos grandes, revisarlo con un abogado.
Componentes de terceros: lo que nadie te explica
Casi ningún sistema se construye desde cero. Se apoya en frameworks y librerías como Laravel, React o miles de paquetes de código abierto, y a veces en herramientas propias que el proveedor reutiliza en varios proyectos.
Eso es bueno: acelera el desarrollo y usa piezas probadas. Solo necesitas saber dos cosas:
- El código abierto tiene licencias que permiten usarlo, pero con condiciones. Las más comunes, como MIT, son muy permisivas para uso comercial.
- Si el proveedor usa componentes propios, pregunta si te da una licencia para seguir usándolos aunque dejes de trabajar con él. Si no, cambiar de proveedor podría obligarte a reescribir esa parte.
Tus datos siempre deberían ser tuyos
Sea cual sea el modelo, los datos que genera tu operación deberían seguir siendo tuyos. Revisa que puedas:
- Exportarlos en un formato abierto, como CSV, Excel o un respaldo de la base de datos, sin depender del proveedor.
- Saber dónde están alojados y quién tiene acceso a ellos.
- Contar con respaldos periódicos y con un procedimiento para recuperarlos.
Si el sistema maneja datos personales de tus clientes o trabajadores, el proveedor normalmente actúa como encargado de tratarlos por cuenta de tu empresa. Conviene que el contrato lo refleje, incluida la confidencialidad y lo que ocurre con los datos al terminar la relación.
Los accesos que deberían estar a tu nombre
Esta es la parte más práctica y la que más se descuida:
- Repositorio de código: idealmente en una cuenta u organización de tu empresa, o con acceso tuyo desde el primer día.
- Servidores y nube: la cuenta de hosting o nube a nombre de tu empresa, aunque el proveedor la administre.
- Dominio: registrado a nombre de tu empresa, nunca solo a nombre de una persona del proveedor.
- Servicios externos: pasarela de pagos, facturación electrónica, correo transaccional o mapas, con cuentas a tu nombre.
- Credenciales administrativas: un acceso de administrador para tu empresa, guardado en un lugar seguro.
El proveedor puede tener permisos para operar todo esto, y es lo normal mientras trabajan juntos. Lo importante es que la titularidad sea tuya.
Qué pasa si cambias de proveedor
Aunque la relación vaya bien, conviene acordar desde el inicio cómo sería una transición. Una salida ordenada incluye:
- Entrega del código actualizado y de su historial en el repositorio.
- Documentación técnica mínima: arquitectura, instalación, configuración y dependencias.
- Transferencia de accesos y cambio de credenciales una vez completada.
- Entrega o migración de la base de datos.
- Un periodo razonable de acompañamiento para resolver dudas del nuevo equipo.
Señales de alerta: un proveedor que retiene el código como garantía, un sistema que "solo funciona en nuestro servidor", o la negativa a darte acceso al repositorio mientras pagas el proyecto.
Qué pedir por escrito antes de firmar
- Quién es titular del código desarrollado para ti y con qué alcance.
- Qué componentes del proveedor o de terceros usa el sistema y bajo qué licencia.
- Dónde estará el repositorio y desde cuándo tendrás acceso.
- A nombre de quién estarán la nube, el dominio y los servicios externos.
- Cómo puedes exportar tus datos en cualquier momento.
- Qué documentación recibirás.
- Cómo se hará la transferencia si decides cambiar de proveedor.
- Confidencialidad y tratamiento de datos personales.
Lo que es razonable que el proveedor conserve
Ser claro también implica reconocer lo que no es tuyo: el conocimiento y la experiencia del equipo, las herramientas genéricas que el proveedor usa en muchos proyectos (con la licencia que te corresponda) y, solo si lo autorizas, el derecho a mencionar el proyecto en su portafolio. Un acuerdo equilibrado protege a ambas partes.
Cómo lo hacemos en Wari
Nuestra propuesta establece desde el inicio la propiedad, los accesos, los repositorios, la infraestructura y la forma de transferencia. Nuestro principio es que tu organización conserve el control sobre sus datos y sobre los activos desarrollados para ella, y que trabajar con nosotros sea una decisión que puedas revisar, no una dependencia.
Si estás evaluando proveedores, esta es la pregunta 3 de nuestra guía de 10 preguntas antes de firmar. Y si quieres entender qué define el precio de un proyecto, revisa cuánto cuesta un software a medida.
¿Tienes un sistema y no sabes bien qué te pertenece? Cuéntanos tu caso o revisa nuestro servicio de software a medida: te respondemos en menos de 24 horas hábiles.
Este artículo es orientativo y no reemplaza la asesoría legal para tu caso concreto.