¿Puede la IA crear el login y las cuentas de usuario?
Sí. Conecta Supabase, pide cuentas de usuario en el prompt y el proyecto generado incluye registro, inicio de sesión, sesión que se mantiene entre páginas y pantallas que solo se ven con la sesión abierta. Lo que no se genera solo es tu certeza de que las reglas de acceso funcionan: eso se prueba.
Esa última frase es la diferencia entre un login que existe y un login en el que se puede confiar. La mayoría del trabajo restante no es escribir el formulario, sino comprobar que la base de datos se niega a devolver las filas de otra persona.
¿Qué incluye "login" en un proyecto generado?
Cuatro piezas distintas que la gente nombra con una sola palabra. Está el registro, que crea la cuenta. Está el inicio de sesión, que la reconoce. Está la sesión, que evita volver a pedir la contraseña en cada página. Y está la autorización, que decide qué puede ver y hacer cada cuenta ya identificada.
Las tres primeras son mecánicas y salen del prompt sin sobresaltos. La cuarta es la que hace correcto tu producto concreto, porque "solo el dueño ve sus pedidos" o "el administrador ve todo y el cliente solo lo suyo" son reglas de tu negocio y nadie las deduce por ti.
Detrás está Supabase, conectado con un conector integrado, que cubre base de datos, acceso y archivos en el mismo sitio. Es útil porque identidad y datos viven juntos: filtrar una consulta por el usuario actual es una función conectada y no dos sistemas que hay que presentar entre sí.
¿Cómo se pide un login en el prompt?
Nombrando los roles y lo que cada uno puede ver, no solo diciendo "con login". Un prompt que pide autenticación sin describir la autorización recibe la puerta, pero deja que la herramienta invente quién tiene llave de cada habitación.
Débil: "una app de proyectos con inicio de sesión". Fuerte: "una app donde cada persona se registra con correo, ve solo los proyectos que ha creado, puede invitar a otras al proyecto, y un administrador ve todos los proyectos y puede borrarlos".
La segunda versión fija roles, propiedad de los datos y una acción compartida. Es probable que necesite ajustes, y ajustar sale barato: la edición cuesta 3 créditos. Reescribir el modelo de permisos cuando ya hay cuentas reales dentro es lo caro, aquí y en cualquier herramienta.
Un detalle que casi nadie escribe y siempre hace falta: qué pasa con quien no ha iniciado sesión. Di explícitamente si una página es pública, si redirige al formulario de acceso o si muestra una versión reducida. Sin esa frase, cada pantalla resuelve la duda a su manera.
Y decide pronto qué ve una cuenta recién creada. Un área privada vacía es la primera pantalla real de tu producto, así que merece una instrucción propia: qué texto aparece, qué botón invita a crear el primer registro y adónde lleva. Es una línea del prompt que evita una edición entera después.
¿Qué hay que probar antes de fiarse?
Esto es lo que separa un login demostrable de uno decorativo. La prueba dura diez minutos y no requiere saber programar.
| Prueba | Cómo se hace | Qué demuestra |
|---|---|---|
| Registro y acceso | Crea una cuenta, cierra sesión, vuelve a entrar | El circuito básico está completo |
| Aislamiento entre cuentas | Crea una segunda cuenta y busca los datos de la primera | Que el filtrado existe de verdad |
| Acceso sin sesión | Abre una URL privada en una ventana de incógnito | Que la página protegida no se sirve a cualquiera |
| Persistencia | Recarga y navega entre páginas | Que la sesión no se pierde al moverse |
| Rol de administrador | Entra con una cuenta normal y busca la pantalla de administración | Que el rol se comprueba en el servidor |
La fila del aislamiento es la importante. Una consulta que filtra por usuario en la interfaz no es lo mismo que una base de datos que se niega a devolver las filas de otro. Si la segunda cuenta ve algo que no debería, la corrección es una edición y hay que hacerla antes de invitar a nadie.
Vale la pena decir qué cubre la verificación previa. Cada construcción se arranca en un entorno aislado antes de entregarse y una que no abre se reporta como fallo. Eso reduce el riesgo de una pantalla en blanco. No dice nada sobre si tus reglas de acceso están bien escritas, que es una pregunta distinta y más importante.
¿Es seguro un login generado por IA?
La respuesta honesta tiene dos mitades, y mezclarlas es lo que produce sorpresas caras. La mitad estructural juega a tu favor: las cuentas y las contraseñas viven en tu proyecto de Supabase, un servicio de identidad hecho para esto, en lugar de en una tabla improvisada dentro de la aplicación.
La mitad que te toca a ti es la autorización. Las reglas que deciden qué fila devuelve la base de datos son configuración de tu proyecto, y son exactamente el punto donde un producto real falla en silencio: todo se ve bien, nadie se queja, y una cuenta puede leer datos ajenos hasta que alguien lo descubre.
Por eso la recomendación práctica es la de arriba: dos cuentas, una ventana de incógnito y curiosidad hostil. Y si el proyecto maneja datos sensibles de terceros, esa revisión merece los ojos de alguien con oficio.
Zugo no sustituye a un equipo de desarrollo en un producto complejo, y la seguridad es donde esa frase pesa más. En si tus datos están seguros se detalla dónde vive cada cosa y quién responde de ella.
¿Cuánto cuesta añadir cuentas al proyecto?
Depende de si el login llega en la primera construcción o después, y la diferencia es pequeña. El precio va por acción, no por complejidad del texto.
| Situación | Acción | Créditos |
|---|---|---|
| Sitio de una página con acceso | Construcción | 6 |
| Plataforma con área privada, tres primeras páginas | Construcción multipágina | 12 |
| Cada página adicional del área privada | Página extra | 3 |
| Añadir cuentas a algo ya construido | Edición | 3 |
| Ajustar permisos o roles | Edición | 3 |
Free incluye 5 créditos una sola vez, menos de lo que cuesta una construcción, así que un producto con cuentas empieza en la práctica en un plan de pago. Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.
Lo razonable es pedir las cuentas desde el primer prompt cuando sabes que el producto las necesita. Añadirlas después funciona, pero suele arrastrar ediciones extra en cada pantalla que ya existía, y cada una de esas ediciones cuesta 3 créditos.
¿Qué pasa cuando el producto crece?
Llega un momento en que el modelo de permisos deja de caber en una frase. Aprobaciones en varios pasos, equipos dentro de equipos, permisos por campo o auditoría de quién vio qué son cosas que se construyen por capas con ediciones, no de un solo prompt.
Cuando ese momento llega, tienes salida. El código se exporta a GitHub, el proyecto es tuyo y un desarrollador trabaja con herramientas normales sin necesitar una cuenta de Zugo. Cómo se hace ese traspaso está en si un desarrollador puede retomarlo después.
Mientras tanto, la ruta corta sigue siendo válida: describe las cuentas y los roles en la primera frase, construye en Zugo, crea dos usuarios de prueba e intenta romper el aislamiento tú mismo antes de que lo haga otro.
La otra mitad del asunto, los datos y sus tablas, está en si la IA puede crear una app con base de datos.