Cómo crear un tablero kanban sin código, paso a paso

Para crear un tablero kanban sin código, nombra tus columnas, enumera los campos que lleva una tarjeta y explica qué debe ocurrir al arrastrarla de una columna a otra. Conecta Supabase para que el tablero sobreviva a un refresco. Una construcción de una página cuesta 6 créditos y tarda alrededor de un minuto.

Antes de nada, lo honesto: Trello, Linear y Notion existen, son buenos y son gratis para equipos pequeños. Construir el tuyo solo tiene sentido en unos pocos casos, y esta guía empieza nombrándolos en lugar de fingir que las herramientas generales son malas.

¿Cuándo conviene un tablero propio en lugar de Trello?

Cuando la tarjeta no es una tarea. Los equipos que siguen candidaturas, reparaciones, pedidos, expedientes o piezas de contenido acaban doblando una herramienta de tareas hasta una forma que se resiste, y cada campo improvisado cuesta atención para siempre.

El segundo caso es el cálculo. Si la tarjeta necesita mostrar un importe, un margen o los días que lleva parada, y ese número debe salir de otros campos, las herramientas generales te obligan a mantenerlo a mano. Un tablero propio lo calcula.

El tercero es quién mira. Cuando el tablero tiene que estar en tu web, con tu marca, y verlo un cliente sin crear cuenta en una herramienta ajena, la funcionalidad importa menos que el contexto donde vive.

Fuera de esos tres casos, la respuesta sincera es usar Trello. Un tablero genérico hecho a medida no gana nada frente a uno que ya tiene aplicación móvil, notificaciones y quince años de detalles resueltos.

¿Qué hay que decidir antes de escribir el prompt?

Tres cosas, y ninguna es técnica. Decidirlas mal cuesta ediciones, y cada edición son 3 créditos.

Las columnas son el error clásico. Un tablero con diez estados obliga a decidir dónde va cada elemento en lugar de trabajar, y en la práctica todo el mundo lo deja atascado en la tercera. Si dudas entre dos estados, únelos y añade una etiqueta.

Sobre los campos visibles, la prueba es la distancia: si el tablero no se entiende desde un metro de la pantalla, hay demasiado texto en las tarjetas. Lo demás vive dentro de la tarjeta, no en la portada.

¿Qué prompt genera el tablero?

Describe los datos y el comportamiento, no los colores. El aspecto se ajusta luego; la estructura mal planteada se arrastra.

Crea un tablero kanban para seguir reparaciones de un taller.
Columnas: Recibido, Diagnóstico, Esperando pieza, En reparación,
Listo para recoger.
Cada tarjeta lleva: cliente, teléfono, equipo, avería descrita,
fecha de entrada, presupuesto aprobado (sí/no), importe.
La tarjeta muestra en portada: equipo, cliente y días desde la
fecha de entrada. Si pasa de siete días, se marca en rojo.
Al arrastrar una tarjeta, guarda la nueva columna y la fecha
del cambio.
Botón para crear tarjeta con un formulario de esos campos.
Buscador por cliente o por teléfono.
Guarda todo en base de datos.

Dos frases hacen el trabajo pesado. "Días desde la fecha de entrada" convierte el tablero en un detector de atascos en lugar de un archivo. "Guarda todo en base de datos" es lo que impide el resultado más decepcionante posible: un tablero precioso que se vacía al recargar la página.

¿Cómo se consigue que el tablero no se borre al recargar?

Con Supabase. Sin base de datos, el tablero vive en la memoria del navegador y desaparece con el refresco, que es exactamente lo que nadie quiere descubrir después de meter cuarenta tarjetas.

La conexión aporta tres cosas a la vez: la tabla donde viven las tarjetas, el inicio de sesión para que cada persona entre con su cuenta y el almacenamiento de archivos si las tarjetas llevan fotos o presupuestos adjuntos. Los pasos concretos están en la guía de Supabase.

Merece la pena pedir desde el principio que cada movimiento de tarjeta guarde también la fecha. Es una línea más en la tabla y te da, sin trabajo extra, el dato que después querrás: cuánto tiempo pasa un elemento en cada columna.

