Una web app con login y base de datos sin equipo de desarrollo

La respuesta corta: el agente escribe, tú defines

Hasta hace poco, una web app con login y base de datos significaba contratar al menos a un desarrollador durante algunas semanas, o armar un rompecabezas de herramientas sin código que nunca terminaban de entenderse. Hoy un agente de IA puede escribir la app entera: pantallas, registro, login, área privada, tablas en la base de datos y las reglas de quién ve qué.

Lo que sigue siendo tu trabajo, y lo que decide si el proyecto funciona:

• Quién usa la app y qué tipos de usuario existen.
• Qué ve y qué puede hacer cada uno.
• Qué datos guarda la app y por cuánto tiempo.
• El camino principal, lo que la persona viene a hacer.

Con eso claro, lo demás es conversación.

Sitio o web app: ¿de verdad necesitas login?

Antes de pedir una web app, confirma que no te alcanza con un sitio. Un sitio con formulario resuelve mucho: presupuestos, contacto, inscripciones. El login vale la pena cuando:

• Cada persona necesita ver sus propios datos (pedidos, turnos, documentos, avances).
• Hay acciones repetidas que quedan guardadas (registrar una visita, cambiar un estado, aprobar algo).
• Existen roles distintos, como cliente, empleado y administrador.

Ejemplos típicos para quien vende sitios a pequeños negocios: el portal de clientes de un estudio contable, el control de alumnos de un estudio de yoga, el área del paciente con documentos de una clínica, un sistema simple de órdenes de trabajo para un servicio técnico.

Escribe el pedido como una historia de uso

El agente entiende lenguaje natural, pero un pedido vago da una app genérica. En lugar de "quiero un sistema para mi gimnasio", describe:

1. Quién entra: "Socios y entrenadores. El dueño es administrador."
2. Qué hace cada uno: "El socio ve sus rutinas y marca asistencia. El entrenador carga rutinas para sus socios. El dueño ve todo."
3. Los datos: "El socio tiene nombre, correo, teléfono y plan. La rutina tiene ejercicios, series y fecha."
4. La primera pantalla de cada uno después del login.
5. Lo que nunca puede pasar: "Un socio nunca ve la rutina de otro."

La última línea es la más importante. Las reglas de acceso son donde las apps improvisadas suelen fallar, y escribirlas desde el principio hace que el agente construya la separación en la base de datos y en las rutas, no que solo esconda un botón.

Qué viene listo y qué necesita tu atención

La prueba más valiosa es simple: crea un usuario de cada tipo y usa la app como lo haría él. Intenta abrir la página de otro usuario cambiando la dirección. Si aparece algo que no debería, pide la corrección con ese ejemplo exacto.

Empieza por la app más pequeña que resuelve

La app que se termina es la que empieza pequeña. Un alcance sugerido para la primera versión:

• Un tipo de usuario además del administrador.
• Dos o tres pantallas.
• Una tabla principal.
• Un flujo completo, del registro a la acción principal.

Ponla en manos de tres o cuatro personas reales durante una semana. Lo que pidan es la versión dos. Esto importa todavía más si vendes la app a un cliente: entregar rápido una primera versión útil y cobrar su evolución es mejor para los dos que prometerlo todo de una vez.

Dónde corre la app

Una web app con login necesita un proceso propio en el servidor, a diferencia de un sitio estático. Las opciones comunes:

• Un servidor de apps administrado: no gestionas ninguna máquina, y el límite es el del plan.
• Un VPS: recursos dedicados y control total, con el mantenimiento del servidor a tu cargo.

Para la mayoría de los MVP y portales de pequeños negocios, el administrado alcanza. El VPS tiene sentido cuando la app crece, necesita software específico o el cliente quiere aislamiento.

Cómo hacerlo en Basely

En Basely, las Web Apps las hace el mismo agente del AI Builder:

• Next.js con registro, login, área privada y base de datos Postgres propia para cada app.
• Describes la app conversando; el agente escribe el código, lo revisa en un navegador real y lo publica. Los ajustes también van por conversación.
• El código queda guardado en un repositorio, así que el proyecto es tuyo y te lo puedes llevar.
• Se publica en nuestro servidor, dentro del límite de tu plan de la plataforma, o en un VPS cuando la app lo pida.

Si vendes la app a un cliente, sigue el mismo flujo de ventas que los sitios: propuesta, contrato y el cliente con su propio login en el portal. Y si prefieres la terminal, el Conector deja que Claude Code lea y escriba los archivos de la app y consulte sus datos.

El límite honesto: el agente construye lo que describes. Si las reglas de negocio son complejas o la app maneja datos sensibles, conviene que alguien técnico la revise antes de abrirla al público.

El plan en una página

1. Escribe quién la usa, qué hace cada uno y qué nunca puede pasar.
2. Recórtala a la app más pequeña que resuelve el problema principal.
3. Pídesela al agente y pruébala entrando como cada tipo de usuario.
4. Ponla en manos de pocas personas reales.
5. Mejórala según lo que pidan.

Escribe hoy la historia de uso de tu app y empieza por la primera pantalla.