Cómo cambiar de desarrollador o agencia sin perder tu app
Qué comprobar antes de dejar a tu desarrollador o agencia actual: acceso al código, dominio y cuentas, y cómo hacer el traspaso sin parar tu app o tu web.
Germán Hernández
· 7 min de lectura
Puedes cambiar de desarrollador o agencia sin perder tu app o tu web si antes confirmas que tienes acceso real al código, al dominio y a las cuentas de App Store, Google Play y hosting. El problema no es dejar a quien te desarrolló hasta ahora: es descubrir, cuando ya quieres irte, que todo eso está a nombre de otra persona.
En los proyectos que hago me he encontrado varias veces con negocios que llegan a esta situación sin haberlo decidido: no eligieron cambiar, se vieron obligados porque su desarrollador dejó de responder, subió el precio sin avisar o cerró el negocio. Esta guía sirve para los dos casos, el cambio planeado y el cambio forzado.
Por qué no deberías esperar a que surja un problema
Lo habitual es no pensar en esto hasta que hace falta: una funcionalidad rota, un desarrollador que no contesta o una subida de precio que no esperabas. En ese momento, si no tienes acceso a lo básico, no puedes simplemente buscar a otra persona y seguir adelante. Primero tienes que recuperar el control de tu propio producto, y eso puede llevar semanas si quien lo tenía no colabora.
Por eso conviene comprobarlo ahora, tengas o no intención de cambiar a corto plazo. Si quieres saber qué debería haber quedado por escrito desde el principio para evitar justo este problema, lo cubro en qué debe incluir un contrato de desarrollo de app o web.
Qué debes tener acceso antes de plantear un cambio
Antes de hablar con nadie nuevo, revisa si tienes en tu poder, o puedes conseguir en pocos días, estos elementos:
- El código fuente completo, en un repositorio al que puedas dar acceso a otra persona (no una copia suelta en un ordenador de otro).
- El dominio, registrado a tu nombre en tu propia cuenta del registrador, no en la cuenta del desarrollador.
- Las cuentas de App Store Connect y Google Play Console, con el rol de propietario asignado a tu empresa.
- El acceso al hosting o al proveedor donde corre el backend, incluidas las credenciales de la base de datos.
- La documentación mínima: qué servicios externos usa el proyecto (pagos, email, mapas) y con qué claves.
Si falta alguno de estos puntos, no significa que debas entrar en conflicto de inmediato. Significa que la primera conversación con tu desarrollador actual debe ser para pedir ese acceso, antes de hablar de cualquier otra cosa.
Señales de que el cambio conviene, aunque no haya un conflicto claro
No hace falta una ruptura dramática para plantearse un cambio. Algunas señales que veo con frecuencia:
- Las respuestas tardan cada vez más, aunque el contrato de mantenimiento siga activo.
- Cada petición pequeña se cotiza como un proyecto nuevo, sin relación con lo que ya se pagó.
- El código no se ha actualizado en mucho tiempo y empieza a dar problemas con versiones nuevas de iOS, Android o del navegador.
- Ya no reconoces quién lleva tu cuenta: ha cambiado de persona varias veces sin que nadie te lo explique.
- Sientes que preguntas más de lo que te responden, y las explicaciones técnicas nunca bajan a un lenguaje que entiendas.
Ninguna de estas señales obliga a cambiar, pero juntas suelen anticipar un problema mayor. Si quieres repasar qué preguntar para no repetir la misma experiencia con el siguiente, tengo una lista completa en qué preguntar antes de contratar a un desarrollador de apps.
Cómo hacer el traspaso sin parar la app o la web
Una vez decidido el cambio, el orden importa para no dejar tu producto caído mientras tanto:
- Pide el acceso por escrito, con fecha límite razonable (una o dos semanas suele ser suficiente para un proyecto normal).
- No canceles nada todavía: ni el hosting, ni el dominio, ni las cuentas de desarrollador, hasta que el nuevo equipo confirme que todo funciona con los accesos recibidos.
- Haz una copia del código y de la base de datos en cuanto tengas acceso, aunque no vayas a tocarlos de inmediato.
- Revisa certificados y claves que caducan: certificados de notificaciones push, claves de APIs de pago o de mapas. Si vencen durante el traspaso, la app o la web puede dejar de funcionar aunque nadie haya tocado el código.
- Haz la transición en paralelo, no de golpe: el equipo nuevo revisa y prueba con los accesos reales antes de que se corte cualquier contrato con el anterior.
Si el acceso no llega o llega incompleto, tienes dos caminos: insistir con un plazo formal (por escrito, citando el contrato si existe) o, si el coste de insistir es mayor que el de reconstruir, valorar una reconstrucción parcial. No es la opción ideal, pero a veces sale más barato y más rápido que una disputa larga por unas credenciales.
Cuándo compensa reconstruir en vez de traspasar
Hay casos donde, aunque consigas el acceso, no merece la pena seguir sobre el código existente:
| Situación | Qué suele convenir |
|---|---|
| Código desordenado, sin documentación, difícil de entender para otro equipo | Reconstrucción parcial del módulo más problemático, manteniendo lo que funciona bien |
| Tecnología muy antigua que ya no recibe soporte ni actualizaciones | Reconstrucción completa, aprovechando el diseño y los contenidos existentes |
| Acceso completo, código razonable, solo falta cambiar de interlocutor | Traspaso directo, sin reconstruir nada |
| Proyecto pequeño y barato de rehacer frente al tiempo de recuperar accesos perdidos | Empezar de nuevo puede ser más rápido que una disputa larga |
Cualquier desarrollador serio, al recibir el código, debería darte una valoración honesta de en qué situación estás antes de cobrarte nada.
Qué pedir al nuevo desarrollador desde el primer día
Para no repetir el mismo problema dentro de un año, deja esto claro desde la primera conversación con quien va a continuar el proyecto:
- Que el código, el dominio y las cuentas queden a tu nombre desde el primer día, no solo al terminar.
- Que te dé acceso de lectura a todo lo que se vaya construyendo, aunque no sepas programar.
- Que el contrato indique explícitamente qué pasa con esos accesos si la relación termina en el futuro.
Preguntas frecuentes
¿Puedo cambiar de desarrollador si no tengo el código?
Puedes, pero primero tienes que reclamarlo. Si el código se creó para tu negocio y lo pagaste, normalmente te corresponde, aunque la reclamación sea más fácil o más difícil según lo que diga el contrato original. Si no hay contrato o no dice nada sobre propiedad, la conversación es más complicada y puede requerir insistencia o, en última instancia, asesoría legal.
¿Cuánto tiempo lleva un traspaso normal?
Para una app o web de tamaño pequeño o mediano, con accesos disponibles desde el principio, entre una y tres semanas suele bastar para que el nuevo equipo revise el proyecto y confirme que puede continuar sin sorpresas. Si hay que reclamar accesos o reconstruir partes, el plazo depende de cada caso.
¿Es buena señal que mi desarrollador actual se niegue a dar accesos?
No. Un profesional serio no tiene motivo para retener el código, el dominio o las cuentas de un proyecto ya pagado. Si te encuentras con resistencia, es la señal más clara de que el cambio, aunque incómodo, es la decisión correcta.
Si estás valorando un cambio y quieres que alguien revise primero en qué estado está tu proyecto actual, antes de prometerte nada, puedes escribirme en contacto o ver cómo planteo un desarrollo con alcance y precio cerrados en app, web y panel por 3.000 EUR en 4 semanas.
