Cómo construir la app que sostiene el curso 2026/27

La documentación del Club ya define, con distinto grado de detalle, casi todo lo que la app necesita modelar. El trabajo de este estudio no es inventar funcionalidades, sino traducir decisiones ya tomadas en pantallas, datos y una arquitectura concreta — y señalar los huecos que faltan por decidir.

El Club lo explica con una metáfora deliberada: un conservatorio de guitarra. El principiante y el intérprete avanzado entran por la misma puerta y estudian el mismo instrumento — lo que cambia es la profundidad, la autonomía y el acompañamiento, no el club al que pertenecen. Aplicado al Club, eso significa que la app no modela tres productos distintos, sino un único Proyecto Educativo AVANZA con tres modalidades que conviven:

Hay un matiz importante para el diseño de la app: el discurso es "sin jerarquía", pero la estructura de precios es acumulativa. Tribuna es "todo lo incluido en Fórum" más talleres y masterclass; Ágora es "todo lo incluido en Tribuna" más mentorías y proyecto personal. No son modalidades paralelas independientes — son círculos concéntricos con precio creciente (149 / 249 / 399 €/año). Aun así, nadie está obligado a pasar por Fórum y Tribuna antes de apuntarse a Ágora directamente, y cualquiera puede quedarse años en la modalidad que elija.

• Inclusión acumulativa, no niveles paralelos. Para la app esto simplifica el control de acceso: un único campo "modalidad" con una relación de orden (Fórum ≤ Tribuna ≤ Ágora).
• Sin recorrido obligatorio, aunque el precio suba con la modalidad. Se puede entrar directamente en Ágora, o quedarse en Fórum indefinidamente. La app no debe forzar un embudo Fórum → Tribuna → Ágora en el proceso de alta.
• Acceso cruzado sujeto a plazas. Ciertas actividades "podrán abrirse a personas de otras modalidades cuando existan plazas disponibles", con condiciones específicas por definir caso a caso.
• Orientación, no selección. Cuestionario breve y/o entrevista al entrar, sin filtrar a nadie, solo para recomendar modalidad.
• Plazas limitadas por modalidad. Cada modalidad tiene un aforo máximo; al cubrirse, las nuevas solicitudes van a lista de espera y es la Junta Directiva quien valora altas si hay bajas.

La pieza que lo hace posible: la sala de los viernes

El Club dispone hoy de una sala tres horas todos los viernes, con aforo de hasta 100 personas, divisible en dos ambientes independientes, con equipo audiovisual nuevo y tarima. Eso permite sesiones simultáneas — un grupo grabando podcast mientras otro practica al lado, o un espacio reservado para trabajo personalizado de Ágora. La app tiene que representar esto en el calendario como varias sesiones en paralelo, cada una atada a un espacio, no como una sola franja horaria por viernes.

Modalidades acumulativas, no niveles paralelos: Tribuna incluye todo Fórum, Ágora incluye todo Tribuna. Sin recorrido obligatorio — se puede empezar directamente en cualquiera y cambiar cuando se quiera, sujeto a plazas disponibles.

Las tres modalidades

Reglas transversales (aplican a las tres modalidades)

No son features de una modalidad concreta — son mecánicas de negocio nuevas que la app tiene que soportar sí o sí, sea cual sea la modalidad elegida.

Roles de gestión (lado admin, según la Estrategia)

No son "socios": son cuentas internas con acceso al backoffice. La app necesita un segundo eje de permisos para ellas, independiente de la modalidad.

Diez entidades cubren todo lo descrito en los cuatro documentos fuente. No hace falta más para el primer curso.

A · Orientación de entrada nuevo

• Cuestionario y/o solicitud de entrevista — captura experiencia previa, objetivos y disponibilidad; produce un itinerario recomendado, no vinculante.
• La persona confirma o cambia la recomendación antes de darse de alta — coherente con que el Borrador insiste en que "el objetivo no sería seleccionar a nadie".

B · Fórum, Tribuna, Ágora (las tres modalidades)

