Si tu programador desapareció o te ha dejado un código que nadie quiere tocar, la salida es un rescate en cuatro pasos: recuperar tu código y tus cuentas, auditar la app, estabilizar lo roto y, solo entonces, seguir construyendo. No necesitas saber leer código para salir de esta, y casi nunca hace falta rehacerlo todo desde cero. Lo que necesitas son dos cosas: la titularidad de lo que ya es tuyo y una auditoría técnica honesta. Todo lo demás sale de ahí.
Primero: asegura lo que es tuyo
Antes de cualquier trabajo técnico, recupera el control de los activos. Repasa esta lista hoy, aunque algunos puntos se te resistan:
- El código. ¿Está en un repositorio (GitHub, GitLab, Bitbucket) al que puedes entrar? Si solo existe en el ordenador del programador, pide una copia por escrito.
- El hosting y el dominio. Los servidores donde corre la app y el dominio deben estar en cuentas tuyas, no del programador.
- Las cuentas de las tiendas. En apps móviles, las cuentas de Apple y Google con las que se publicó. Si la app se publicó con la cuenta del programador, las actualizaciones de tus usuarios dependen de alguien ilocalizable.
- Los servicios de terceros. Pasarela de pago, correo, base de datos, analítica — todo lo que la app usa por detrás.
Si el programador no responde y controla algo de esto, ve directamente a los proveedores. Acreditando pagos y titularidad de la empresa, los hostings, registradores de dominio y tiendas de aplicaciones tienen procesos para transferirte el control. Es más lento que pedírselo a él, pero funciona.
Segundo: audita antes de rehacer
El error más caro en este punto es contratar al primero que dice “esto está fatal, hay que rehacerlo entero”. A veces es verdad. Pero un presupuesto de rehacer sin que nadie haya leído el código es un argumento de venta, no un diagnóstico.
Una auditoría seria es un trabajo corto y cerrado, normalmente unos días, en el que un desarrollador lee el código, intenta arrancarlo y te escribe un informe en lenguaje claro: qué hay, qué funciona de verdad, qué es peligroso y cuánto cuestan las opciones realistas. En nuestra experiencia, el informe cambia el plan del dueño más veces de las que lo confirma: muchas apps que “parecen” rotas funcionan en su mayor parte, y el camino rápido es estabilizar lo que ya existe.
La auditoría también te protege en el sentido contrario. Si el código de verdad no tiene salvación (un framework abandonado, actualizaciones imposibles, arreglos que rompen dos cosas por cada una que curan), el informe te da la evidencia, y la decisión de rehacer es tuya y no de un desconocido.
¿Arreglar o rehacer? Cómo decidirlo
No hay una respuesta universal, pero el patrón suele repetirse:
| Señal | Apunta a |
|---|---|
| La app funciona y tiene usuarios reales | Arreglar — el software que funciona vale más que el software bonito |
| Los fallos molestan pero son predecibles | Arreglar — estabilizar y luego mejorar |
| El framework o la plataforma están abandonados | Rehacer — no se puede parchear un cimiento muerto |
| Cada arreglo rompe otra cosa | Auditar más a fondo — puede salir por cualquiera de los dos lados |
| No hay repositorio ni historial | Cuidado — el riesgo real es lo que no se ve |
Rehacer tira a la basura cada lección que el código viejo ya pagó: todos los casos raros corregidos durante años desaparecen con él. Por eso, en nuestra experiencia, arreglar gana más veces de las que el dueño espera. Pero cuando los cimientos están mal, parchearlos es el camino caro. La auditoría existe para decirte en cuál de los dos casos estás.
Tercero: estabiliza antes de construir
Los rescates fracasan cuando se construyen funcionalidades nuevas sobre cimientos rotos. El orden aburrido es el que funciona:
- Seguridad primero — las copias de seguridad existen y se pueden restaurar, los agujeros de seguridad están cerrados, los errores se capturan y se ven.
- Entendimiento después — el nuevo desarrollador documenta lo que ha encontrado, para que el conocimiento deje de vivir en una sola cabeza.
- Lo nuevo, al final — solo cuando la app es estable tiene sentido desarrollar cosas nuevas.
Esta es además la prueba del algodón de a quién contratas para el rescate: un desarrollador que empieza por la monitorización, las copias y la documentación está planificando tu continuidad. Uno que empieza por un rediseño está planificando su factura.
Cómo queda cuando se hace bien
El final de un buen rescate se describe fácil: la app funciona, cada cuenta está a tu nombre, el código vive en un repositorio tuyo con su historial intacto, hay documentación que otro desarrollador podría seguir, y la producción está monitorizada para ver los problemas antes de que los usuarios los sufran. Así es como llevamos el software en Givore Studio — es el mismo montaje que usamos en Givore, la app comunitaria con ~10k usuarios que construimos y seguimos operando de principio a fin — y es lo que deberías exigir a cualquiera que retome tu app, incluidos nosotros. Un rescate bien hecho arregla algo más que la app: hace que nadie pueda volver a dejarte tirado.
Si estás en esta situación, el siguiente paso es pequeño: una auditoría corta, números honestos y un plan que puedes llevarte a donde quieras. En qué preguntar antes de contratar tienes cómo poner a prueba a quien contrates — también a nosotros. Y si quieres entender la parte de mantenimiento, cuánto cuesta mantener una app explica los números que nadie da por adelantado.