Cómo crear un panel de control SaaS sin código, paso a paso

Para crear un panel de control SaaS sin código, define primero quién entra, qué datos ve cada uno y qué decisión toma con ellos. Zugo genera la interfaz a partir de esa descripción, y una base de datos aporta las cuentas y los datos reales. Sin esa conexión, el panel es una maqueta.

La diferencia entre un panel útil y uno decorativo no está en los gráficos. Está en si cada número lleva a una acción concreta y en si cada usuario ve exactamente lo suyo, ni más ni menos.

¿Qué tiene que decidir tu panel antes de generarlo?

Tres respuestas escritas, y el prompt casi se redacta solo. Saltarse este paso es la razón habitual de acabar con seis gráficos bonitos que nadie mira dos veces.

¿Quién entra y con qué papel? Cliente final, administrador de su equipo, y tú como responsable del producto. Cada papel ve pantallas distintas, y mezclarlos obliga a rehacer la navegación entera.

¿Cuál es la métrica que importa? Una principal, dos de apoyo. Un panel con doce indicadores en igualdad de peso no comunica prioridad y se ignora en dos semanas.

¿Qué acción sigue a cada número? Si un dato sube o baja y no hay nada que hacer al respecto, ese dato es un informe, no un panel. La acción puede ser tan simple como un botón para exportar o para escribir a un cliente.

Con eso decidido, el diseño del panel se vuelve una consecuencia. Y si de esas preguntas sale que hay muchos papeles distintos, es señal de que necesitas dos paneles separados y no uno con condiciones por todas partes.

¿Qué capas tiene un panel y quién resuelve cada una?

Un panel es varias piezas trabajando juntas. Verlas separadas evita pedirle al generador algo que no le corresponde.

La fila de permisos es la que más problemas causa cuando se hace mal. Ocultar un botón en la interfaz no protege nada: la regla tiene que impedir el acceso al dato, no solo esconder el enlace. Escríbelo así en el prompt y compruébalo entrando con dos cuentas distintas.

¿Qué prompt genera un panel usable?

El generador acierta cuando nombras pantallas, papeles y datos. Este esqueleto sirve para la mayoría de productos cambiando las métricas.

Crea un panel de control en español para [producto].
Papeles: cliente y administrador.
Pantallas:
1. Entrada: correo y contraseña, recuperar contraseña.
2. Panel del cliente: tarjeta con la métrica principal
   [x] del mes, dos métricas de apoyo, gráfico de los
   últimos 30 días y tabla de los últimos [registros]
   con filtro por fecha y estado.
3. Detalle de registro: todos los campos y las acciones
   [editar, exportar, marcar como resuelto].
4. Ajustes de cuenta: nombre, correo, contraseña, plan.
5. Panel de administrador: lista de clientes, alta y
   baja, y el mismo resumen agregado.
Reglas: cada cliente ve solo sus propios datos, y esa
regla vive en la base de datos, no solo en la interfaz.
Estados vacíos: cuando no hay datos, explicar qué hacer
para tener el primero.
Estilo sobrio, tablas legibles, funciona en portátil.

La línea de estados vacíos ahorra una ronda entera de correcciones. Un panel recién estrenado está vacío por definición, y esa primera pantalla es la que decide si el usuario da el paso siguiente o cierra la pestaña.

¿Cómo se añaden cuentas y datos reales?

El panel empieza a servir cuando alguien entra con su usuario y ve lo suyo. Conectando Supabase obtienes base de datos, cuentas de usuario y almacenamiento de archivos en la misma pieza.

El orden que menos retrabajo genera es: primero cuentas, después datos, después permisos, y al final gráficos. Si empiezas por los gráficos, los harás dos veces, porque la forma de los datos reales casi nunca coincide con la que imaginaste.