• Calendario semanal de viernes — 3 horas, 2 espacios en paralelo; cada sesión se reserva por espacio y hora, no solo por día. Aforo total 100, repartible entre ambientes.
• Roles rotativos de sesión (Fórum) — los 7 clásicos: maestro/a de ceremonias, muletillas, cronometrador, lenguaje no verbal, escucha activa, palabra del día, gramática. La app necesita un sorteo/asignación semanal de estos roles, no solo lista de asistentes.
• Talleres y masterclass de Tribuna — todas las sesiones Avanza en Comunidad + 5 masterclass especializadas + talleres específicos; catálogo con fecha, aforo y espacio, en paralelo con Fórum cuando coincidan viernes.
• Proyecto de Ágora — 5 laboratorios Avanza a tu Ritmo + 5 masterclass avanzadas, más el desarrollo y seguimiento de un proyecto personal de comunicación con mentorías, análisis de grabaciones y ensayos asociados a ese objetivo.
• Plazas por modalidad — aforo máximo, lista de espera y pantalla de gestión para que la Junta apruebe altas cuando se libera plaza.
• Dos tarifas por modalidad — precio estándar y precio de inscripción anticipada (antes del 1 de septiembre); el checkout necesita aplicar la tarifa correcta según fecha.
• Ayuda económica confidencial — formulario de solicitud a Tesorería, resuelto caso a caso, visible solo para roles con permiso de Tesorería/Junta.
• Acceso a otra modalidad — cuando una actividad tiene plazas libres, ofrecerla a personas de otras modalidades con condiciones específicas (a definir por actividad).
• Contador de invitado — si la figura de Invitado se mantiene: cada asistencia a Fórum resta del cupo de 3; al agotarse, la app dispara la invitación a pasar por orientación.
• Feedback post-sesión — formulario ligero tras cada intervención.
• Micro Abierto / Avanza y Comunica — calendario de grabaciones, roles del episodio, enlace al vídeo publicado; en Ágora incluye además la coordinación del proyecto de podcast del Club.
• Concurso de Discursos e Improvisados — envío de vídeo candidatura, panel de jurado, y el sistema de votación pública por móvil que Rollo Creativo ya construyó: se integra, no se rehace. Tribuna forma coaches del concurso; Ágora coordina el proceso.

C · Cuenta y membresía

• Alta de invitado sin fricción (nombre + email), sin pago.
• Checkout de cuota anual por modalidad, con tarifa estándar o anticipada, y solicitud de ayuda económica confidencial a Tesorería cuando aplique.
• Cambio de modalidad en cualquier momento del curso — sin tratarlo como un "ascenso", solo como un cambio de recorrido, sujeto a plazas disponibles.
• Voto en asamblea — habilitado solo para socios (no invitados), vinculado a convocatorias puntuales.

D · Backoffice / gestión

• Dashboard de indicadores desglosado por itinerario (no por "nivel"): captación, asistencia, satisfacción, comerciales — los mismos ejes que ya define la Estrategia en su tabla de indicadores clave.
• Calendario editorial del curso, ya redactado mes a mes en la Estrategia (septiembre = diagnóstico, octubre = seguridad y estructura… junio = gala y certificación): la app solo necesita un calendario configurable con esas plantillas precargadas.
• Generación automática de la memoria anual a partir de los datos vivos del curso — cierra el círculo con el propio documento "Memoria del Proyecto Educativo AVANZA" que hoy se redacta a mano.

E · Asistentes IA

Avanzadito (dudas sobre el manual/roles del Club) y Clarita (FAQ de la web) son hoy dos piezas sueltas. Dentro de la app tiene sentido fusionarlas en un único asistente contextual del área privada, con una base de conocimiento común (manual + FAQ + estado real del socio: su nivel, sus próximas sesiones, sus evidencias pendientes) en vez de mantener dos bots con contextos separados.

No es un wireframe pixel a pixel — es la lista mínima que cubre los módulos anteriores, alineada con el sitemap ya aprobado en la Guía Web.

El criterio no es "qué es lo más potente", es qué encaja con lo que ya existe (web propia, votación digital hecha a medida, dos asistentes IA) y con un equipo técnico pequeño apoyado en voluntariado.

La Estrategia ya fija fechas institucionales concretas. La app no necesita un roadmap propio y desconectado — necesita construirse dentro de ese calendario.

