AIRSPACE Especificación Funcional para Cotización El servicio de coordinación y participación para skydiving Documento dirigido a: equipos de desarrollo software e IA Propósito: base para estimación de esfuerzo y propuesta económica Versión: 1.0 Fecha: Abril 2026 Control de versiones --------- ------------ -------------------------- ----------------------------------------------------------- Versión Fecha Autor Cambios 1.0 Abril 2026 Equipo Producto AIRSPACE Versión inicial entregable a proveedores para cotización. --------- ------------ -------------------------- ----------------------------------------------------------- Cómo leer este documento Este documento describe el alcance funcional y técnico de la versión 1 (V1) de AIRSPACE, junto con las fases sucesivas previstas. Está diseñado para que un proveedor de desarrollo software, un proveedor de IA, o un equipo mixto, puedan emitir una cotización fundamentada con un margen de incertidumbre razonable. - Secciones 1–3: contexto, alcance y supuestos. Necesarias para entender el problema y los límites del proyecto. - Secciones 4–5: actores, roles, casos de uso y flujos. Base para estimar el esfuerzo de UX y producto. - Secciones 6–11: módulos funcionales detallados. Base principal para la estimación de desarrollo. - Secciones 12–14: modelo de datos, integraciones y arquitectura indicativa. Para el dimensionamiento backend. - Secciones 15–16: componente de IA. Cotizable de forma separada. - Secciones 17–20: requisitos no funcionales, criterios de aceptación, entregables y estructura de la cotización solicitada. 1. Contexto y objetivos del producto 1.1 Qué es AIRSPACE AIRSPACE es un servicio mobile-first de coordinación y participación específicamente diseñado para la comunidad de skydiving. Ayuda a saltadores (jumpers) a descubrir actividad local en drop zones, encontrar coaches disponibles, descubrir eventos y aplicar a ellos; y proporciona a coaches y organizadores las herramientas estructuradas para gestionar esa participación. AIRSPACE no es una red social, no es un directorio, y no es una plataforma genérica de eventos. Es un servicio vertical construido alrededor de cómo realmente se toman las decisiones de participación en este deporte. 1.2 Problema que resuelve Hoy la coordinación en skydiving está fragmentada entre WhatsApp, Instagram, hojas de cálculo, formularios sueltos y boca a boca. Esto produce cuatro costes operativos: - Oportunidad invisible: jumpers se pierden eventos y slots de coaching porque no saben que existen. - Coordinación ineficiente: coaches y organizadores dedican horas a logística por canales informales. - Confianza inconsistente: no hay forma portable de establecer o verificar credibilidad. - Participación dependiente de redes personales: el acceso a las mejores oportunidades está limitado por a quién ya conoces. 1.3 Objetivos funcionales del V1 1. Permitir que un jumper descubra actividad relevante (DZ activa, coaches disponibles, eventos próximos) sin depender de canales informales. 2. Permitir que un coach publique disponibilidad estructurada vinculada a lugar y fecha, y reciba solicitudes. 3. Permitir que un organizador cree eventos con capacidad, requisitos y aplicación, y gestione el ciclo de vida de las solicitudes. 4. Servir como única fuente de verdad para el estado de las aplicaciones en un contexto real de evento. 5. Soportar usuarios con doble rol (jumper y coach simultáneamente) sin fricción. 6. Operar con un modelo de datos preparado para que las capas de IA y monetización del Phase 2/3 se construyan sin reingeniería. 1.4 Lo que el V1 explícitamente no hace - Pagos in-platform y lógica de payout (V1 sólo enlaza a pasarelas externas). - Integración profunda con sistemas operativos de DZ (manifest, registros de seguridad, jump logging). - Sistema de reputación pública avanzado, feedback 360 estructurado, ranking de coaches. - Permisos de equipo profundos más allá de eventos multi-manager básicos. - Analítica avanzada y herramientas de exportación. - Mecánicas de feed social o compartición de fotos/vídeos como red social pública (la zona social — "Fan Zone" — se trata como módulo opcional, ver sección 11). 2. Alcance del proyecto a cotizar 2.1 Plataformas objetivo - Aplicación móvil iOS (iPhone, iOS 16+). Aplicación nativa o framework cross-platform — el proveedor debe justificar su elección. - Aplicación móvil Android (Android 11+). Misma decisión técnica que iOS. - Backend / API REST o GraphQL, multi-tenant lógico (no multi-tenant físico), preparado para escalar horizontalmente. - Panel web de administración para roles de plataforma (claims, verificación, moderación). No es panel de cliente; es interno. - Panel web ligero para Coaches y Organizadores (opcional V1, recomendado V2): permite operaciones que son más cómodas en escritorio (revisión masiva de aplicaciones, edición de eventos largos). 2.2 Tres bloques que se cotizan separadamente Para que la propuesta sea comparable entre proveedores, se solicita cotización separada de los tres bloques siguientes: -------- ---------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Bloque Contenido Por qué se separa A V1 Pilot — App móvil + Backend + Admin Es el alcance mínimo viable para lanzar piloto en 3–5 drop zones. Debe estimarse de forma firme. B Componente de IA Reconocimiento de nivel a partir de vídeo, recomendaciones, copilot de organizador. Cotización separada porque puede ir a un proveedor especializado distinto, y porque algunas piezas son Phase 2. C Phase 2 — Profundidad de plataforma Pagos in-platform, herramientas de equipo, analítica, verificación avanzada. Estimación indicativa, no firme. Sirve para validar que la arquitectura del Bloque A no bloquea el crecimiento. -------- ---------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2.3 Fuera de alcance de esta cotización - Diseño gráfico de marca (logo, identidad visual). Se entregará al proveedor. - Estrategia comercial, captación de DZs piloto y onboarding de coaches iniciales. - Producción de contenido (fotos/vídeos de marketing). - Hosting de producción a largo plazo (se cotiza setup y primer año; renovaciones aparte). 3. Supuestos y restricciones 3.1 Supuestos de negocio - El piloto V1 se lanza en 3–5 drop zones seleccionadas. Volumen estimado piloto: 500–2.000 jumpers activos, 50–150 coaches, 20–60 eventos en los primeros 6 meses. - Idiomas iniciales: español e inglés. Arquitectura preparada para añadir más sin retrabajo. - Mercado inicial: Europa y EEUU. Los DZs y eventos pueden estar en cualquier zona horaria; la app debe gestionar correctamente las TZ. - Los jumpers acceden gratis. Los coaches pagan suscripción (~6,99 €/mes o 49–59 €/año). En V1 no se procesa el cobro dentro de la app — se enlaza a pasarela externa. La gestión del estado de suscripción sí está en V1. 3.2 Supuestos técnicos - Cumplimiento RGPD obligatorio. Datos personales tratados conforme a la normativa europea, con opción de borrado y exportación. - Autenticación: Apple Sign In, Google Sign In y email con código OTP. No se acepta sólo email/contraseña. - Notificaciones push obligatorias (APNs y FCM). - Almacenamiento de vídeo: el upload de vídeos para análisis de nivel requiere almacenamiento de objetos (S3 o equivalente). Se debe prever lifecycle policy (vídeos antiguos a tier frío). - Integración con servicio de mapas (Mapbox o Google Maps). El proveedor debe justificar la elección considerando coste. 3.3 Restricciones - La estética visual debe seguir las pautas del deck de inversor entregado: glassmorphism suave, fondos azules / cielo, tipografía sans-serif moderna (estilo SF Pro / Inter). - La app debe ser usable con guantes y con sol directo (jumpers la usan en drop zone): contraste alto, áreas táctiles grandes, lecturabilidad en exterior. - Tiempo offline tolerable: la app debe permitir consulta de la última información cargada sin conexión y sincronizar al recuperarla. No se requiere edición offline en V1. - El componente de IA del V1 se limita al reconocimiento de nivel a partir de vídeo. El resto de capacidades de IA del Phase 2/3 se cotizan pero no se construyen en V1. 4. Actores y roles 4.1 Mapa de roles +----------------+----------------+----------------+----------------+ | Rol | Lado del | Acciones | Notas | | | marketplace | principales | | +----------------+----------------+----------------+----------------+ | Fun Jumper | Demanda | Descubrir DZ, | Rol por | | | | coaches, | defecto al | | | | eventos. | registrarse. | | | | | Puede activar | | | | Marcar | la capa Coach | | | | presencia. | desde su | | | | | perfil. | | | | Solicitar | | | | | coaching. | | | | | | | | | | Aplicar a | | | | | eventos. | | +----------------+----------------+----------------+----------------+ | Coach | Oferta | Publicar | Es una capa | | | | d | adicional | | | | isponibilidad. | sobre el | | | | | perfil de | | | | Gestionar | jumper. Misma | | | | solicitudes. | cuenta, mismas | | | | | credenciales. | | | | Editar perfil | | | | | pro. | | | | | | | | | | Cobrar (vía | | | | | link externo). | | +----------------+----------------+----------------+----------------+ | Load Organizer | Oferta | Coordinar | Funcionalmente | | | | saltos del | similar a | | | | día. | Coach pero con | | | | | permisos para | | | | Gestionar | gestionar | | | | grupos. | cargas de | | | | | avión. | | | | Notificar | | | | | participantes. | | +----------------+----------------+----------------+----------------+ | Event | Oferta | Crear eventos. | Puede ser una | | Organizer / | | | persona o una | | Team | | Configurar | entidad con | | | | requisitos. | varios | | | | | managers | | | | Revisar | (basic | | | | aplicaciones. | multi-manager | | | | | en V1). | | | | Gestionar | | | | | lista de | | | | | espera. | | +----------------+----------------+----------------+----------------+ | Drop Zone / | Lugar (nodo) | Página de | Precargados en | | Tunnel | | venue. | V1 a partir de | | | | | fuentes | | | | Reclamar | públicas. | | | | gestión | Reclamables | | | | (claim). | por | | | | | a | | | | Eventos | dministradores | | | | asociados. | reales en una | | | | | fase | | | | | posterior. | +----------------+----------------+----------------+----------------+ | Platform Admin | Plataforma | Aprobar | Rol interno de | | | | claims. | AIRSPACE. La | | | | | operación | | | | Verificar | manual es | | | | coaches. | parte | | | | | explícita del | | | | Moderar | modelo V1. | | | | contenido. | | | | | | | | | | Soporte. | | +----------------+----------------+----------------+----------------+ 4.2 Reglas de doble rol Un usuario puede simultáneamente ser jumper y coach. La interfaz debe permitir: - Cambiar de "vista jumper" a "vista coach" mediante un selector visible en la home (toggle o pestaña). - Recibir notificaciones segmentadas por rol (notificaciones de coach en su sección, no mezcladas con las de jumper). - Mantener un único perfil público con dos secciones: información de jumper (nivel, saltos, DZ home) e información de coach (disciplinas, experiencia, endorsements, disponibilidad). 5. Casos de uso principales Los siguientes casos de uso definen el comportamiento esperado del producto. Cada caso indica el rol, el flujo principal y los criterios de éxito. Sirven de base para test cases de aceptación. 5.1 CU-01: Jumper visita una DZ nueva - Actor: Fun Jumper. - Precondición: Usuario registrado y autenticado. La DZ existe en el sistema (precargada o reclamada). - Flujo principal: a. El jumper abre el mapa o el calendario. b. Localiza la DZ por geografía o búsqueda. c. Entra a la página de la DZ y ve: eventos próximos, coaches con disponibilidad para esa DZ, jumpers que han marcado presencia, datos meteorológicos básicos. d. Marca su propia asistencia para una fecha. e. Visualiza al menos dos perfiles de coach con disciplina, endorsements y precio orientativo. f. Envía una solicitud de coaching seleccionando coach, fecha y franja horaria. - Criterio de éxito: el jumper completa todo el flujo en menos de 3 minutos sin recurrir a canales externos. La solicitud queda registrada con estado "pendiente" y se notifica al coach. 5.2 CU-02: Coach gestiona disponibilidad multi-DZ - Actor: Coach con suscripción activa. - Flujo principal: a. El coach entra en su "Coach Space". b. Crea un bloque de disponibilidad: DZ, rango de fechas, franjas horarias, disciplinas, nivel de alumno requerido. c. Repite para una segunda y tercera DZ. d. Recibe solicitudes de jumpers; las acepta, declina o pide más información. e. Lanza una notificación push grupal a sus jumpers confirmados para confirmar asistencia 24h antes. - Criterio de éxito: el coach gestiona la agenda de tres DZs sin salir de la app y sin usar mensajería externa para confirmaciones rutinarias. 5.3 CU-03: Organizador lanza un camp con aplicación - Actor: Event Organizer. - Flujo principal: a. Crea un evento (formación de 4-way, fecha, DZ, capacidad 16 plazas). b. Define requisitos: nivel mínimo de alumno, disciplina, número mínimo de saltos. c. Configura formulario de aplicación corto (3–5 campos). d. Publica el evento. Recibe N aplicaciones. e. Revisa cada aplicación, acepta, rechaza o coloca en lista de espera. f. Cada cambio de estado dispara notificación al jumper y queda en el audit log. g. Antes del evento, descarga la lista de participantes confirmados. - Criterio de éxito: todo el ciclo de vida de la aplicación queda registrado en AIRSPACE como única fuente de verdad. Cero hilos de email. 5.4 CU-04: Jumper sube vídeo y la IA estima nivel - Actor: Fun Jumper. - Flujo principal: a. El jumper entra en "Datos de usuario" y selecciona "Subir vídeo de salto". b. Sube un vídeo (máx. 200 MB, formatos mp4/mov). c. El sistema procesa el vídeo en backend y devuelve un nivel estimado y una explicación corta. d. El nivel calculado se muestra junto al nivel autodeclarado y al nivel verificado por coach (si existe). - Criterio de éxito: el procesamiento se completa en menos de 5 minutos en el 90% de los casos. La estimación tiene un margen de error documentado y se etiqueta como "AI-assisted, not certified". 5.5 CU-05: Admin aprueba una reclamación de DZ - Actor: Platform Admin. - Flujo principal: a. Una persona reclama ser administradora de la DZ "Skydive X". b. El admin recibe la solicitud en el panel web con datos de contacto y prueba de relación. c. Verifica manualmente (llamada, email a un contacto público de la DZ). d. Aprueba o rechaza; ambas acciones notifican al usuario. e. Aprobada: el usuario obtiene permisos de gestión sobre la página de esa DZ. - Criterio de éxito: trazabilidad completa de la decisión, no se puede aprobar sin dejar registro de quién y cuándo. 6. Módulo funcional: Discovery 6.1 Pantalla principal (Home) Pantalla de entrada al abrir la app. Tres bloques de descubrimiento en este orden de prioridad visual: - DZs activas / cercanas: carrusel horizontal con DZ del país del usuario más DZs marcadas como favoritas. Cada tarjeta muestra nombre, indicador de actividad (jumpers presentes hoy), evento próximo si lo hay. - Eventos próximos: siguientes 30 días, ordenados por fecha. Cada tarjeta muestra fecha, nombre, DZ, plazas restantes. - Coaches disponibles: coaches con disponibilidad publicada en los próximos 14 días en DZs cercanas o favoritas. Foto, nombre, disciplina principal, badge de verificación. Acceso permanente a tres puntos de menú principal: MAPA, CALENDARIO, COACHES. Los cuatro puntos secundarios son: Mis Reservas, Eventos, Datos de Usuario, Coach Space (sólo si el usuario tiene capa de coach activa). 6.2 Vista MAPA - Mapa interactivo mundial centrado por defecto en la ubicación del usuario. - Marcadores de tipo "DZ activa" (en color primario) y "Evento próximo en los siguientes 90 días" (en color acento). - Cluster automático cuando hay >5 marcadores próximos. - Filtros: tipo de DZ (avión / túnel), disciplina, presencia de eventos, presencia de coaches con disponibilidad. - Tap en marcador → preview en bottom sheet con: nombre, distancia, próxima actividad, botón "ver detalle". - Cambio entre vista mapa y lista (toggle superior). 6.3 Vista CALENDARIO - Vista mensual con scroll vertical (rolling 90 días). - Cada día muestra "pastillas" con eventos planificados y DZs con actividad confirmada. - Filtros: por DZ, por disciplina, por proximidad geográfica, sólo eventos con plazas, sólo eventos a los que ya he aplicado. - Tap en pastilla → ficha de evento o ficha de DZ. 6.4 Vista COACHES - Lista de coaches con disponibilidad publicada en los próximos 30 días. - Ordenable por: cercanía geográfica, nivel/experiencia, fecha de próxima disponibilidad, rating de endorsements. - Cada tarjeta de coach: foto, nombre, DZ habituales, disciplinas, rango de coste indicativo, badge "Certified Pro" si aplica, número de saltos confirmados. - Tap en coach → perfil completo (sección 7.3). 6.5 Detalle de DZ (Venue Page) Página dedicada a cada drop zone. Contiene cinco secciones en este orden: 7. Cabecera: nombre, ubicación, foto, datos básicos (altitud, aviones disponibles, contactos públicos). 8. Eventos: lista cronológica con tres pestañas — "Abiertos" (admiten aplicaciones), "Próximos" (confirmados sin plazas), "Pasados". 9. Coaches con disponibilidad en esta DZ en los próximos 30 días. 10. Jumpers presentes hoy / próximos 7 días (los que han marcado asistencia). 11. Datos meteorológicos (integración con servicio externo de meteo, sección 13). Si la DZ no está reclamada, una banda informativa propone reclamarla. 7. Módulo funcional: Perfiles y Datos de Usuario 7.1 Perfil de Jumper Datos que componen un perfil completo de jumper: ---------------------------------- ------------------------ ------------------------------------------------------------------------------------------------ Campo Tipo Notas Nombre y apellido Texto, obligatorio Visible públicamente. Foto de perfil Imagen, opcional Si no hay, avatar generado por defecto. Email Email, obligatorio No visible públicamente. Usado para auth y notificaciones. DZ home Referencia DZ Selección de DZ habitual. Número total de saltos Entero, opcional Autodeclarado. Disciplinas practicadas Multi-select FS, FF, Wingsuit, Canopy Piloting, Tracking, etc. Lista cerrada gestionada por admin. Licencia (USPA / FAI / nacional) Texto + tipo Autodeclarado en V1. Verificación manual en V2. Nivel autodeclarado Enum (A, B, C, D, Pro) Selección del usuario. Nivel calculado por IA Enum + score Calculado a partir del vídeo subido. Sólo lectura. Etiquetado como AI-assisted. Nivel acreditado por coach Enum, opcional Sólo puede ser modificado por un coach con permiso de endorsement. Datos de pago Token de pasarela V1: el usuario guarda método de pago para uso futuro vía pasarela externa. No se almacena PAN. Idioma preferido Enum Para notificaciones y UI. Vídeos subidos Lista de referencias Hasta 10 vídeos almacenados por usuario. Lifecycle a tier frío tras 90 días. ---------------------------------- ------------------------ ------------------------------------------------------------------------------------------------ 7.2 Activación de capa Coach Un jumper que quiere ofrecerse como coach activa la capa desde su perfil. Esto añade los siguientes campos y desbloquea "Coach Space": - Disciplinas que coachea (multi-select). - Nivel de alumnos que acepta (rango). - Bio profesional (texto libre, máx. 500 caracteres). - Certificaciones (texto libre con archivo adjunto opcional). - Rango de precios indicativo (mínimo–máximo en EUR/USD). - Estado de suscripción de coach (activa / inactiva / en periodo de prueba). - DZs habituales (multi-select de DZs registradas). 7.3 Perfil público de Coach Vista que ven los jumpers al pinchar un coach. Combina datos del jumper (foto, nombre, DZ home, total de saltos verificados si los hay) con la capa coach. Incluye: - Header con foto, nombre, badges (Certified Pro, número de saltos, años de experiencia). - Disciplinas y nivel de alumno. - Bio. - Endorsements de otros coaches (estructura de skeleton en V1: visibles solamente al jumper que mira; públicos en Phase 2). - DZs habituales con indicador de "disponible próximamente". - Calendario de disponibilidad (siguientes 30 días). - CTA: "Solicitar slot" → flujo de reserva (sección 8). 7.4 RGPD y privacidad - Consentimiento explícito al crear cuenta para tratamiento de datos personales y, separadamente, para envío de notificaciones de marketing. - Acceso desde "Datos de usuario" a: descargar mis datos (export JSON), eliminar mi cuenta (soft delete con purge a los 30 días). - Vídeos: se procesan para análisis de IA y se conservan a menos que el usuario los borre. Documentar la base legal del tratamiento. - Datos de menores: AIRSPACE no admite menores de 18 años. Validación en onboarding. 8. Módulo funcional: Reservas de Coaching 8.1 Disponibilidad publicada por el coach Una unidad de disponibilidad (slot) tiene los siguientes atributos: - Coach (referencia). - DZ (referencia). - Fecha y franja horaria (inicio, fin). - Disciplinas que se coachean en ese slot. - Capacidad máxima (1 a N alumnos). - Precio por alumno (opcional, indicativo). - Requisitos mínimos de nivel. - Estado: abierto, cerrado, completado, cancelado. 8.2 Solicitud de reserva (request) Un jumper crea una request al pinchar "Solicitar slot". La request incluye: - Slot al que se aplica. - Mensaje opcional al coach (texto libre, máx. 300 caracteres). - Confirmación de nivel (autodeclarado o calculado). 8.3 Máquina de estados de reserva Toda reserva sigue esta máquina de estados. Cualquier transición debe quedar registrada en un audit log con timestamp, usuario que la dispara y razón opcional. ------------ ------------------------------------------------ ----------------------------------------------- --------------------------------------- Estado Disparado por Siguiente estado posible Notificación Pendiente Jumper crea request Confirmada / Rechazada / Cancelada por jumper Push al coach Confirmada Coach acepta Pagada / Cancelada Push al jumper Pagada Webhook pasarela externa o confirmación manual Completada / Cancelada Push a ambos Completada Coach marca como realizada (estado terminal) Push al jumper, opción de endorsement Rechazada Coach rechaza (estado terminal) Push al jumper Cancelada Cualquier parte (estado terminal) Push a la otra parte ------------ ------------------------------------------------ ----------------------------------------------- --------------------------------------- 8.4 Pago - V1: enlace a pasarela externa (Stripe Payment Links, PayPal.me o equivalente). El coach configura su URL de pago en su perfil. Al confirmar la reserva, el jumper recibe el enlace. - Webhook opcional: si la pasarela soporta webhooks (Stripe), se actualiza el estado a "Pagada" automáticamente. Si no, el coach marca como pagada manualmente. - Phase 2: pagos in-platform con custody, payouts a coaches, comisión de plataforma. Estimación indicativa, no en V1. 8.5 Mis Reservas (vista jumper) - Listado con tres tabs: Pendientes, Activas (Confirmadas + Pagadas), Histórico. - Cada item muestra coach, DZ, fecha, estado actual, importe. - Acciones por item: ver detalle, cancelar (si aplica), abrir link de pago, ver chat (V2 opcional). 9. Módulo funcional: Eventos y Aplicaciones 9.1 Creación de un evento Un Event Organizer crea un evento mediante un formulario de varios pasos. Campos: - Información básica: título, descripción, tipo (Camp, Boogie, Competición, Curso), DZ donde se celebra, fecha de inicio y fin. - Capacidad: número máximo de plazas, política de overflow (lista de espera sí/no). - Requisitos: nivel mínimo, disciplinas requeridas, número mínimo de saltos, certificaciones específicas. - Aplicación: formulario de hasta 10 preguntas configurables (texto corto, texto largo, selección única, selección múltiple, archivo adjunto). - Coaches asociados (opcional): coaches que participan en el evento. - Información comercial: precio orientativo, link de pago externo, política de cancelación. - Imagen de portada y galería opcional (hasta 5 imágenes). - Visibilidad: público, sólo invitados con código. 9.2 Aplicación a un evento (jumper) - El jumper rellena el formulario configurado por el organizador. - Si el evento requiere nivel mínimo, el sistema valida automáticamente con el nivel del jumper (autodeclarado / calculado IA / acreditado coach). Si no cumple, muestra advertencia pero permite aplicar (la decisión final es del organizador). - La aplicación entra en estado "Pendiente revisión". 9.3 Máquina de estados de aplicación - Pendiente revisión → Aceptada / En lista de espera / Rechazada. - Aceptada → Pagada (si aplica) → Confirmada → Asistida / No-show. - En lista de espera → Aceptada (si se libera plaza) o Expirada (si no se libera antes del evento). - Cada transición notifica al jumper y queda en audit log. 9.4 Vista de gestión del organizador - Tabla con todas las aplicaciones del evento, filtros por estado, búsqueda por nombre. - Acciones bulk: aceptar varios a la vez, mover a lista de espera, rechazar. - Vista detalle de aplicación: respuestas del formulario, perfil del jumper, histórico (otras aplicaciones suyas en eventos pasados — si los hay). - Mensaje al participante (texto libre que se envía vía push + queda en su sección de mensajes del evento). - Export de la lista en CSV (V2; en V1 sólo visualización en app/web). 9.5 Confirmación de asistencia - Antes del evento (configurable: 24h, 48h o 7 días antes), notificación push al jumper aceptado pidiendo confirmar asistencia. - Si no confirma en X horas, el organizador recibe alerta y puede liberar la plaza a la lista de espera. 10. Módulo funcional: Coach Space y Load Organizer Space 10.1 Coach Space Sección habilitada únicamente para usuarios con la capa Coach activa y suscripción al día. Contiene cuatro pantallas: - Mis disponibilidades: calendario con todas las disponibilidades publicadas, edición y borrado. - Solicitudes recibidas: pendientes, aceptadas, históricas. Acciones rápidas: aceptar, rechazar, pedir info. - Mis eventos como coach: eventos en los que estoy listado como coach asociado. - Mi perfil pro: edición de bio, disciplinas, certificaciones, foto profesional, link de pago. 10.2 Comunicación Coach → Jumpers - Notificación push grupal: el coach selecciona un grupo de jumpers (todos los confirmados de un slot, todos los del próximo evento) y envía un mensaje. - Material por evento: el coach puede subir documentos (instrucciones, briefing, vídeo de referencia) que los jumpers ven en su sección "Mis Reservas" o ficha de evento. - Mensajería 1:1 directa entre coach y jumper: opcional V1, recomendable V2. En V1 puede sustituirse por links externos (WhatsApp del coach). 10.3 Load Organizer Space Variante simplificada de Coach Space para load organizers. Permite: - Crear "loads" (saltos del día) con: avión, hora prevista, disciplina, slots disponibles, requisitos. - Los jumpers se inscriben tap-to-join. - El organizer cierra la load cuando se completa o cuando despega. - Notificaciones automáticas a inscritos: 30min antes, embarque, cierre. Nota de alcance: si el equipo prefiere postergar Load Organizer Space al Phase 2 para acortar V1, indicarlo en la cotización con su impacto en effort. 11. Módulo funcional: Panel de Administración 11.1 Acceso y roles - Acceso vía web (URL separada de la app pública). SSO con Google Workspace de la empresa. - Tres roles internos: Admin (todo), Moderator (sólo moderación de contenido), Support (sólo lectura + chats con usuarios). 11.2 Gestión de DZs - Listado completo de DZs: precargadas, reclamadas, pendientes. - CRUD completo de DZs (alta manual, edición, baja). - Bandeja de claims pendientes con detalle de la solicitud y acción aprobar/rechazar. - Histórico de claims (auditoría). 11.3 Verificación de Coaches - Listado de coaches con filtros (verificados, pendientes, suscripción activa, etc.). - Vista detalle con sus certificaciones cargadas y opciones de aprobar / pedir más info / rechazar. - Asignación / revocación manual del badge "Certified Pro". 11.4 Moderación de contenido - Cola de reportes (un usuario reporta a otro, una imagen, un evento, un comentario). - Acciones: descartar, ocultar contenido, suspender cuenta (temporal o permanente), enviar warning. - Histórico por usuario: warnings, suspensiones, reportes. 11.5 Configuración global - Listas cerradas: disciplinas, niveles, tipos de evento, idiomas soportados. - Parámetros: precio sugerido suscripción coach, días de retención de vídeos, ventanas de notificación. - Textos legales (T&C, privacy, cookies) versionables: cuando se cambian, los usuarios deben re-aceptar al siguiente login. 11.6 Métricas operativas - Dashboard básico: usuarios activos diarios/semanales, nuevos registros, eventos creados, reservas completadas. - Funnel: registro → primera marca de presencia → primera solicitud → primera reserva confirmada. - V1 = dashboard simple. Analítica avanzada se cotiza en Phase 2. 11.7 Fan Zone (módulo opcional V1) La Fan Zone es una zona de tipo red social ligera donde los usuarios pueden subir fotos y vídeos cortos y ver actividad de otros. Su inclusión en V1 está sujeta a decisión: el deck de inversor explícitamente posiciona AIRSPACE como NO red social. Se recomienda postergarla al Phase 2 o tratarla como módulo opcional cotizado por separado. 12. Modelo de datos (alto nivel) Modelo conceptual orientado a estimación. El proveedor entregará el modelo físico definitivo en la fase de diseño detallado. 12.1 Entidades principales ---------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Entidad Atributos clave y relaciones User id, email, nombre, foto, idioma, dz_home_id, total_saltos, nivel_autodeclarado, nivel_ia, nivel_acreditado, fecha_creación, estado (active/suspended/deleted). Relación 1:0..1 con CoachProfile. CoachProfile user_id, bio, disciplinas[], niveles_alumno[], certificaciones[], dz_habituales[], rango_precio, link_pago_externo, suscripcion_estado, suscripcion_hasta, badge_certified_pro. DropZone (Venue) id, nombre, país, lat/lng, tipo (avión/túnel), descripción, foto, contactos_publicos, claimed_by_user_id, fecha_creación, estado. Event id, titulo, tipo, dz_id, organizer_user_id, fecha_inicio, fecha_fin, capacidad, requisitos, formulario_aplicacion_json, precio, link_pago, visibilidad, estado. EventApplication id, event_id, user_id, respuestas_json, estado (pdte/aceptada/lista_espera/rechazada/cancelada/asistida/no_show), fecha_creación, audit_log[]. CoachSlot (Disponibilidad) id, coach_user_id, dz_id, fecha, hora_inicio, hora_fin, disciplinas[], capacidad, precio, requisitos, estado. Booking (Reserva) id, slot_id, jumper_user_id, mensaje, estado (pdte/confirmada/pagada/completada/rechazada/cancelada), fecha_creación, audit_log[]. Endorsement id, from_coach_user_id, to_user_id, tipo (skill/general), comentario, visibilidad (privada V1, pública V2), fecha. Attendance (Presencia) id, user_id, dz_id, fecha, fuente (manual/evento). Marca que un jumper estará en una DZ una fecha. Notification id, user_id, tipo, payload_json, leida, fecha. VideoUpload id, user_id, url_storage, fecha_subida, estado_procesamiento_ia, resultado_ia_json, lifecycle_tier. AuditLog Tabla genérica para trazar cambios de estado críticos. id, entidad, entidad_id, acción, actor_user_id, fecha, payload. ---------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 12.2 Estimación volumétrica V1 (12 meses) - Usuarios: 5.000–15.000. - Coaches activos: 200–500. - DZs precargadas: ~1.500 (escraping inicial). DZs reclamadas: 50–150. - Eventos creados: 500–1.500. - Reservas: 5.000–20.000. - Vídeos subidos: 2.000–8.000 (máx 200MB cada uno). - Notificaciones push: 50.000–200.000/mes. 13. Integraciones externas -------------------------- --------- ------------------------------------------------------------------------------------------------------------ Integración Fase Notas Apple Sign In V1 Obligatorio en iOS por política de App Store. Google Sign In V1 Mismo SSO en iOS y Android. Email OTP V1 Vía proveedor transaccional (Postmark, SendGrid o equivalente). Mapas V1 Mapbox o Google Maps. Justificar elección por coste y SLA. Notificaciones push V1 APNs (iOS) y FCM (Android), gestionadas vía un proveedor unificado (Firebase Cloud Messaging o OneSignal). Email transaccional V1 Postmark, SendGrid, AWS SES o equivalente. Servicio de meteo V1 OpenWeather, Tomorrow.io o equivalente. Datos básicos en venue page. Almacenamiento objetos V1 S3, Cloudflare R2 o equivalente. Vídeos y fotos. Pasarela de pago externa V1 Sólo enlace + webhook opcional. Stripe Payment Links o equivalente. Pagos in-platform Phase 2 Stripe Connect o equivalente con custody de fondos y payouts. Analytics producto V1 Mixpanel, Amplitude o PostHog para funnel y eventos producto. Crash reporting V1 Sentry o equivalente. Soporte cliente V1 Intercom o Crisp embebido para chat in-app. -------------------------- --------- ------------------------------------------------------------------------------------------------------------ 14. Arquitectura técnica indicativa La arquitectura final la propone el proveedor. Las siguientes pautas son orientativas, no prescriptivas. 14.1 Componentes esperados - Apps móviles iOS y Android (nativas o cross-platform — el proveedor justifica). - API backend (REST o GraphQL). - Servicio de procesamiento asíncrono (workers) para tareas largas: análisis de vídeo, notificaciones masivas, lifecycle de almacenamiento. - Base de datos relacional principal (PostgreSQL recomendado). - Cache (Redis) para sesiones, rate limiting y datos hot. - Object storage (S3 o equivalente) para vídeos, fotos, documentos. - Servicio de IA: pipeline de inferencia desacoplado del API principal (ver sección 15). - Panel admin (web app). - CDN para distribución de imágenes y vídeos. 14.2 Entornos - Desarrollo (local + cloud staging compartido). - Staging (preproducción, datos sintéticos). - Producción. - CI/CD automatizado: tests, build, deploy a staging on merge to main, deploy a producción con aprobación manual. 14.3 Seguridad - Comunicaciones HTTPS/TLS 1.2+ en todos los endpoints. - Tokens de auth con expiración y refresh. - Rate limiting por IP y por usuario. - OWASP Top 10 cubierto en pentest pre-lanzamiento (ver sección 17). - Cifrado at rest de datos personales sensibles (RGPD). - Logs sin información personal identificable; métricas anonimizadas. 15. Componente de Inteligencia Artificial — Bloque B El componente de IA se cotiza en bloque separado. En V1, una sola capacidad es funcional: el reconocimiento de nivel a partir de vídeo. El resto se especifica para que el proveedor pueda ofertar Phase 2. 15.1 V1 — Reconocimiento de nivel a partir de vídeo - Entrada: vídeo subido por el usuario, formato mp4/mov, máx 200 MB, duración 30s a 5 min. - Salida: nivel estimado (A, B, C, D, Pro), score de confianza (0–1), explicación textual corta (< 200 caracteres) tipo "Estabilidad: buena. Apertura: tardía. Recomendación: trabajar conciencia de altitud". - Modelo: el proveedor propone enfoque (modelo de visión preentrenado fine-tuned, multimodal LLM con análisis de frames, etc.). Se valorará: precisión declarada, coste por inferencia, tiempo de respuesta. - Latencia objetivo: <5 minutos en el 90% de los casos para vídeos de hasta 2 minutos. Procesamiento asíncrono con notificación push al terminar. - Etiquetado: todo resultado se muestra al usuario como "AI-assisted, not certified". El nivel acreditado por coach humano siempre prevalece visualmente. - Set de datos: el proveedor de IA debe indicar si necesita un dataset de entrenamiento etiquetado y, en su caso, cómo se construye (con qué coaches, qué volumen mínimo, cuánto tiempo de etiquetado). - Reentrenamiento: estimar coste y cadencia de reentrenamiento con feedback de coaches reales. 15.2 Phase 2 — Capacidades adicionales - Matching jumper-coach: recomendación de coaches para un jumper en función de nivel, disciplina, ubicación, histórico de bookings. - Recomendación personalizada de eventos: ranking de eventos abiertos para un jumper específico. - Organizer Copilot: asistente que ayuda al organizador a revisar aplicaciones (sugerir aceptar/rechazar con justificación), priorizar lista de espera, redactar mensajes. - Skill interpretation: análisis agregado de varios vídeos del mismo jumper para detectar progresión. - Trust support: detección de patrones sospechosos (fake accounts, endorsements falsos, abuso). 15.3 Consideraciones éticas y legales - Consentimiento explícito al subir vídeo, con explicación clara de cómo se usa. - Posibilidad de borrado del vídeo por el usuario en cualquier momento, con garantía de borrado del modelo (no usado para entrenamiento futuro). - Política de no entrenamiento con datos del usuario sin consentimiento explícito. - Disclaimer claro: la IA no sustituye criterio profesional para decisiones de seguridad. 16. Flujos UX críticos 16.1 Onboarding del jumper (primer uso) 12. Splash screen + login (Apple / Google / Email). 13. Aceptación de T&C y política de privacidad. 14. Mini-formulario: nombre, foto opcional, DZ home (autocompletado), nivel autodeclarado, total de saltos. 15. Permiso de notificaciones push y de geolocalización (con explicación previa). 16. Aterrizaje en Home con tour guiado de 3 pasos (mapa, calendario, coaches). 16.2 Onboarding del coach 17. El usuario ya es jumper. Entra en "Datos de Usuario" → "Convertirme en coach". 18. Formulario adicional: bio, disciplinas, certificaciones, link de pago. 19. Pantalla de suscripción: explicación de plan + redirección a pasarela externa para alta. 20. Tras confirmación de pago (webhook), la capa coach se activa. 21. Tour guiado del Coach Space. 16.3 Reserva de slot de coaching (jumper) 22. Desde perfil de coach → calendario → tap en slot disponible. 23. Pantalla de confirmación: detalles del slot, mensaje al coach, confirmación de nivel. 24. Envío. Estado "Pendiente". Notificación al coach. 25. Cuando el coach acepta, el jumper recibe push con link de pago. 26. Tras pago, estado pasa a "Confirmada". 24h antes recibe recordatorio. 16.4 Aplicación a evento (jumper) 27. Desde detalle de evento → "Aplicar". 28. Si no cumple requisitos automáticos: aviso pero sigue. 29. Formulario configurado por el organizador. 30. Envío. Estado "Pendiente revisión". 31. Cuando el organizador decide, push y cambio de estado en "Mis Reservas". 16.5 Casos borde a definir en diseño - Coach cancela un slot ya pagado: ¿reembolso automático? ¿manual? ¿quién informa? - Evento cancelado por el organizador con aplicaciones aceptadas y pagadas. - Jumper no se presenta a un slot pagado (no-show). - Cambio meteorológico que cancela toda la actividad de la DZ. - Suscripción del coach expira con reservas activas pendientes. - Usuario borra su cuenta con reservas activas o eventos creados. La política de cada caso es decisión de producto. El proveedor debe asumir un comportamiento por defecto razonable y documentarlo en su propuesta. 17. Requisitos no funcionales 17.1 Rendimiento - Tiempo de carga de Home: <2 segundos en red 4G. - API: P95 de respuesta <500ms para endpoints de lectura, <1s para escritura. - Procesamiento de vídeo IA: <5 minutos en P90. 17.2 Disponibilidad - SLA objetivo de 99.5% en V1, 99.9% en Phase 2. - Plan de DR documentado con RTO 4h y RPO 1h. 17.3 Escalabilidad - Arquitectura horizontalmente escalable: stateless API, base de datos con réplicas de lectura. - Soporte de 10x los volúmenes V1 sin re-arquitectura. 17.4 Mantenibilidad - Cobertura de tests automatizados ≥70% en backend, ≥50% en frontend. - Documentación de API en OpenAPI / GraphQL Schema. - Linting y formateo automatizados. - Onboarding técnico de un nuevo desarrollador en menos de 1 día. 17.5 Seguridad y cumplimiento - Pentest externo antes de producción. - RGPD completo: registro de actividades de tratamiento, política de privacidad, DPA con subprocesadores. - App Store y Google Play compliance, incluyendo política de IAP cuando aplique. 17.6 Accesibilidad - WCAG 2.1 AA en pantallas críticas. - Compatibilidad con VoiceOver (iOS) y TalkBack (Android). - Tamaños de fuente respetan ajustes del sistema operativo. 17.7 Internacionalización - Strings externalizados desde día 1. - Idiomas iniciales: español, inglés. - Soporte de unidades imperiales y métricas (pies / metros, mph / km/h). - Manejo correcto de zonas horarias por DZ (no por usuario). 18. Criterios de aceptación del V1 La entrega del V1 se considera aceptada cuando se cumplen, de forma demostrable, los siguientes criterios: Funcionales - Todos los casos de uso CU-01 a CU-05 pasan en el entorno de staging con datos de test. - Las cinco máquinas de estado (reserva, aplicación, claim DZ, suscripción coach, vídeo IA) están implementadas y trazadas. - El panel admin permite operar todos los flujos descritos en la sección 11. Técnicos - Cobertura de tests cumplida (sección 17.4). - Pentest externo pasado sin vulnerabilidades altas o críticas. - Apps publicadas en App Store y Google Play en estado "available for review". - Documentación técnica entregada (sección 19). Operativos - Entorno de producción provisionado y en marcha. - Pipelines CI/CD funcionales. - Monitorización y alerting configurados (Sentry, métricas de disponibilidad). - Hand-off técnico documentado para que el equipo del cliente pueda operar tras la entrega. Piloto - 3–5 DZs precargadas y reclamadas en producción. - Mínimo 10 coaches con perfil completo y disponibilidad publicada. - Mínimo 3 eventos creados por organizadores reales con al menos una aplicación cada uno. - 100 jumpers registrados con al menos una marca de presencia. Notas: los criterios del piloto requieren coordinación con el cliente para captación de DZs y coaches; no son responsabilidad exclusiva del proveedor. 19. Entregables esperados 19.1 Producto - App iOS publicada en App Store. - App Android publicada en Google Play. - Backend en producción, multi-entorno. - Panel admin web. 19.2 Documentación técnica - Documento de arquitectura final. - Modelo de datos físico (DDL). - Especificación de API (OpenAPI / Schema). - Guía de despliegue y operación. - Runbook de incidencias. - Documentación del modelo de IA: arquitectura, métricas de evaluación, guía de reentrenamiento. 19.3 Documentación funcional - Manual de usuario de la app (jumper, coach, organizador) — formato breve, en español e inglés. - Manual de uso del panel admin. 19.4 Diseño - Design system entregado en Figma. - Screens finales de todas las pantallas implementadas. 19.5 Código y assets - Código fuente en repositorio Git del cliente. - Cuentas y credenciales de todos los servicios externos a nombre del cliente. - Inventario de licencias open source utilizadas. 20. Estructura de la cotización solicitada Para que las propuestas sean comparables, se solicita al proveedor que presente su cotización con la siguiente estructura mínima: 20.1 Resumen ejecutivo - Comprensión del proyecto en sus propias palabras. - Enfoque metodológico (Agile/Scrum, sprints, governance). - Equipo propuesto (perfiles, dedicación). - Plazo total y fecha estimada de go-live. 20.2 Desglose económico por bloque -------- --------------------------------------- ------------------------- -------- ------- Bloque Concepto Esfuerzo (días-persona) Tarifa Total A V1: App + Backend + Admin Diseño UX/UI Desarrollo móvil Desarrollo backend + admin QA y testing DevOps y setup infraestructura Project management B Componente IA (V1: nivel desde vídeo) C Phase 2 (estimación indicativa) -------- --------------------------------------- ------------------------- -------- ------- 20.3 Costes recurrentes año 1 - Hosting e infraestructura cloud. - Servicios SaaS (mapas, push, email, analytics, crash, soporte). - Coste por inferencia de IA (estimación con volúmenes V1). - Mantenimiento evolutivo (% del coste de desarrollo, típicamente 15–20% anual). 20.4 Plan de proyecto - Cronograma con hitos. - Sprints o fases con entregables por hito. - Dependencias del cliente (decisiones, contenido, captación piloto). 20.5 Riesgos y supuestos - Riesgos identificados y plan de mitigación. - Supuestos asumidos por el proveedor para construir la oferta. 20.6 Garantías y soporte post-entrega - Periodo de garantía sobre defectos (mínimo 90 días). - SLA de mantenimiento posterior. - Estructura de pricing para cambios y ampliaciones. 20.7 Referencias - Mínimo dos casos comparables (apps móviles con backend, idealmente con componente de IA o marketplace de servicios). - CV del equipo clave. 20.8 Validez de la oferta - Mínimo 60 días desde la fecha de presentación. 21. Anexos 21.1 Glosario --------------------- -------------------------------------------------------------------------- Término Definición DZ (Drop Zone) Instalación donde se realizan saltos de paracaidismo. Tunnel Túnel de viento vertical, instalación para entrenamiento de caída libre. Jumper / Fun Jumper Saltador de paracaidismo recreativo (no instructor). Coach Saltador con experiencia que entrena a otros jumpers. Load Carga de avión: el grupo de saltadores que sube en un mismo vuelo. Load Organizer Persona que coordina los saltos del día en una DZ. Boogie Evento de skydiving multi-día con muchos jumpers, ambiente festivo. Camp Evento formativo intensivo, típicamente 3–7 días. Endorsement Recomendación o aval que un coach hace de otro jumper o coach. FS / FF Formation Skydiving / Free Flying. Disciplinas del deporte. Manifest Sistema operativo de la DZ que gestiona embarques y registros de salto. USPA United States Parachute Association. Federación nacional de EEUU. FAI Federación Aeronáutica Internacional. --------------------- -------------------------------------------------------------------------- 21.2 Documentos de referencia - AIRSPACE Investor Memo v3 (.docx) — contexto estratégico y de negocio. - AIRSPACE Deck (.pdf) — visión visual del producto y estética objetivo. - AIRSPACE Functional Specifications (.docx) — borrador inicial sobre el que se construye este documento. 21.3 Próximos pasos 32. Envío del documento a 3–5 proveedores preseleccionados. 33. Sesión de Q&A grupal o individual (1 semana después del envío). 34. Recepción de propuestas (3 semanas tras Q&A). 35. Evaluación: criterios técnicos (40%), económicos (30%), equipo y referencias (20%), encaje cultural y de proceso (10%). 36. Shortlist y entrevistas con 2 finalistas. 37. Adjudicación y contratación.