Prueba los permisos de forma adversa, no amable. Crea dos cuentas de cliente, mete datos con cada una y comprueba desde la primera que no puedes ver ni modificar nada de la segunda, incluso escribiendo la dirección directa del registro. Si el dato aparece, la regla vivía en la interfaz.

La explicación general de cuentas está en si la IA puede hacer inicio de sesión, y la de la base de datos en la guía de Supabase. Ambas conexiones se piden desde el propio generador, no hay que cablear nada a mano.

¿Cuánto cuesta construirlo?

El plan gratuito da 5 créditos para ver una primera versión. Pro cuesta $25 al mes con 200 créditos. Business son $99 al mes, que es el plan razonable cuando el panel es parte de un producto que factura.

Las acciones tienen precio fijo: generar cuesta 6 créditos, editar cuesta 3 y una aplicación de varias páginas se cobra como plataforma, 12 créditos por las tres primeras páginas y 3 por cada página adicional.

Un panel realista tiene entrada, panel del cliente, detalle, ajustes y panel de administrador: cinco pantallas, 12 créditos por las tres primeras y 6 por las dos siguientes, 18 en total. A partir de ahí, cada refinamiento son 3 créditos.

Como editar es la acción más barata, el patrón eficiente es una generación bien descrita seguida de muchos cambios pequeños: "añade filtro por estado a la tabla", "muestra el porcentaje de cambio junto a la métrica principal", "ordena por fecha descendente". Diez ajustes son 30 créditos, bastante menos que regenerar el proyecto tres veces.

El modo Hi-Fi duplica las cifras, 12 la generación y 6 la edición. En un panel interno rara vez compensa; en uno que ven tus clientes de pago, en la pantalla principal, sí.

¿Cómo se evita que el panel envejezca mal?

Un panel se deteriora por acumulación: cada mes alguien pide un indicador más y en un año hay treinta que nadie mira. Dos hábitos lo evitan.

Una métrica principal por pantalla. Si aparece una segunda candidata, merece pantalla propia. La jerarquía visual es lo que hace que un panel se lea en cinco segundos.

Revisión trimestral de lo que sobra. Quitar un gráfico cuesta lo mismo que añadirlo, 3 créditos, y casi siempre mejora más. Pregunta a quien lo usa qué mira de verdad, no qué le gustaría tener.

Añade también una fecha de actualización visible. Un número sin fecha genera desconfianza en cuanto alguien sospecha que puede estar cacheado, y esa duda vale más que el propio dato.

Vigila además el rendimiento de las tablas largas. Una lista que carga mil filas de golpe se vuelve lenta en cuanto el producto crece, y la solución habitual, paginar o filtrar por defecto, se pide como una edición cualquiera antes de que el problema se note.

¿Dónde se queda corto un generador de IA aquí?

Cuatro límites, dichos claro.

La facturación por uso es un proyecto en sí. Stripe cubre planes y suscripciones. Contar consumo por cliente, prorratear cambios de plan a mitad de mes y conciliar impagos es lógica de negocio que se construye por ediciones, no de un prompt.

Las integraciones con sistemas externos no vienen hechas. Traer datos de tu propia API, de un ERP o de una herramienta de terceros requiere trabajo específico en cada caso.

El tiempo real de verdad es otra liga. Un panel que refresca al abrir la pantalla es directo; uno que se actualiza al segundo, con muchos usuarios a la vez, es un problema de ingeniería.

En producto complejo hace falta equipo. Zugo no sustituye a un equipo de desarrollo cuando hay muchos clientes, auditoría de accesos y datos sensibles. Lo bueno es que el código se exporta a GitHub y el proyecto es tuyo, así que un desarrollador puede continuar desde donde lo dejaste en lugar de empezar de cero.

Para el caso normal, un producto pequeño que necesita que sus clientes entren y vean sus datos con una acción clara, esto es cuestión de una tarde y unos cuantos ajustes. Si además vas a vender planes, la parte comercial se resuelve en la página de precios. Puedes empezar con los créditos gratuitos en zugo.dev.