Elimine el anonimato de mi app, y fue la decision correcta

Pasé semanas construyendo un sistema de autenticación anónima que permitía usar TAMSIV sin una cuenta. Era elegante, funcionaba bien y estaba orgulloso de ello. Esta semana, lo eliminé todo. Aquí te explico por qué fue la decisión correcta.

Por qué eliminé la autenticación anónima

Cuando lancé TAMSIV en alfa, el registro "lazy" era obvio. Según AppsFlyer, del 40 al 60% de los usuarios abandonan en el momento del registro. Al eliminar esta fricción, pensé que maximizaría la retención. Y funcionó, por un tiempo.

Pero en producción, la realidad es diferente. Las cuentas anónimas se acumulaban en la base de datos. Decenas de cuentas sin correo electrónico, sin forma de contacto, sin posibilidad de recuperación. Las métricas del panel de administración se volvieron ilegibles: imposible distinguir un usuario real de un curioso que abrió la aplicación durante 30 segundos.

El problema de seguridad era aún más concreto. Una cuenta anónima es una cuenta con un UUID y datos, pero sin una identidad verificable. Si alguien perdía su teléfono, sus tareas y notas desaparecían con él. Sin correo electrónico para la recuperación. Sin contraseña para la protección. Solo un token efímero en un dispositivo.

¿Cómo simplificó esta decisión el código?

[EXPERIENCIA PERSONAL] Al eliminar las sesiones anónimas, eliminé una cantidad sorprendente de rutas condicionales en el código. No más if (isAnonymous) en los servicios. No más lógica de migración de anónimo a cuenta real. No más limpieza automática de cuentas "zombie" después de 30 días.

El commit 7a0101d afectó el flujo de autenticación completo. En el primer lanzamiento, el usuario ahora llega a una pantalla de registro o inicio de sesión. Es más simple, más predecible y garantiza que cada persona que usa la aplicación ha tomado una decisión deliberada.

¿Corre el riesgo de perder usuarios en el momento del registro? Probablemente algunos, sí. Pero los que se registran son usuarios comprometidos. Y ese es exactamente el tipo de métrica que queremos seguir en producción.

El error de "flash" modal que nadie había notado

Al probar la nueva autenticación, descubrí un error vicioso. Cada vez que se iniciaba la aplicación, el modal de los términos y condiciones de uso aparecía durante una fracción de segundo antes de desaparecer. Un "flash" rápido, casi subliminal. El tipo de cosa que no notas conscientemente, pero que da una impresión de falta de pulido.

[DATOS ORIGINALES] El problema venía del tiempo. La aplicación cargaba el perfil de usuario desde Supabase, y durante esta carga, el campo terms_accepted era temporalmente null. El componente del modal interpretaba este null como "el usuario no ha aceptado los Términos y Condiciones" y se mostraba. Unos milisegundos después, el perfil llegaba con terms_accepted: true, y el modal desaparecía.

La solución en el commit 8979543: esperar el perfil fresco de la base de datos antes de evaluar el estado del modal. Sin perfil cargado = sin decisión = sin "flash". Simple, pero había que encontrarlo. Este tipo de error no se reproduce en las pruebas automatizadas porque los "mocks" devuelven el perfil instantáneamente.

¿Por qué aumentar una versión por "solo" 3 commits?

[PERSPECTIVA ÚNICA] Al construir en público, la tentación es fuerte de agrupar muchos cambios en una sola versión para que parezca impresionante. Hice lo contrario. El salto a la versión 1.04 (commit d900d21, versionCode 39) solo contiene estos tres cambios. Y es voluntario.

Un cambio de autenticación es el tipo de modificación que puede romper cosas de manera sutil. Un usuario que tenía una cuenta anónima, ¿qué sucede cuando actualiza la aplicación? ¿Los tokens son inválidos? ¿El perfil es accesible? Al aislar este cambio en una versión dedicada, la depuración es simple: si algo se rompe, sé exactamente dónde buscar.

Las versiones pequeñas y frecuentes son mejores que las versiones grandes y raras. Es un principio que he aplicado desde el inicio de TAMSIV, y que me ha evitado muchas noches en vela. Cada "build" es una instantánea comprobable. Cada versión desplegada tiene un alcance claro.

Lo que cambia para los usuarios

En la práctica, el cambio es mínimo para alguien que ya usaba TAMSIV con una cuenta. Nada cambia. Las tareas, las notas, los grupos, todo permanece en su lugar.

Para los nuevos usuarios, la experiencia es diferente pero no necesariamente peor. En lugar de aterrizar directamente en la aplicación, pasan por una pantalla de registro. Correo electrónico, contraseña, listo. Y a partir de ahí, sus datos están seguros, sincronizables en varios dispositivos y recuperables en caso de pérdida del teléfono.

El sistema de autenticación por código QR para la aplicación web ahora funciona para el 100% de los usuarios, no solo para aquellos que se habían tomado el tiempo de crear una cuenta. Es una ganancia concreta en UX para la versión de escritorio.

Las lecciones de un desarrollador en solitario que cambia de opinión

Cambiar de opinión sobre una decisión técnica es incómodo. Escribí un artículo completo sobre los beneficios del registro "lazy". Y hoy hago lo contrario. ¿Es vergonzoso? Un poco. Pero también es la realidad del desarrollo: lo que es óptimo en alfa no es necesariamente óptimo en producción.

En alfa, con 12 probadores reclutados, el anonimato reducía la fricción. En producción, con usuarios reales que esperan que sus datos estén seguros, el registro es un mínimo. El contexto ha cambiado, por lo que la decisión cambia.

Si tú estás construyendo un producto y dudas entre estos dos enfoques, mi recomendación es simple. En el prelanzamiento, el registro "lazy" es genial para validar tu producto. En producción, el registro obligatorio es más sensato. Siempre puedes ofrecer una prueba gratuita generosa para compensar la fricción.

Preguntas frecuentes

¿Los usuarios anónimos existentes pierden sus datos?

Las cuentas anónimas que habían sido migradas a cuentas reales (con correo electrónico) no se ven afectadas. Solo las cuentas que permanecieron puramente anónimas, sin correo electrónico asociado, ya no pueden iniciar sesión. Se planea una limpieza de estas cuentas huérfanas.

¿El registro lleva mucho tiempo?

Dos campos: correo electrónico y contraseña. Sin verificación por SMS, sin captcha, sin formularios largos. El objetivo es permanecer por debajo de los 30 segundos entre la apertura de la aplicación y el primer uso.

¿El error de "flash" modal afectaba la seguridad?

No. Era un problema puramente visual. El modal de los Términos y Condiciones se mostraba brevemente y luego desaparecía. No se exponía ningún dato y las condiciones permanecían aceptadas en la base de datos. Era un defecto de pulido, no de seguridad.