Esto es lo que falta por cerrar antes de escribir el control de acceso y el checkout en producción.

• Cómo se gestiona en la práctica la lista de espera por modalidad: ¿orden de llegada, priorización manual de Junta, ambas?
• Criterio y proceso para resolver solicitudes de ayuda económica sin fórmula fija — quién la aprueba, con qué trazabilidad, sin romper la confidencialidad que pide el propio documento.
• Condiciones específicas de acceso a actividades de otra modalidad — el documento dice "podrán establecerse", sin concretar cuáles.
• Si la figura de Invitado (3 visitas gratis al año) sigue vigente — no aparece mencionada en la documentación más reciente.
• Si el Instituto AVANZA / certificación (Estrategia) sigue vigente sobre este modelo, se aparca, o se funde dentro de Ágora.
• Diseño operativo del proceso de orientación: ¿cuestionario, entrevista, o ambos? ¿Quién lo gestiona y con qué SLA de respuesta?
• Nombrar formalmente quién dirige la parte académica del proyecto (tarea que la Estrategia ya marcaba como crítica).

A diferencia del resto del estudio, esto no sale de la Memoria, la Estrategia ni de los borradores del Club — son dos mejoras que Víctor quiere incorporar directamente al desarrollo, ya en marcha (el beta ya tiene tesoreria.js / tesoreria.css). Se documentan aquí como backlog abierto, no como una decisión ya tomada por el Club.

A · Tesorería: alta de tickets/facturas asistida por IA

• Captura — subir una foto o PDF de un ticket/factura desde móvil o escritorio, directamente dentro del módulo de Tesorería.
• Lectura automática — un modelo con visión (p. ej. Claude) extrae importe, fecha, proveedor/concepto y propone una categoría, y crea el apunte sin tecleo manual.
• La IA propone, la persona confirma — el apunte generado queda marcado como "pendiente de revisión" hasta que alguien de Tesorería lo valida. En temas de dinero, la IA no debería ser la única fuente de verdad.
• Edición y borrado — todos los campos del apunte (importe, fecha, concepto, categoría, adjunto) tienen que poder editarse o eliminarse a mano después, haya sido creado por IA o manualmente.
• Encaja con lo ya definido — es un módulo hermano del flujo de ayuda económica confidencial (sección 03): mismo espacio, mismo control de acceso restringido a Tesorería/Junta.
• Nota de arquitectura — con el stack recomendado en la sección 07, esto es Supabase Storage (el adjunto) + una función que llama a la API de Claude con el fichero, sin infraestructura adicional.

B · Mensajería interna entre usuarios

• Alcance mínimo — mensajes 1:1 entre socios, y entre un socio y coordinación/Junta, dentro de la propia app, sin depender de WhatsApp o email externos.
• Alcance ampliado (a valorar más adelante) — canales por modalidad (Fórum/Tribuna/Ágora) o por sesión, para coordinación de grupo.
• Relación con los asistentes IA existentes — puede vivir como un canal más dentro de la misma bandeja donde hoy están Avanzadito/Clarita, o mantenerse separado; a decidir en diseño de producto, no aquí.
• Preguntas abiertas — ¿tiempo real (necesitaría websockets/Supabase Realtime) o bandeja asíncrona tipo email es suficiente para el primer curso; moderación y retención/privacidad de los mensajes.

C · Registro de incidencias (log)

• Qué guarda — tipo de incidencia (técnica, operativa, administrativa), descripción breve, quién la registra, fecha/hora, y opcionalmente a qué afecta (una sesión, un pago, un apunte de Tesorería, una cuenta de socio).
• Por qué encaja aquí — cubre el mismo hueco de trazabilidad que ya señalaba el riesgo de la lista de espera en la sección 10, y hace lo equivalente para los apuntes editables/borrables de Tesorería del punto A: si alguien edita o borra un apunte, debe quedar rastro de qué había antes y quién lo cambió.
• Alcance mínimo — log de solo lectura, visible para quien tenga permiso de administración (Junta/coordinación), sin flujo de resolución tipo ticket.
• Alcance ampliado (a valorar más adelante) — estado abierta/resuelta y asignación a una persona, si se quiere convertir en un pequeño sistema de incidencias en vez de un simple registro.