Esta es la pregunta más cara que las PyMEs argentinas no hacen antes de contratar dev. Tres escenarios reales (sin nombres porque son clientes que vinieron a rescate), y las 3 preguntas que evitan la trampa.
Tres escenarios reales (con números)#
Caso 1: el cliente fantasma#
PyME contrata freelance por ARS 200k. Sitio "listo". A los 6 meses quieren agregar una sección. El freelance no responde. Resultado: pagan ARS 400k a otro dev para tomar control, porque el código original estaba en una cuenta personal del freelance y nada escrito decía cómo recuperarlo. No podían ni mover el sitio de servidor.
Caso 2: la agencia "incluida"#
Otra PyME contrata agencia por ARS 1.5M. "Incluye mantenimiento mensual de $80k". Después de 18 meses, $1.4M extras en mantenimiento. Quisieron salir, pero el código tenía dependencias del "framework propietario" de la agencia. No era portable.
Caso 3: Wix premium para siempre#
PyME arma su tienda en Wix. 3 años pagando USD 45/mes. Cuando quisieron migrar, descubrieron que no se podían llevar los datos de los clientes ni el diseño. Empezaron de cero. Plata tirada acumulada: ARS 1.6M.
Las 3 preguntas que evitan la trampa#
1. ¿Cuándo pasa a ser mío el código, y dónde vive mientras tanto?#
Respuesta correcta: una condición concreta, como "cuando terminás de pagar", y una respuesta clara sobre dónde está alojado hasta entonces: en tu cuenta o en la infraestructura del proveedor. Respuesta peligrosa: "Es nuestro, vos tenés una licencia de uso", sin fecha de traspaso, o "eso lo vemos después".
2. ¿A nombre de quién queda el dominio?#
Respuesta correcta: "A tu nombre, en NIC Argentina o en el registrador que elijas." El hosting puede estar en tu cuenta o en la del proveedor, pero el dominio es la dirección donde te encuentran tus clientes: tiene que ser tuyo siempre. Respuesta peligrosa: "Lo registro yo y te lo incluyo en el abono" — si mañana te vas, te quedás sin tu dirección.
3. ¿Qué pasa si en 1 año quiero moverme a otro proveedor?#
Respuesta correcta: "Te entregamos el código —el repositorio transferido a tu GitHub o en un .zip—, las fotos y archivos, y tus datos en CSV o JSON, en un plazo definido y sin costo de salida." Si parte de tu sitio corre sobre un servicio que el proveedor comparte con todos sus clientes (un sistema de tienda o de reservas, por ejemplo), te lo tienen que decir antes: esas funciones no se mudan, pero tus datos sí. Respuesta peligrosa: "Lo armé con mi framework propio, sería difícil migrarlo", sin decirte qué te llevás. Si te dicen esto, correlo.
¿Tiene que estar el repositorio en tu cuenta desde el primer día?#
No necesariamente. Hay dos modelos honestos. En el primero, el proyecto vive desde el día 1 en tus cuentas (GitHub, hosting, base de datos): tenés todo a mano, pero también te toca crearlas, pagarlas y mantenerlas. En el segundo, el proveedor aloja y mantiene todo en su infraestructura, y el código pasa a ser tuyo cuando terminás de pagar: no te ocupás de nada técnico, pero dependés de que la salida esté bien escrita.
Los dos sirven. Lo que no sirve es el tercero, el más común: el código en la cuenta del dev, sin fecha de traspaso y sin una salida por escrito. De ahí salen los tres casos de arriba.
¿Qué hacer si ya firmaste sin preguntar?#
- Pedí por escrito una copia del código y la exportación de tus datos (email + WhatsApp).
- Si el dev no responde en 7 días, escalá legalmente — el código del sitio puede ser tuyo por ley si lo pagaste.
- En paralelo, hacé backup de todo lo público (el frontend) y exportá toda la data que tengas acceso.
- Considerá contratar a otro dev para una "auditoría de propiedad" — chequea qué tan portable es tu setup actual.
¿Por qué un dev serio quiere que el código sea tuyo?#
Porque no necesita atarte para que te quedes. El que te retiene escondiendo el código o el acceso es porque su trabajo no se sostiene solo. Un proveedor confiado te deja la salida por escrito —código, archivos y datos, sin costo— y te quedás igual, porque trabajás bien con él. El lock-in es una muleta de retención, no una práctica profesional. Si te lo proponen "para simplificar", desconfiá.
¿Qué tiene que decir el acuerdo, aunque sea un email?#
- Cuándo pasa a ser tuyo el código (por ejemplo, cuando terminás de pagar) y dónde vive mientras tanto.
- Que el dominio queda a tu nombre, no del proveedor.
- Cómo es la salida: qué te entregan (código, archivos y datos), en cuántos días y sin costo.
- Que tus datos se exportan en formatos abiertos (CSV o JSON) cuando los pidas.
- Qué incluye el proyecto y qué no (scope claro, para evitar el "eso es aparte").
- Precio fijo y plazo por escrito, no "por hora sin tope".
¿Cambia algo si es una app en vez de una web?#
Aplica lo mismo, más un detalle clave: las cuentas de Apple Developer y Google Play tienen que estar a TU nombre (o de tu empresa), no del dev. Si la app se publica bajo la cuenta del desarrollador, en las tiendas la app es de él. Pedí siempre publicar bajo tu propia cuenta de developer.
Preguntas frecuentes
¿El código de mi sitio es legalmente mío si lo pagué?
En Argentina, la titularidad del código depende del contrato. Sin contrato escrito, la propiedad puede quedar ambigua. Por eso es crítico pactar por escrito, antes de empezar, cuándo pasa a ser tuyo y qué te llevás si te vas.
¿Qué es el lock-in de un proveedor?
Es cuando técnicamente es muy difícil o imposible migrar tu sitio o app a otro proveedor. Ocurre cuando no hay una salida por escrito para llevarte el código, cuando el sitio depende de piezas propietarias que nadie te avisó que no se mudan, o cuando los datos no se pueden exportar.
¿Wix y Shopify tienen lock-in?
Sí, alto. Wix no te deja exportar el diseño ni los datos de los clientes. Shopify es un poco mejor (exportás productos y clientes) pero el theme y las customizaciones no son portables. Tiendanube está en el medio.
¿Cómo me aseguro que el código quede a mi nombre?
Pedí por escrito dos cosas: cuándo pasa a ser tuyo (una condición concreta, como terminar de pagar) y cómo te lo entregan si te vas (el repositorio transferido a tu GitHub o un .zip, en un plazo definido y sin costo). Algunos proveedores trabajan en tu cuenta desde el primer día y otros alojan el proyecto y te lo transfieren al terminar de pagar: los dos modelos sirven si la salida está escrita.
¿Me sirve tener el código si no sé programar?
Sí, muchísimo. Aunque no lo toques, el código es el activo: podés contratar a cualquier otro dev para que lo continúe, moverlo de servidor, o venderlo junto con tu negocio. Sin el código, dependés para siempre de una sola persona o plataforma.
¿Cómo maneja APEX la propiedad del código?
Cuando terminás de pagar, el diseño, los textos y el código de tu página son tuyos. Mientras te la alojamos, vive en la infraestructura de APEX, así no tenés que crear ni pagar cuentas técnicas. Si te vas, te lo llevás sin costo: el repositorio transferido a tu GitHub o en un .zip, con tus datos en CSV o JSON. Las funciones del sistema central (tienda, reservas, cursos y panel) no se mudan, porque las comparten todos los clientes, pero tus datos te los llevás siempre. El dominio queda siempre a tu nombre, y todo esto figura en los términos que ves antes de pagar.