mi desarrollador renunció: qué hacer con tu aplicación web (guía para dueños).

el mensaje llega un viernes: "tenemos que hablar — me voy". o peor: el desarrollador simplemente deja de contestar. tu aplicación sigue funcionando, los pedidos siguen entrando, pero de un día para otro nadie en tu empresa sabe cómo se mantiene viva. respira: esto se resuelve con orden, no con pánico. esta es la guía concreta, paso a paso, escrita para dueños de negocio — no para programadores.

// las primeras 48 horas: asegura los accesos

una aplicación web no vive en el computador de nadie: vive en un conjunto de cuentas de servicios. dominio, hosting, repositorio de código, base de datos, correo, pasarela de pago. si esas cuentas están a nombre de tu desarrollador, hoy no eres dueño de tu sistema — eres usuario de un sistema ajeno. el objetivo de las primeras 48 horas es invertir eso, idealmente mientras la relación todavía es cordial.

• -dominio: verifica quién figura como titular. si tu sitio es .cl, la titularidad se consulta y se transfiere en nic.cl. si el dominio está a nombre del desarrollador, esa transferencia es tu trámite número uno.
• -hosting / nube: identifica dónde corre la aplicación (vercel, aws, google cloud, hostinger, un vps) y pide ser dueño de la cuenta, o que el proyecto se transfiera a una cuenta creada con un correo de tu empresa.
• -repositorio de código: pide que el código se transfiera a una cuenta u organización tuya en github o gitlab. que te "compartan acceso" no basta: la propiedad de la cuenta es lo que manda.
• -base de datos: pide las credenciales y, el mismo día, un respaldo completo exportado (un archivo .sql o equivalente) guardado en un lugar tuyo. el respaldo de hoy es tu seguro contra cualquier cosa que pase después.
• -dns y correo: confirma quién administra los registros dns y el correo del dominio. si el correo de recuperación de todas las cuentas es el personal del desarrollador, cambiarlo es urgente.
• -pasarela de pago y servicios de terceros: cuentas de cobro, llaves de api, email transaccional, analytics. anota cada servicio, a nombre de quién está y con qué tarjeta se paga.
• -contraseñas: centraliza todo en un gestor de contraseñas de la empresa (1password, bitwarden) — no en un excel ni en whatsapp.

pide un traspaso ordenado mientras la puerta sigue abierta

si la salida es en buenos términos, pide tres cosas antes del último día: una sesión grabada donde muestre cómo se publica un cambio (el deploy), un documento breve con la lista de servicios y accesos, y los días de soporte de transición que estén pactados en el contrato — o negócialos como un cierre pagado si no lo están. pagar unas horas de traspaso ordenado es la mejor inversión disponible esta semana.

// qué tienes realmente: código documentado o caja negra

con los accesos asegurados, la siguiente pregunta es simple y honesta: ¿puede otra persona competente tomar este proyecto y publicar un cambio sin ayuda del desarrollador anterior? la respuesta define cuánto te va a costar todo lo demás.

señales de un proyecto rescatable rápido

• -el repositorio tiene un readme con instrucciones para levantar el proyecto
• -las variables de configuración están listadas (un archivo .env.example o un documento equivalente)
• -el deploy es automático: un cambio en el repositorio se publica solo
• -el código del repositorio coincide con lo que está corriendo en producción
• -la base de datos tiene migraciones versionadas o, al menos, respaldos automáticos

señales de caja negra (presupuesta más tiempo y dinero)

• -el deploy se hacía "desde el computador" del desarrollador
• -no hay repositorio, o lleva meses sin actualizarse mientras producción sí cambió
• -hay credenciales que solo existían en su cabeza o en su correo personal
• -nadie puede decirte qué servicios externos usa la aplicación ni cuánto cuestan al mes

no necesitas ser técnico para esta evaluación: cualquier desarrollador de confianza puede responderla en una sesión corta mirando el repositorio. lo importante es hacerla antes de contratar al reemplazo, no después.

