¿Puede la IA crear una app con base de datos? Guía real
Sí. Describe qué guarda la aplicación y quién lo lee, conecta Supabase y el código generado crea las tablas, los formularios que escriben en ellas y las listas que las leen de vuelta. Una plataforma así cuesta 12 créditos por las tres primeras páginas y 3 por cada página adicional.
Lo interesante no es si aparecen las tablas. Es si el modelo de datos describe bien tu negocio, porque un modelo equivocado es el único error que se encarece cada semana que sigues usando la aplicación.
¿Qué significa realmente "una app con base de datos"?
Detrás de esa frase se esconden cuatro cosas distintas, y se generan con niveles de confianza diferentes. Está el esquema, es decir las tablas y sus relaciones. Están las escrituras: formularios y acciones que guardan. Están las lecturas: listados, filtros y fichas. Y están las reglas de acceso que deciden quién ve qué fila.
Zugo genera las cuatro a partir de una descripción. Las tres primeras son mecánicas: dado "cada cliente tiene varios pedidos y cada pedido tiene un estado", las tablas y las pantallas salen solas. La cuarta es donde un negocio concreto se vuelve concreto, y donde conviene frenar y revisar el resultado con tus propios ojos.
La base de datos es Supabase, conectada mediante un conector integrado. Eso significa Postgres real con tablas reales, no un almacén de juguete escondido dentro de la página. Puedes abrir el panel de Supabase y mirar tus filas, que además es la forma más rápida de confirmar que un formulario guardó algo de verdad.
¿Qué tipo de aplicaciones salen bien?
Casi todas comparten la misma forma: registros y personas que actúan sobre ellos. Eso cubre más terreno del que parece.
| Aplicación | Qué guardan las tablas | Dónde está la dificultad real |
|---|---|---|
| CRM sencillo | Contactos, empresas, oportunidades, notas | Las etapas del embudo y quién posee cada trato |
| Control de inventario | Artículos, ubicaciones, movimientos | Cuadrar existencias cuando dos personas editan |
| Sistema de reservas | Servicios, huecos, reservas | Evitar la reserva doble del mismo hueco |
| Portal de clientes | Clientes, proyectos, archivos | Que cada cliente vea solo sus propias filas |
| Directorio interno | Personas, equipos, competencias | Casi ninguna, buen primer proyecto |
| Cola de soporte | Tickets, mensajes, estados | Reglas de asignación y avisos |
La columna de la derecha es la honesta. Generar las tablas es la mitad fácil en todas las filas. La regla que hace que la aplicación sea correcta y no solo funcional suele ser una frase de lógica de negocio, y es justo la frase que la mayoría de los prompts omite.
¿Cómo se describe un modelo de datos en el prompt?
Nombra los sustantivos, luego las relaciones y por último quién lee qué. Un prompt que describe un negocio sin describir sus datos deja que el generador invente el esquema, y los esquemas inventados son el origen del trabajo repetido.
Débil: "una app para gestionar mis clientes". Fuerte: "una app donde cada cliente tiene nombre, correo y empresa, cada cliente tiene varios proyectos, cada proyecto está en estado nuevo, activo o terminado, y un usuario identificado solo ve sus propios clientes".
La segunda versión fija las tablas, la relación, los valores permitidos y la regla de acceso. Es probable que aún necesite ajustes, pero serán cosméticos en lugar de estructurales. Reorganizar un modelo de datos cuando ya tiene filas reales dentro es la corrección más cara que existe, en cualquier herramienta.
Hay una costumbre más que conviene adoptar: di qué debe pasar en los bordes. ¿Y si dos personas reservan el mismo hueco? ¿Y si se borra un cliente cuyos proyectos siguen apuntando a él? Esas respuestas son reglas que nadie puede deducir, y nombrarlas en el primer prompt sale más barato que descubrirlas en producción.
¿Cuánto cuesta en créditos una app con datos?
La aritmética es predecible porque el precio va por acción, no por tokens ni por tamaño del texto.
| Acción | Créditos |
|---|---|
| Construcción de un sitio, app o juego | 6 |
| Plataforma multipágina, tres primeras páginas | 12 |
| Cada página adicional | 3 |
| Edición sobre un proyecto existente | 3 |
| Construcción en modo Hi-Fi | 12 |
| Edición en modo Hi-Fi | 6 |
Una app con datos casi siempre es una plataforma multipágina, porque el listado, la ficha y el formulario son pantallas distintas. Seis páginas salen por 12 créditos más tres páginas extra, o sea 21 créditos en total.
El plan Free incluye 5 créditos una sola vez, menos de lo que cuesta una construcción, así que una app con datos empieza de hecho en un plan de pago. Pro cuesta $25 al mes con 200 créditos. Business cuesta $99 al mes. Reserva presupuesto para ediciones: estas aplicaciones se afinan más de lo que se escriben, y 200 créditos dan 66 ediciones si solo las gastas en eso.
¿Puede gestionar el acceso y los datos por usuario?
Sí, y en la mayoría de las apps con datos no es opcional. Supabase cubre base de datos, autenticación y almacenamiento de archivos con el mismo conector, así que "identifica a la persona y muéstrale solo sus filas" es una función conectada y no dos sistemas que hay que presentar entre sí.
La aplicación generada puede crear cuentas, iniciar sesión, mantener la sesión entre páginas y filtrar las consultas por el usuario actual. Combinado con Stripe, la misma estructura sostiene un producto de pago donde la ficha de cuenta muestra lo que esa persona compró.
Lo que merece tu propia comprobación es si el filtrado se aplica de verdad o solo se aplica en la interfaz. Crea una segunda cuenta, entra con ella e intenta llegar a los datos de la primera.
El detalle de esa prueba está en si la IA puede crear login y cuentas, y la puesta en marcha del conector, en la guía de Supabase.
¿Es fiable el trabajo de base de datos que genera?
En parte por diseño y en parte bajo tu responsabilidad, y aquí la distinción importa más que en ninguna otra parte del proyecto.
Por diseño: los datos viven en tu proyecto de Supabase, en tu cuenta, con un panel que controlas tú. Nada en ese montaje te esconde tus propias filas, y puedes inspeccionarlas, exportarlas o respaldarlas sin pedirnos permiso.
Bajo tu responsabilidad: las reglas de acceso. Una consulta que filtra por usuario en la página no es lo mismo que una base de datos que se niega a devolver las filas de otro. Revisa las reglas, prueba con una segunda cuenta y trata el "se ve bien en pantalla" como el principio de la comprobación, no como el final.
La verificación previa cubre algo más estrecho de lo que se suele suponer. Cada construcción se arranca en un entorno aislado antes de entregarse, y una que no abre se reporta como fallo en lugar de entregarse igualmente. Eso reduce el riesgo de recibir una pantalla en blanco. No lo elimina, y no dice nada sobre si tu esquema modela bien tu negocio.
¿Dónde se detiene la IA?
En tres puntos previsibles, ninguno de ellos secreto.
La lógica muy específica llega por ediciones. Matrices de permisos poco comunes, cadenas de aprobación en varios pasos y reglas con casos límite se construyen por capas, no de un solo prompt. Por eso la edición es la acción más barata.
La migración de datos existentes es tuya. Meter ocho años de hojas de cálculo en un esquema nuevo es un trabajo de criterio sobre tus datos, no un trabajo de generación.
El crecimiento acaba pidiendo un desarrollador. Zugo no sustituye a un equipo de desarrollo en un producto complejo. Cuando la aplicación sostiene un negocio real, exporta el código a GitHub y entrega un repositorio de verdad a alguien que lo revise. El proyecto es tuyo, así que esa puerta está siempre abierta, tal como se explica en si un desarrollador puede retomarlo después.
El plan sensato es construir la versión pequeña primero, meterle filas reales y dejar que la fricción te diga qué se equivocó el modelo. Puedes empezar en Zugo con un prompt que nombre tus sustantivos, tus relaciones y quién puede ver qué.