- Al posponer la implementación del inicio de sesión
→ se acelera la velocidad de desarrollo y se reduce la complejidad del código
→ se reduce la fricción durante el onboarding de usuarios
→ se reduce la superficie de ataque para hackers
→ incluso puede haber ventajas potenciales de SEO
-
Los 2 productos web que el autor llevó al éxito no tenían inicio de sesión
-
El producto en el que está trabajando ahora tiene 50 mil vistas diarias / ingresos mensuales de $2K, pero recién agregó inicio de sesión 4 años después del lanzamiento
13 comentarios
Wow... nunca se me habría ocurrido esta forma de identificar a los usuarios mediante un link único sin iniciar sesión, está bien ingeniosa.
Creo que este side project voy a intentar hacerlo sin login jaja
Para nosotros, la primera función que descartamos desde la etapa inicial fue el registro/inicio de sesión por la carga que implica manejar datos personales. Además de la carga de implementar la funcionalidad, nos resultaba pesado porque no teníamos personal para operar el servicio ni para procesar datos personales. Aunque pensamos bastante en las funciones y comodidades que se pueden ofrecer después del inicio de sesión, al final decidimos quitarlo y estamos avanzando así en esta primera etapa.
Sí, creo que es una excelente decisión. Si se da la oportunidad, ¡presenta también el producto que estás creando en Show GN! jaja
Incluye posibles beneficios de SEO -> parece que hay un error tipográfico en esta parte
Ups, sí, ya lo corregí rápido ;)
Nuestro producto en la empresa empezó sin inicio de sesión y creció bien, pero después, cuando el producto evolucionó hasta necesitar inicio de sesión, nos costó lograr que los usuarios lo adoptaran. Parece que, según el producto, es una opción que se puede elegir.
Sí, parece que la clave es guiar más adelante al usuario hacia el inicio de sesión de forma natural. Estaría bueno que se compartieran más casos como este.
No estoy seguro de si la función de inicio de sesión, incluyendo OAuth2, también podría estandarizarse hasta cierto punto como una especie de plantilla.
Me parece que con solo OAuth2 ya podría reducirse bastante la carga del onboarding de usuarios.
¿Cuando se habla de reducir la superficie de ataque para hackers, podría entenderse como que, al no contener información de cada persona, desde el principio prácticamente no habría nada que hackear?
Al ver que en el original dice “Evil-doers are much less likely to break into your house if there is nothing of value inside”, queda claro que el sentido correcto es que, como no hay nada que robar, es más seguro.
Gracias. No había podido revisar el original, pero ahora queda claro.
Sí, probablemente se refería a esa parte porque quizá hay que enviar algo al servidor o guardar contraseñas, ese tipo de cosas.
Yo tampoco creo que sea una gran carga del lado del desarrollo hoy en día, porque hay muchas cosas como Passport.js que ya hacen todo eso.
Pero cuando hay un ID, sí termina entrando mucho más trabajo de planificación del servicio. Hacer que se puedan probar las funciones incluso sin ID parece mucho mejor para generar tracción de usuarios al inicio. En lo personal, incluso me incomoda iniciar sesión con OAuth en sitios recién creados. ^^;
Ahora que lo escucho, OAuth también termina siendo una forma de esparcir mi información personal. Yo ya me lo tomo con mucha calma...;;;
Esto dependerá del producto que se esté creando, pero...
si es un servicio que realmente no necesita inicio de sesión, creo que lo correcto es excluir esa función, desarrollarlo y lanzarlo rápido, y luego agregarla. Me parece que en nuestro país los servicios piden demasiada información personal innecesariamente.
Si agrego una cosa más... en el artículo dicen que ni siquiera se debe guardar el correo electrónico, pero creo que al menos una dirección de correo debería pedirse como opcional para notificaciones de funciones o envío de boletines.