Constructor de apps con IA y Supabase: base y acceso
Sí, Supabase se conecta como integración estándar y resuelve tres cosas a la vez: base de datos, acceso de usuarios y almacenamiento de archivos. Es el conector que convierte un sitio web en una aplicación. El proyecto sigue siendo tuyo y los datos viven en tu proyecto de Supabase, no dentro del constructor.
Esa última frase es la que cambia el cálculo de riesgo, así que el resto del artículo trata de cuándo hace falta una base de datos y cómo describirla para que salga bien a la primera.
¿Cuándo necesita tu proyecto una base de datos?
No siempre. Una parte considerable de los proyectos se resuelve sin ella, y conectarla por si acaso añade complejidad justo en la fase en la que menos conviene.
No hace falta base de datos si el contenido cambia poco y lo controlas tú entero: una tarjeta de presentación, una página de aterrizaje, un portafolio, la web de un evento. Ese proyecto se construye más rápido, se rompe menos y se actualiza con una edición.
Sí hace falta en cuanto aparece uno de estos tres casos. Primero: los visitantes crean contenido, es decir envían solicitudes, dejan registros o suben archivos. Segundo: distintas personas tienen distinto acceso, o sea hace falta login. Tercero: los datos deben sobrevivir a una recarga de página y quedarse para siempre.
Una prueba rápida: si no sabes responder a "¿dónde estará esto mañana?", necesitas base de datos. Si el contenido vive dentro del propio proyecto y lo cambias tú, todavía no.
¿Qué aporta exactamente la integración?
| Necesidad | Qué aparece en el proyecto | Ejemplo típico |
|---|---|---|
| Guardar datos | Tablas donde el proyecto escribe y lee | Solicitudes, reservas, productos, tareas |
| Acceso de usuarios | Registro, inicio de sesión y área privada | Portal de cliente, acceso a materiales |
| Separación de datos | Cada persona ve solo lo suyo | Un gestor de tareas con lista personal |
| Archivos | Subida y almacenamiento de imágenes y documentos | Portafolio, contratos, fotos de perfil |
| Roles | Permisos distintos para usuario y propietario | El administrador ve todas las reservas, el cliente solo las suyas |
La fila clave es la tercera. "Cada persona ve solo lo suyo" no es un detalle de presentación, es un requisito sobre los datos, y hay que nombrarlo en la descripción de forma explícita. Un proyecto donde la lista de tareas es común a todos los usuarios y otro donde es personal no se diferencian por su aspecto, sino por sus reglas de acceso.
De ahí sale una consecuencia práctica: describe no solo las entidades, sino quién ve qué. Sale mucho más barato que descubrirlo cuando ya hay datos ajenos en la base.
¿Cómo describir los datos en el prompt?
El modelo traduce bien las descripciones concretas y adivina mal lo que se da por supuesto. Funciona un esquema de tres partes: quién lo usa, qué se guarda y quién ve qué.
Descripción floja: "un servicio para reservar citas". De ahí no se deduce casi nada.
Descripción sólida: "Servicio de reservas para un salón. El cliente se registra con correo, elige profesional, servicio y hora, ve solo sus propias reservas y puede cancelarlas con al menos un día de antelación. El profesional entra con su cuenta y ve su agenda de la semana. La propietaria ve todas las reservas y puede añadir o quitar profesionales."
Hay tres roles, un conjunto de campos y una regla de acceso. Con eso el resultado es previsible en lugar de una sorpresa.
Después funciona el ciclo de ediciones. Cada edición cuesta 3 créditos, y afinar la estructura de datos suele llevar varias iteraciones: miras el resultado, detectas el campo que falta y lo añades. Es el proceso normal, no una señal de error.
El consejo que más ahorra: cierra la estructura de datos antes de que la base tenga registros reales. Renombrar una tabla en la primera semana es barato; en el sexto mes es caro.
¿Qué errores de estructura salen más caros?
Cuatro se repiten, y todos son baratos la primera semana y caros a los seis meses.
Un campo donde deberían ir tres. "Dirección" en una sola línea es cómodo de escribir e imposible de filtrar. Si algún día querrás ver pedidos por ciudad, la ciudad tiene que ser un campo propio desde el principio.
La relación con el usuario olvidada. Los registros guardados sin indicar de quién son no se pueden separar después. Es exactamente el fallo por el que una persona acaba viendo los datos de otra, y se descubre en el peor momento.
Estados escritos en texto libre. Si el estado de un pedido se guarda como texto, en un mes tendrás "pagado", "Pagado" y "pago recibido", y ningún filtro los juntará. Enumera los valores permitidos en la propia descripción.
Borrar en lugar de marcar. Un pedido borrado desaparece de la estadística y del histórico. Muchas veces es mejor marcarlo como cancelado y dejarlo en la base.
Y una costumbre que no es un error: pon una fecha de creación en cada entidad. No cuesta nada y responde a la mitad de las preguntas futuras sobre qué pasó y cuándo.
¿Cómo encaja Supabase con las demás integraciones?
| Integración | De qué se ocupa |
|---|---|
| Supabase | Datos, acceso de usuarios y archivos |
| Stripe | Dinero: pagos únicos y suscripciones |
| Resend | Correos que envía el proyecto |
| GitHub | Código fuente en tu repositorio |
| Vercel | Despliegue en tu cuenta de hosting |
| Google Analytics | Estadísticas de visitas |
| Dominio propio | Dirección permanente del proyecto |
Un producto con usuarios y con dinero se apoya normalmente en las tres primeras filas a la vez: la persona entra con Supabase, paga con Stripe y recibe la confirmación con Resend. Es la combinación típica y conviene planificarla entera, no conectarla de una en una según van apareciendo los problemas.
La fila de GitHub responde a la pregunta de la independencia. El código sale a tu repositorio y los datos viven en tu proyecto de Supabase, y juntas ambas cosas significan que el producto no desaparece con la suscripción.
¿Cuánto cuesta esto?
Conectar la integración no gasta créditos. Supabase es un servicio externo con sus propias condiciones y no se paga a través de Zugo.
Los créditos se van en generar. Una construcción cuesta 6 créditos, una edición 3, una plataforma multipágina 12 por las tres primeras páginas y 3 por cada adicional. El modo Hi-Fi cuesta el doble: 12 la construcción y 6 la edición. El plan gratuito da 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.
Un proyecto con base de datos y acceso casi siempre es una plataforma multipágina y no una sola página. Presupuesta con ese número: 200 créditos son 16 plataformas completas, y cada una suele necesitar además varias ediciones de ajuste.
¿Cómo probar un proyecto con login antes de lanzarlo?
Una aplicación con usuarios se prueba distinto que un sitio informativo. Pasa por estos cinco escenarios y encontrarás la mayoría de los problemas antes que un desconocido.
Dos cuentas a la vez. Abre el proyecto en una ventana normal y en otra privada, entra con usuarios distintos y comprueba que cada uno ve solo lo suyo. Es la única prueba que no se puede sustituir por razonamiento.
Salir y volver a entrar. Los datos deben seguir ahí y no desaparecer con la sesión. Si algo se perdió, es que no vivía en la base.
El enlace ajeno. Copia la dirección de una página que ve el primer usuario y ábrela con el segundo. Si se abre contenido ajeno, las reglas de acceso están incompletas.
El estado vacío. Qué ve alguien que acaba de registrarse y todavía no ha creado nada. Una pantalla vacía sin indicación es la causa más común de abandono en el primer paso.
La recuperación de acceso. Olvidar la contraseña le pasa a todo el mundo, y el camino de vuelta tiene que funcionar antes del lanzamiento.
La comprobación en entorno de pruebas confirma que el proyecto arranca y reduce el riesgo de pantalla en blanco. No pasa por estos cinco escenarios: esa parte es tuya y ocupa unos veinte minutos.
¿Dónde están los límites honestos?
Tres cosas que conviene decir sin rodeos.
La estructura de datos generada es un buen borrador, no un modelo definitivo. Revísala tú mientras haya pocos registros, sobre todo si el proyecto va a crecer en una dirección que no mencionaste en la primera descripción.
Las reglas de acceso merecen una revisión aparte. Cualquier aplicación con datos personales, la haya hecho una persona o un constructor, exige responder a quién puede leer qué. Compruébalo antes de que haya datos ajenos en la base.
Zugo no sustituye a un equipo de desarrollo en un producto complejo. La lógica de negocio muy específica se afina con ediciones sucesivas, y en algún momento sale más barato exportar el código y continuar a mano.
¿Qué hacer ahora?
Empieza por una descripción con el esquema "quién, qué se guarda, quién ve qué", construye la primera versión y mira la estructura de datos antes de meter registros reales. Después afina con ediciones.
Para el resto del montaje, puede la IA construir un login entra en la parte de cuentas, puede la IA construir una app con base de datos amplía el lado de los datos y constructor de apps con IA y GitHub explica la salida del código. Puedes montar un proyecto con base y acceso en zugo.dev: hay 25 plantillas listas, 5 de ellas de juegos, y empezar desde una estructura existente es más rápido que desde una página en blanco.