Empecemos por el dato que hace que valga la pena leer el resto.

En Ecuador, el artículo 115 del Código Orgánico de la Economía Social de los Conocimientos —el «Código Ingenios»— establece que, salvo pacto en contrario, la titularidad de las obras creadas bajo relación laboral o por encargo corresponde al autor.

Léelo otra vez pensando en tu sistema. Si contrataste a alguien para que te construyera un ERP y el contrato no dice explícitamente que los derechos se te ceden, el titular del código es quien lo escribió. No tú, que lo pagaste.

Es el reverso de lo que casi todo el mundo asume, porque es el reverso de lo que decía la ley anterior de propiedad intelectual y de lo que ocurre en otras jurisdicciones. Y aplica igual al programador en relación de dependencia: si tu equipo interno desarrolló el sistema y nunca firmaron una cesión de derechos, la empresa tampoco es la titular.

Esto se arregla con un párrafo en el contrato. Lo caro es descubrirlo cuando quieres cambiar de proveedor, vender la empresa o simplemente que otro equipo continúe el trabajo.

Este artículo es orientación práctica para ordenar una negociación, no asesoría legal. La cesión de derechos redáctala con un abogado — pero entra a esa conversación sabiendo que hace falta, que es de lo que se trata todo esto.

De qué trata este artículo y de qué no

Hay tres decisiones distintas que se suelen mezclar en una sola conversación:

Qué construir o comprar — producto de estantería contra desarrollo a medida. Está tratado aparte en ERP genérico o a medida.
A quién contratarlo.
Bajo qué contrato.

Este artículo es sobre las dos últimas, que son las que casi nunca se preparan y las que determinan si dentro de tres años tienes un activo o un rehén.

Los cuatro modelos de contratación

Ninguno es mejor. Cada uno traslada el riesgo a un lado distinto de la mesa, y el error habitual es elegir el que suena más seguro para lo que menos encaja.

Precio fijo por alcance cerrado

Acuerdas entregables, precio y fecha. Te conviene cuando sabes exactamente qué quieres y no va a cambiar: una integración puntual, un módulo con reglas claras, una migración.

Lo que nadie dice: el precio fijo obliga al proveedor a estimar con incertidumbre, así que el riesgo se paga con sobreprecio. Y si a mitad del proyecto descubres algo mejor —que es lo normal— cada cambio abre una negociación. Los proyectos a precio fijo suelen entregar exactamente lo pactado, que a veces es exactamente lo que ya no sirve.

Tiempo y materiales

Pagas por horas o por sprint. Te conviene cuando el alcance va a evolucionar, que es la mayoría de los sistemas internos reales.

El riesgo se traslada a ti, y la protección no es el contrato sino la cadencia: entregas cada dos semanas a un ambiente que puedas ver. Si a los tres meses no hay nada funcionando que puedas abrir, el modelo se convirtió en un cheque en blanco.

Equipo dedicado

Contratas capacidad, no proyecto. Tiene sentido a partir de cierto volumen sostenido, y su ventaja real es la continuidad: el conocimiento del negocio se queda en el equipo. Requiere que alguien de tu lado dirija, porque un equipo dedicado sin dirección construye lo que le parece.

Híbrido

Precio fijo para un primer bloque bien definido —el que prueba que sabemos trabajar juntos— y tiempo y materiales para lo que sigue. Es lo que más se parece a cómo salen bien los proyectos.

Las siete cláusulas que deciden todo

Esta es la lista que conviene llevar impresa a la negociación.

1. Cesión de derechos patrimoniales

Por lo del artículo 115, el contrato debe decir expresamente que los derechos patrimoniales sobre el software desarrollado se ceden a tu empresa. Sin ese párrafo, no son tuyos.

Verifica además que cubra el código fuente y también la documentación, los diseños, los esquemas de base de datos y los guiones de despliegue. Un sistema sin sus scripts de despliegue es un sistema que sólo el autor sabe poner en marcha.

2. Entrega del código fuente, y cuándo

«Es tuyo» y «lo tienes» son cosas distintas. El contrato debe decir dónde vive el código durante el proyecto — lo sano es un repositorio en una cuenta de tu empresa, con acceso del proveedor, y no al revés. Si el repositorio es del proveedor y te lo entregará «al final», tu poder de negociación es cero justo cuando más lo necesitas.

3. Titularidad de las credenciales y de las cuentas

El dominio, el DNS, la cuenta de la nube, el certificado, la cuenta del correo transaccional, la del SRI. A nombre de tu empresa, con tu tarjeta y tu correo administrador, y el proveedor invitado como usuario.

Es la falla más común y la más dolorosa. Una empresa que no controla su dominio no controla su correo, y una que no controla su cuenta de nube no puede ni mirar su factura ni mover su sistema.

4. Los datos, y cómo salen

Que conste por escrito que los datos son tuyos, y en qué formato te los llevas: un respaldo de la base completa, no un Excel de resumen. Ponle un plazo — «dentro de los diez días de solicitado».

5. El proveedor es «encargado del tratamiento»

Bajo la LOPDP, quien trata datos personales por cuenta tuya es el encargado del tratamiento, y eso trae dos obligaciones que van al contrato:

