Tu developer se fue y tu app es un desastre. Aquí está lo que sigue.
El tiempo es dinero. Si el developer anterior se fue sin avisar, la agencia se disolvió, el contratista entregó trabajo de mala calidad, o el equipo simplemente siguió adelante, ahora eres dueño de una app que no escribiste. Auditamos primero, identificamos qué se puede salvar, luego tomamos el control a precio fijo. Sin misterios, sin estimaciones que se desvían, sin proyectos estirados.
Auditoría primero · Precio fijo · Liderado por senior · Ventana de estabilidad de 30 días
Resultado de rescue
0.7★ → 4.4★ en una app de terapia React Native heredada
Tomamos el control de una app de salud React Native que estaba fallando, semanas antes de que el cliente ancla se fuera. El equipo anterior ya no estaba en el proyecto. Reconstruimos el codebase lo suficiente para enviar, pasamos la aprobación en ambas tiendas en 4 semanas, y corrimos triage quincenal de crashes para asegurar estabilidad. Números por proyecto de un rescue reciente.
Leer el caso completo →Si alguno de estos te suena, hemos tomado una app como la tuya antes
Estas son las situaciones que vemos más seguido cuando equipos llegan con un proyecto móvil heredado.
El developer o agencia anterior ya no está
El contratista dejó de responder. La agencia se disolvió o pivotó. El developer interno se fue sin terminar el handoff. Tienes un repositorio, tal vez credenciales, tal vez no. Nadie en tu equipo actual puede enviar un release.
Sin documentación, sin decisiones arquitectónicas, sin runbooks
El equipo anterior no escribió por qué se construyó nada de la manera en que se construyó. Onboardear a un nuevo developer toma semanas porque cada decisión está sin documentar. Re-derivar la intención hace lento cada cambio.
Pipeline de build y release roto o incompleto
El pipeline que el developer anterior usaba está roto en tus máquinas. Certificados de code-signing expirados. Acceso a App Store Connect bloqueado. Cuentas de Play Console a nombre de otra persona. Los releases son inenviables hasta que esto se ordene.
Credenciales críticas, cuentas o servicios a nombre de un empleado anterior
Cuenta de App Store, Play Console, Firebase, certificados de code-signing, cuentas de SDKs de terceros, API keys. El equipo anterior es el dueño nombrado. No puedes enviar un release sin esto. Tenemos un proceso para esto.
Trabajo de features sin terminar o parcialmente fusionado en el codebase
Ramas que nunca se terminaron. Feature flags apuntando a nada. Estados de UI que existen en el código pero nunca fueron integrados. El codebase se ve más grande que la app realmente porque la mitad está incompleta.
Brechas de seguridad, problemas de compliance o de licenciamiento dejados atrás
Secretos hardcodeados en el repo, dependencias abandonadas con CVEs conocidos, librerías de terceros usadas fuera de su licencia, sin privacy manifest, sin rastro de revisión de seguridad. La deuda técnica tiene una dimensión de compliance.
Cómo corre una toma de control en la práctica
Cuatro etapas. Pasos concretos y claros. Cada paso tiene un entregable al que puedes apuntar.
Technical Audit pagada
Primer paso obligatorio. Acceso de solo lectura al repo. Producto independiente. Te llevas un informe escrito, independientemente de si sigues adelante.
Leemos el codebase, el historial de commits (lo que queda), la configuración de build, y la documentación que exista. Mapeamos lo que funciona, lo que está roto, lo que falta por completo. La auditoría produce una lista de hallazgos priorizada por severidad, una evaluación de deuda técnica, y un plan de rescue. Cinco días hábiles, precio fijo. Esto no es negociable: cotizaciones de rescue sin auditoría son adivinanzas, y las adivinanzas te cuestan dinero.
Plan de rescue
Convertimos los hallazgos de la auditoría en un alcance de rescue de precio fijo. Ves el plan, los pasos de transferencia de credenciales, y el número en dólares antes de que comience el trabajo.
Algunas tomas de control necesitan estabilización (detener el sangrado, hacer que el pipeline de release funcione, recuperar credenciales). Algunas necesitan reconstrucción (el codebase es inviable; la respuesta correcta es un fresh start). La auditoría te dice en cuál caso estás honestamente. Si una reconstrucción es la respuesta correcta, lo decimos y re-escopeamos como un Build, no un rescue estirado.
Toma de control ejecutada
Toma de control hands-on. Acceso de lectura/escritura al repo, builds diarios, sync semanal. Enviamos en el orden que la auditoría priorizó.
Recuperar credenciales primero. Hacer que el pipeline de build funcione. Diagnosticar y arreglar issues que bloquean releases. Establecer una base limpia desde la cual puedes enviar. Luego nos movemos al trabajo priorizado que la auditoría sacó a la luz. Builds diarios para tu equipo, sync semanal con stakeholders. No añadimos feature work durante la fase de estabilización.
Handoff y ventana de estabilidad
Documentación de handoff para tu equipo (o un nuevo contratista), más una ventana de estabilidad de 30 días. Después eliges tu próxima ruta.
Tu equipo toma el volante con el paquete de handoff que el developer anterior nunca produjo: runbooks operacionales, registros de decisiones arquitectónicas, un doc de onboarding, propiedad de credenciales transferida a tu control. Una ventana de estabilidad de 30 días sigue al handoff: respondemos a cualquier cosa que el rescue haya sacado a la superficie en producción. Después eliges: mantener in-house, contratar a alguien, o graduarte a un Partner retainer.
Resultados de un rescue reciente
Números por proyecto de un rescue de app de terapia React Native en salud.
0.7★ → 4.4★
Vuelta de la calificación en App Store
4 semanas
Aprobación en ambas tiendas tras envío
$8k+
Precio de rescue publicado comienza aquí
¿Cuánto cuesta una toma de control?
Auditoría primero, cotizado rápido. Alcance de rescue de precio fijo desde los hallazgos. Sin estimaciones, sin proyectos estirados.
Rescue de Toma de Control de App Móvil
Desde $8,000 · auditoría primero, luego cotizado
Auditoría primero ($2,500 Quick Scan o $5,000 Full Audit). Rescue de precio fijo escopado desde los hallazgos. Depósito + milestones. Ventana de estabilidad de 30 días tras el handoff.
El alcance se cierra tras la auditoría. Si los hallazgos muestran que el codebase está más allá de estabilización, re-escopeamos como un Build (reconstrucción) o un Partner (propiedad continua), no un rescue estirado.