Sí. Tan pronto como la descripción de su aplicación incluye la necesidad de conexión (por ejemplo, un acceso restringido a su equipo), el generador incorpora una gestión real de cuentas, no una única contraseña compartida: el administrador puede crear otros cuentas, con el rol de 'usuario' (que crea, modifica y elimina datos) o de 'solo lectura', cada una con su propio identificador. La creación se realiza desde la pantalla de Ajustes, asignando una contraseña temporal de un solo uso que la persona debe cambiar en su primera conexión.
Qué significa «varios usuarios» en la práctica
Una aplicación generada cuya descripción prevé la necesidad de conexión incluye tres roles distintos: administrador, usuario y solo lectura. El administrador gestiona las cuentas además de usar la aplicación; el usuario crea, modifica y elimina datos igual que el administrador, pero no puede gestionar cuentas; el rol solo lectura permite consultar información sin poder escribir ni modificar nada. Cada persona inicia sesión con su propio identificador, no con una única contraseña compartida por todo el equipo, lo que garantiza que toda acción quede asociada inequívocamente a quien la realizó.
No se trata de una funcionalidad que deba activarse por separado: en cuanto la descripción de tu proyecto implica un inicio de sesión (un acceso restringido a tu equipo, frente a una página pública), la gestión de cuentas forma parte del código que genera Blueprint Maker.
Cómo se crea una cuenta
Desde la pantalla de Ajustes, un administrador introduce un identificador y selecciona el rol (edición o solo lectura), y confirma. La aplicación responde con una contraseña temporal de un solo uso, mostrada una única vez, ni el administrador ni nadie más podrá volver a verla después. La persona la usa para iniciar sesión y debe sustituirla por su propia contraseña en su primera conexión.
Una cuenta puede desactivarse: la desactivación se lleva a cabo en dos pasos (un clic para prepararla y un segundo para confirmarla), nunca mediante un cuadro de diálogo nativo del navegador, que podría bloquear la interfaz bajo ciertas herramientas de automatización. Un administrador no puede desactivar ni su propia cuenta ni la última cuenta activa con rol de administrador: de lo contrario, sería imposible recuperar la gestión de accesos.
Qué impide realmente el rol «solo lectura»
La restricción no es meramente visual. Si una cuenta con rol solo lectura intenta crear, modificar o eliminar datos, incluso saltándose la interfaz mediante una petición API directa, el servidor rechaza la solicitud antes de que se produzca cualquier escritura. No se trata, pues, de un botón oculto: es una protección aplicada a cada llamada, independientemente de cómo se haya originado.
Qué no incluye
Dos limitaciones, expuestas con claridad. En primer lugar, los roles son globales para toda la aplicación: no existen permisos finos por entidad o por sección («este usuario ve los clientes, pero no la facturación»); la opción es únicamente 'modificación' (creación, edición y eliminación de datos) o 'solo lectura', aplicadas a todas las funcionalidades y datos de la aplicación. En segundo lugar, no hay autenticación de dos factores (2FA) en las cuentas de una aplicación generada: la protección prevista consiste únicamente en la contraseña temporal de un solo uso y su renovación obligatoria en la primera conexión, sin ningún segundo factor adicional. Si su actividad requiere permisos más finos o autenticación de dos factores (2FA), dado que el código generado es Next.js y Prisma estándar y exportable, un desarrollador puede integrarlos partiendo de la base ya generada.