Hay una pregunta que casi nadie hace antes de firmar, y que decide si lo que estás comprando es un activo o una jaula: *¿el código es mío?*
Suena obvio. No lo es. Muchos contratos de desarrollo te entregan un sistema que funciona —y al que no puedes tocar, mover ni mantener sin tu proveedor original. Pagaste por construirlo, pero no eres dueño de él. Eres su inquilino. Y la renta no baja.
Qué significa "ser dueño" de verdad
No basta con que el sitio o la app estén en línea a tu nombre. La propiedad real son cuatro llaves, y necesitas las cuatro:
- El repositorio. El código fuente completo, en un Git que controlas tú (tu cuenta de GitHub/GitLab), con todo el historial. No un ZIP suelto el último día.
- La base de datos. El proyecto de Supabase (o el que sea) creado en tu organización, con tus datos exportables cuando quieras.
- El hosting. El sitio en tu cuenta de Netlify/Vercel, no en la del proveedor "para simplificar".
- El dominio. Registrado a tu nombre, con acceso a tu DNS. No "lo gestionamos nosotros".
Si una de esas cuatro está a nombre de quien construyó, no eres dueño del producto: eres dueño de un permiso para usarlo mientras le pagues.
El costo de no tenerlo
No tener las llaves no se siente caro el día uno. Se siente caro el día que quieres hacer un cambio, cotizar con alguien más, o simplemente saber qué tienes. Tres formas en que muerde:
- Rehén del proveedor. Cada ajuste —un texto, un campo nuevo, un precio— pasa por una sola puerta. Esa puerta pone el horario y el precio. Sin código, no hay segunda opinión posible.
- No puedes migrar. Si el proveedor sube tarifas, baja calidad o desaparece, no te llevas nada. Empezar de cero es más caro que la primera vez, porque ahora hay datos de clientes adentro.
- Renta eterna. El "mantenimiento" deja de ser servicio y se vuelve peaje. Pagas por seguir teniendo acceso a algo que ya pagaste por construir.
Y hay un costo silencioso: tu plataforma no entra en el balance como activo. Un sistema cuyo código no controlas no es valuable en una ronda de inversión ni en una venta. Es un gasto recurrente disfrazado de propiedad.
La excusa técnica que deberías ignorar
A veces el lock-in se justifica con argumentos que suenan razonables: "es nuestra metodología", "el código es propietario de la casa", "así te damos soporte mejor". Tradúcelo: *queremos que dependas de nosotros.*
Un buen equipo no necesita atarte para que te quedes. Se queda porque hace buen trabajo, no porque tengas la salida bloqueada. La propiedad del código y un buen contrato de soporte no se pelean — conviven. Lo que no debería existir es soporte que solo funciona si renuncias a ser dueño.
Esto, por cierto, es una de las diferencias prácticas entre una agencia y un studio de producto: el modelo de negocio de quien vende horas premia que sigas atado; el de quien vende resultado, no.
Qué pedir antes de firmar
Pon esto por escrito en la propuesta o el contrato. No es agresivo — es higiene básica:
- Cesión total de derechos del código fuente al cierre del proyecto, sin licencias "de uso" que se reserva el proveedor.
- Acceso de administrador a repositorio, base de datos, hosting y DNS — a tu nombre, desde el inicio, no "cuando terminemos".
- Cláusula explícita de no lock-in: stack estándar y documentado, sin componentes propietarios que solo ese proveedor pueda mantener.
- Plan de salida (offboarding): cómo se te entrega todo y se transfieren accesos si la relación termina. Que exista esa cláusula ya dice mucho de con quién tratas.
- Documentación mínima: README para correr el proyecto y un mapa de la infraestructura. Sin esto, el repo es tuyo pero ilegible.
Si te dicen que no a la primera, ya tienes tu respuesta sobre qué estabas a punto de comprar.
En XXDM, las llaves son tuyas desde el día uno
No es una promesa de marketing, es cómo trabajamos. El repositorio se crea en tu cuenta, la base de datos en tu organización de Supabase, el hosting en tu Netlify y el dominio a tu nombre. Construimos sobre stack estándar —Supabase, Netlify, React/Astro— precisamente para que cualquier buen desarrollador pueda tomar el relevo. Tú no dependes de nosotros: nos quedamos si hacemos buen trabajo.
Y lo puedes comprobar: Hypothek —portal multi-rol de 8 etapas que construimos en 12 días— y RealZtage corren en producción, en infraestructura de sus dueños. Esos son los casos que puedes abrir y verificar.
No presumimos. Comprobamos. Y lo que construimos, te lo quedas.
¿Vas a contratar desarrollo y quieres saber qué pedir para no terminar atado? Agenda un diagnóstico — revisamos tu caso sin vueltas.