Y una advertencia práctica: si varias personas van a mover tarjetas a la vez, pruébalo con dos navegadores abiertos antes de darlo por bueno. La actualización en vivo entre usuarios se pide de forma explícita, no viene sola.

¿Cuánto cuesta y cuánto tarda?

Un tablero es una construcción de una sola página, es decir 6 créditos, y se genera en alrededor de un minuto. Si además quieres una página de informes y otra de configuración, pasa a ser una plataforma multipágina: 12 créditos por las tres primeras páginas y 3 por cada página adicional.

Las ediciones son donde se va el presupuesto real, y cada una cuesta 3 créditos. Ajustar qué se ve en la tarjeta, cambiar el umbral de días, añadir un filtro por responsable: quince ediciones son 45 créditos, y quince ediciones es una estimación realista para un tablero que vas a usar de verdad.

Con el plan gratuito, que trae 5 créditos, no llegas ni a la primera construcción de una página, así que sirve para mirar y poco más. Pro cuesta 25 dólares al mes con 200 créditos, suficiente para el tablero y varias semanas de retoques. Business cuesta 99 dólares al mes.

Antes de entregártelo, el proyecto se arranca en un entorno aislado, y una construcción que no abre se reporta como fallo en lugar de entregarse en blanco. Eso reduce el riesgo, no lo elimina: comprueba tú mismo que arrastrar una tarjeta la deja donde la soltaste después de recargar.

¿Qué informes salen del propio tablero?

Tres, y todos dependen de haber guardado la fecha de cada movimiento. Sin ese dato, el tablero solo sabe dónde está cada cosa hoy; con él, sabe cómo llegó hasta ahí.

El primero es el tiempo medio por columna. Responde a la pregunta que todo el mundo discute sin datos: dónde se atasca el trabajo. Casi siempre la respuesta sorprende, porque el cuello de botella real rara vez es la columna donde más tarjetas se acumulan.

El segundo es el número de elementos terminados por semana. Es la única medida de capacidad que no se puede discutir, y sirve para prometer plazos con fundamento en lugar de con optimismo.

El tercero es la lista de tarjetas paradas más de X días. No es una estadística, es una lista de acciones pendientes, y es el informe que de verdad se mira cada mañana.

Pedir estos tres como una segunda página convierte el proyecto en una plataforma multipágina, con lo que el coste pasa a 12 créditos por las tres primeras páginas. Vale la pena solo cuando el tablero ya se usa a diario.

¿Qué no va a salir de un solo prompt?

Cuatro cosas, todas conocidas de antemano.

Notificaciones y avisos. Que una tarjeta atascada avise por correo requiere conectar Resend y describir la regla. Es alcanzable, pero es un paso aparte, no un efecto secundario del tablero.

Permisos finos por persona. "El técnico ve solo sus tarjetas y el jefe las ve todas" es lógica de acceso, y se afina con ediciones sucesivas y reglas en la base de datos. Merece una prueba deliberada con dos cuentas reales.

Aplicación móvil nativa. El tablero funciona en el navegador del teléfono, y arrastrar con el dedo se puede pedir, pero no es una aplicación de la tienda. Si el uso principal es en movilidad, tenlo en cuenta al elegir columnas: menos y más anchas.

Un producto complejo necesita equipo. Zugo no sustituye a un equipo de desarrollo cuando el tablero se convierte en el sistema central de una empresa con integraciones, auditoría y permisos por rol. Cuando llegue ese punto, la exportación a GitHub te deja el código en tu repositorio.

Para un equipo pequeño que necesita seguir algo que no encaja en una herramienta de tareas, el tablero propio se sostiene bien. Si lo que quieres es cobrar por el acceso a esa herramienta, sigue por cómo montar un sitio de membresía; si tu caso es coordinar trabajo con clientes externos, mira cómo se plantea un portal de empleo, que resuelve el mismo problema de formularios y estados. Cuando tengas las columnas escritas en una servilleta, descríbelas en zugo.dev.