"no eres dueño de tu aplicación: eres dueño de las cuentas donde vive. asegura las cuentas y todo lo demás tiene solución."

// tus opciones reales para retomar el proyecto

opción 1: contratar un desarrollador interno

tiene sentido cuando el software es el corazón del negocio y hay trabajo continuo para una jornada completa: roadmap, funcionalidades nuevas todos los meses. el costo es un sueldo permanente más un proceso de búsqueda que en chile no es inmediato. y el riesgo silencioso: si contratas a una sola persona, en un año puedes estar leyendo esta misma guía de nuevo.

opción 2: freelance por horas

flexible y rápido de activar; útil para mantención liviana. el problema aparece cuando el proyecto es una caja negra: sin diagnóstico previo, las primeras semanas se van en exploración facturada por hora, sin entregable claro, y tú no tienes cómo distinguir avance real de horas de lectura.

opción 3: rescate por proyecto, con alcance cerrado

un profesional o estudio toma el sistema, ordena accesos y documentación, deja el deploy reproducible y entrega un informe del estado real con un plan priorizado. precio cerrado contra entregables definidos: sabes qué recibes y cuánto cuesta antes de partir. como referencia real de mercado, en mi propia lista de precios los proyectos parten en $1.000.000 clp — un rescate acotado vive en ese orden de entrada, y un sistema grande o muy enredado escala desde ahí según el estado del código.

las tres opciones se combinan. el patrón que mejor protege al dueño es rescate por proyecto primero — para saber qué tienes y dejar la base ordenada — y recién después decidir, con información, si necesitas alguien interno, un freelance estable o mantención por horas.

// el diagnóstico técnico es poder de negociación

cuando no sabes qué tienes, cualquier presupuesto que te den es un número imposible de evaluar — y quien te cotiza lo sabe. con un diagnóstico técnico independiente sobre la mesa, la conversación cambia de naturaleza:

• -sabes si el código es rescatable o si conviene reescribir partes — antes de pagar por mantenerlo
• -puedes pedir presupuestos comparables, porque todos cotizan contra el mismo documento y el mismo alcance
• -distingues lo urgente (seguridad, respaldos, accesos) de lo cosmético, y pagas en ese orden
• -si alguien te propone "reescribir todo desde cero", tienes una segunda opinión técnica para desafiar ese número

publiqué una guía completa sobre qué debe cubrir una auditoría técnica — búscala en el blog como "auditoría técnica de tu aplicación web". y si prefieres partir directo, en /diagnostico está el formato con el que trabajo estos casos.

// que no vuelva a pasar: las reglas permanentes

esto tiene nombre: bus factor — el número de personas que pueden desaparecer del proyecto antes de que se detenga. si tu respuesta es "una", acabas de vivir las consecuencias. las reglas para no repetirlo son simples y no negociables:

• -todas las cuentas a nombre de la empresa: dominio, hosting, repositorio, base de datos y pasarela se crean con un correo del dueño y se pagan con la tarjeta de la empresa. los desarrolladores entran como colaboradores invitados, nunca como dueños de la cuenta.
• -documentación mínima viva: un readme con cómo levantar y publicar el proyecto, más una lista de servicios con sus costos. se actualiza con cada cambio importante.
• -respaldos automáticos verificados: no basta con que existan — alguien tiene que haber restaurado uno alguna vez.
• -traspaso como cláusula de contrato: todo acuerdo con un desarrollador define qué se entrega al salir (accesos, documentación, sesión de traspaso).
• -revisión externa periódica: un par de ojos independientes una o dos veces al año detecta el problema cuando todavía es barato arreglarlo.

perder un desarrollador es un problema de semanas. perder la propiedad de tus cuentas puede ser un problema de meses — y de abogados. la diferencia entre los dos escenarios se decide en las primeras 48 horas.