Hoy cambié la cerradura de Nido con la gente adentro.

Nido es el acompañante de IA que estoy construyendo para personas en transición vital: una conversación que se convierte en un plan semanal, con privacidad radical. Desde hoy, el registro está abierto: cualquier persona puede entrar con su cuenta de Google o con un código que le llega al correo. Sin contraseña, sin invitación, sin cupos.

Suena a una pantalla nueva. No lo era. Lo difícil de abrir una puerta no es la puerta: es que quien ya estaba adentro no pierda nada cuando cambias todo lo que hay debajo.

El defecto que tenía nombre

El defecto principal de la corporación cabía en una frase: no podía sumar usuarios nuevos, porque la gente se perdía en el login. La meta fue igual de concreta. Que alguien nuevo, sin ayuda, se cree una cuenta y entre en el menor número de pasos posible. Que vuelva a entrar sin problemas. Y que, si ya tenía cuenta, conserve sus datos.

Sospeché primero de la protección de despliegues de Vercel. No era eso: los dominios de producción respondían bien. Las causas eran varias a la vez, y se sumaban. Listas de correos permitidos: si no estabas, no entrabas. Un entorno de login de desarrollo funcionando en producción, compartido entre varias apps, con tope de 100 usuarios y fallas en Safari de iPhone. Contraseña obligatoria. Rutas que mandaban a la app equivocada. Pantallas de “acceso denegado” sin salida.

Una puerta por casa

Decidí una app de login de producción por cada producto, cada una en su propio subdominio. Nido primero, como piloto.

Antes de tocar el login pasé Vercel al plan Pro, US$20 al mes, porque PRISMA, otro producto de la corporación, anuncia un servicio pagado y el plan gratuito no permite uso comercial. El servicio de login, Clerk, sigue en su plan gratuito, con un costo que acepté a conciencia: el correo con el código llega en inglés, porque esas plantillas no se pueden editar. Lo aviso en la pantalla de entrada. Prefiero una limitación dicha a una sorpresa.

Lo que de verdad estaba en juego

En Nido ya había cuentas con historia, la mía entre ellas. Para un sistema de login nuevo, todas son desconocidas. Hay que traer lo de antes —el plan, la bitácora, lo que Nido fue aprendiendo— y pegarlo a la cuenta nueva.

Escribí un plan maestro y lo sometí a una revisión adversarial: cinco lentes, 54 agentes, 63 hallazgos confirmados, cuatro altos. El que más cambió el plan fue ese traslado: disparado desde el lugar equivocado, podía mover los datos reales a la cuenta incorrecta. Quedó restringido a producción y al dominio propio de la app.

La misma revisión invirtió el orden del corte: primero se prepara todo lo nuevo sin que lo viejo lo note, y el corte ocurre en un solo instante, sin ventana intermedia.

Huecos en el procedimiento

El día del corte empezó con todos mis sitios caídos desde las 3:52 de la madrugada por una factura de hosting impaga, que pagué en la tarde.

Ese día revisé y aprobé cada texto nuevo —pantalla de entrada, landing, quiz opcional, cinco correos, página de baja— en una página generada desde el código real, no desde un documento que dijera lo que el código debería decir.

Después vino la revisión que más me enseñó. Una pasada de solo lectura antes de tocar producción: diez agentes repartidos en cinco enfoques, y en cada enfoque un verificador encargado de desmentirlos. Cero bloqueos, once hallazgos medios confirmados. Ninguno era un bug que rompiera el corte. Casi todos eran huecos del procedimiento.

Uno me dejó pensando. La vuelta atrás “rápida” dejaba de valer apenas saliera un solo correo con el link nuevo, y ese correo no dependía de mí: el quiz de la landing lo envía automáticamente a quien lo responde. Otro: borrar en el sistema de login a alguien cuyos datos ya se habían traído borraba esos datos y, con ellos, el puente para revertir.

El código aguantaba el corte. Lo que tenía agujeros era la secuencia de cosas que yo iba a hacer con él.

Al cambio de base de datos le hice además una prueba sobre la base real que se deshace sola: termina en error a propósito y no deja nada escrito. Probó traer los datos y devolverlos.

18:52

El cambio entró a las 18:51. La versión nueva quedó lista a las 18:52, y esa fue la hora del corte.

La primera prueba en producción la hice yo. Desde la landing entré con Google a la app nueva en tres clics, y Nido trajo todo lo mío: el plan, la bitácora, lo que había aprendido de mí. Salí. Intenté abrir una página protegida y me bloqueó. Entré con un código al mismo correo y caí en la misma cuenta, justo en la página que había pedido. Lo repetí en un iPhone. Mis otras apps siguieron con su sesión abierta. Un navegador con la sesión vieja no quedó atrapado en un loop.

De ocho criterios, seis quedaron verdes de punta a punta. Los dos pendientes, con todas sus letras: crear una cuenta nueva desde cero con código (la prueba con un correo alternativo no llegó a crearse) y Android (no había teléfono). Aparte, quedó por probar el aviso automático cuando alguien borra su cuenta.

Cuatro tropiezos

Un “listo” que no era lo que parecía. Para limpiar unos controles automáticos en rojo se rehicieron las versiones de prueba y quedaron todas listas. Eran de una versión anterior del código, no de la que iba a publicar. Casi cito como evidencia algo que no correspondía. “Listo” dice que algo se construyó, no qué se construyó.

Un 403 que asustaba. Justo después del corte, tres pruebas devolvieron acceso prohibido. Era una protección del propio sistema contra formularios enviados desde otro sitio, rechazando con razón una prueba mal armada. Leyendo la respuesta completa lo vi en un minuto. Primero se lee, después se diagnostica.

Un error repetido. Uno pequeño de la terminal me mordió dos días seguidos, y la segunda vez la lección ya estaba escrita. Escribirla no alcanza: hay que cambiar la herramienta.

Un plan que venció. Horas después del corte, otros dos frentes de trabajo publicaron cambios encima, y la vuelta atrás instantánea dejó de aplicar. Solo quedó la lenta. Un plan de vuelta atrás tiene fecha de vencimiento, y casi nunca la trae impresa.

Lo que viene

Mañana reviso que el envío automático diario no le haya escrito a nadie por error, y sigo con siete días de monitoreo. Después, el aviso a las personas inscritas de que ya pueden entrar, con vista previa y mi aprobación antes de que salga. Luego, el mismo cambio en las demás apps de la corporación.

La puerta nueva era la parte visible. Lo que ocupó estos tres días fue cuidar que nadie que ya estaba adentro tuviera que empezar de cero. Y eso no se jugó en el código, sino en el orden de las cosas que decidí hacer con él.