Mi programador desapareció: qué hacer en las primeras 48 horas

Las primeras horas: asegura lo que ya es tuyo

No empieces por buscar otro programador. Empieza por saber qué controlas hoy. Haz esta lista con una hoja y una pluma:

La verificación en dos pasos no es un detalle. Un estudio de Microsoft encontró que reduce el riesgo de que roben una cuenta en 99.22%.

Si la persona sigue teniendo acceso a cuentas tuyas, quítaselo solo después de tener una copia de todo. No cambies nada en el sistema en producción mientras tanto.

Pide la entrega por escrito

Manda un correo y un WhatsApp el mismo día, con fecha y en tono neutro. Pide cinco cosas:

1. El código fuente completo, con su historial, o acceso al repositorio.
2. Un respaldo completo de la base de datos.
3. La lista de servicios que usa el sistema y a nombre de quién está cada uno.
4. Los accesos que te falten.
5. La documentación que exista, aunque sea poca.

Si encargaste y pagaste el desarrollo, la Ley Federal del Derecho de Autor presume que los derechos patrimoniales son tuyos, salvo pacto en contrario (art. 83). Pero la cesión debe constar por escrito (art. 30). Si tienes contrato, cítalo en el mensaje. Si la situación escala, consulta a un abogado: esta guía no sustituye su consejo.

Cómo saber si lo que hay sirve

Con el código en la mano, pide a otro programador una revisión corta antes de decidir nada. Estas preguntas separan un sistema rescatable de uno que no:

• ¿Corre en otra computadora siguiendo las instrucciones del repositorio? Si nadie sabe levantarlo, ese es el primer trabajo.
• ¿Cada usuario ve solo lo que debe? El fallo de seguridad más común en aplicaciones web es el control de acceso roto: es el primero de la lista OWASP Top 10:2025.
• ¿Hay contraseñas o llaves escritas dentro del código? Si las hay, se cambian todas.
• ¿Hay pruebas automáticas? Sin ellas, cada arreglo puede romper otra cosa.
• ¿Qué tan viejas son las piezas que usa? Un sistema con años sin actualizar es más caro de mantener.
• ¿Hay respaldos y alguien los ha restaurado alguna vez?

Corregir, terminar o empezar de cero

Empezar de cero duele porque ya pagaste una vez. Pero seguir pagando por un sistema que nadie entiende suele salir más caro. Lo que no se tira son tus datos.

Cómo evitar que vuelva a pasar

18F, la oficina de tecnología del gobierno de Estados Unidos que cerró en 2025, dejó escrito un manual para reducir el riesgo de los proyectos de software a la medida. Sus reglas aplican igual a una pyme:

1. Tú eres dueño de todo lo que el proveedor produce, entregado al final de cada iteración, con documentación suficiente para que otro equipo lo levante.
2. Software funcionando cada dos semanas, no avances en un documento: "demos, no memos".
3. Contratos chicos. El manual cita el informe de Standish de 2015: los proyectos de menos de un millón de dólares tuvieron 61% de éxito y los de más de diez millones, 6%.

A eso súmale cuentas a tu nombre desde el primer día y pagos por etapa contra entregas que aceptas. Lo detallamos en ¿de quién es el código? y en qué debe decir un contrato de desarrollo.