Cláusulas de confidencialidad y tratamiento adecuado. No tenerlas es infracción grave del artículo 68, numeral 9, con multa de entre el 0,7 % y el 1 % de tu facturación anual.
El plazo de dos días. El artículo 43 obliga al encargado a notificarte cualquier vulneración de seguridad dentro del término de dos días desde que la conoce. Si no está escrito, no te vas a enterar a tiempo — y tú tienes cinco días para notificar a la Superintendencia. Está desarrollado en la guía de la LOPDP.

6. Garantía y qué cuenta como error

Distingue defecto de cambio. Un defecto es que lo acordado no funciona y se corrige sin costo durante un período pactado; un cambio es que quieres algo distinto y se cotiza. Sin esa frontera escrita, toda discusión posterior es un pulso.

7. Continuidad y salida

Qué pasa cuando la relación termina, sea por lo que sea: un período de transición pagado, la documentación entregada, una sesión de traspaso al equipo que sigue. Un proveedor sano lo acepta sin problema — es la cláusula que más rápido revela con quién estás tratando.

Cómo evaluar a un proveedor sin ser técnico

No necesitas leer código. Necesitas hacer preguntas cuyas respuestas evasivas signifiquen algo.

«Muéstrame algo que hayas hecho, funcionando, y ponme en contacto con ese cliente.» No un portafolio con capturas: el sistema andando y alguien que lo use. Que sea de tu sector y de tu tamaño.

«¿Cómo voy a ver el avance?» La respuesta buena describe entregas frecuentes a un ambiente que puedes abrir tú. La respuesta mala es un informe mensual.

«¿Quién va a trabajar en esto?» Pasa seguido que quien vende no es quien construye. Pregunta quiénes son y si estarán durante todo el proyecto.

«¿Qué pasa si la persona que lo construyó se va?» Mide si hay documentación y más de una cabeza, o si estás contratando a un individuo con membrete de empresa.

«¿Qué es lo que más suele salir mal en un proyecto como el mío?» La mejor pregunta de todas. Quien ha entregado proyectos reales tiene una respuesta específica e inmediata. Quien no, dice que con buena comunicación no hay problemas.

«¿Qué de lo que te pedí no deberíamos construir?» Un proveedor que a todo dice que sí te está cotizando, no asesorando.

Señales de alarma

Cotiza sin preguntar casi nada. Un precio serio sale de entender la operación. Un precio inmediato sale de una plantilla.
El presupuesto es una cifra sin desglose. No permite comparar ni negociar alcance.
No menciona el SRI ni la LOPDP y tú tampoco los sacaste. Quien ha implementado en Ecuador los nombra solo.
Promete el sistema completo en una entrega grande y lejana. Te obliga a acertar el primer día.
Se resiste a la cláusula de salida. Es el indicador más confiable de todos.
El precio está muy por debajo del resto. A veces es eficiencia real. Muchas veces es alcance que no entendió y va a aparecer como «eso no estaba incluido».
Ofrece mantenimiento pero no lo define. «Soporte incluido» sin tiempos de respuesta acordados no es un compromiso; lo que sí lo es está descrito en mantenimiento y soporte.

Preguntas frecuentes

¿Proveedor local, de otra ciudad, o del exterior?

Lo que importa no es la distancia sino dos cosas: que entienda las obligaciones ecuatorianas —SRI, guías de remisión, LOPDP—, y que puedas hacer efectivo el contrato si algo sale mal. Un proveedor en otro país con un contrato bajo otra ley es un riesgo real cuando hay que reclamar, aunque el trabajo sea bueno.

¿Es más barato un freelance?

Por hora, casi siempre. El riesgo no es la calidad —hay freelancers excelentes— sino la continuidad: una persona sola se enferma, cambia de trabajo y no tiene con quién traspasar. Si vas por ahí, la cláusula de documentación y el repositorio en tu cuenta dejan de ser recomendables y pasan a ser obligatorias.

¿Cuánto debería costar?

No hay una cifra útil sin alcance, así que el primer paso de la conversación es acotarlo. Lo que sí puedes comparar es la estructura: que las propuestas desglosen por módulo o por fase, para poder recortar alcance en vez de regatear el total. Y suma siempre la infraestructura y el mantenimiento, que son costo recurrente.

Ya tengo un sistema y el proveedor desapareció. ¿Qué hago?

Primero, recupera el control de las cuentas: dominio, DNS, nube, repositorio. Después, un diagnóstico de qué hay y qué tan mantenible es. Tomar un sistema que construyó otro es un trabajo específico y se puede hacer; lo que no se puede es hacerlo sin acceso a la infraestructura.

¿Y si ya firmé sin la cesión de derechos?

Se puede firmar después, como acuerdo aparte. Conviene hacerlo mientras la relación es buena — pedirlo el día que quieres irte es una negociación mucho peor.

Lo mínimo que hay que llevarse

Si de todo esto sólo guardas tres cosas, que sean éstas.

El artículo 115 del Código Ingenios invierte lo que asumes. Sin cesión expresa, el software es del autor. Ese párrafo en el contrato es lo más barato que vas a firmar y lo más caro que puedes omitir.

Las cuentas y el repositorio, a nombre de tu empresa desde el primer día. No al final, no «cuando terminemos».

La cláusula de salida es el mejor examen del proveedor. Quien planea hacer bien el trabajo no tiene problema en explicar cómo se iría.

Cuando esas tres están resueltas, la conversación puede pasar a lo que importa, que es qué construir y en qué orden — que es donde empieza un proyecto de desarrollo de software a medida que valga la pena.