Bdreams · Hoja de ruta oficial

Del MVP al
laboratorio clínico.
Cuatro fases.

Roadmap de producto de Bdreams — app para inducción de sueños lúcidos basada en neurociencia. Desde el loop diurno-nocturno en HTML vanilla hasta la interfaz cerebro-sueño con EEG consumer.

Vista general

4 fases · 18 meses de visión

De MVP funcional a plataforma clínica y de investigación. Cada fase tiene criterio de éxito medible antes de pasar a la siguiente.

1
Fase 01
MVP Web
En curso
Live
2
Fase 02
PWA + Wearable
3–4 meses
Próxima
3
Fase 03
Mobile nativo
6–9 meses
Planificada
4
Fase 04
Clínico + BCI
12–18 meses
Visión
Detalle de fases

Hitos, criterios y dependencias

Cada fase está definida por sus entregables, el criterio de éxito que habilita el paso a la siguiente, y las dependencias técnicas que la bloquean.

Fase 01 · En curso
MVP Web
HTML/CSS/JS vanilla · localStorage
🌙
  • Reality Check Pavloviano — Tótem sonoro (Web Audio API) + logs diarios de condicionamiento
  • Técnicas guiadas: MILD (grabación de intención), WBTB (alarma configurable), SSILD (temporizador de ciclos atencionales)
  • Diario onírico con captura de texto + cálculo del IRO (Índice de Recuerdo Onírico, escala 0–100)
  • Streak diario + gamificación básica: 5 niveles (Aprendiz → Explorador → Soñador → Arquitecto → Comunicador)
  • Loop completo persistente en localStorage — sin backend, funciona offline por defecto
Criterio de éxito
El usuario puede completar el loop diurno–nocturno–mañana sin fricciones: RC diurno → técnica nocturna → diario al despertar → IRO actualizado. Tasa de abandono en los primeros 3 días < 40%.
  • FEWeb Audio API para generación del Tótem sonoro
  • FElocalStorage con schema versionado (dream_entries, rc_logs, streak)
  • FENotification API (local, sin push) para RC aleatorio diurno
  • FESin dependencias externas — bundle cero
Fase 02 · 3–4 meses
PWA + Wearable
Supabase · Edge Functions · Claude API
📡
  • Progressive Web App instalable: manifiesto, Service Worker, notificaciones push reales (no solo locales)
  • Integración HealthKit (iOS) / Google Fit (Android) para lectura de ciclos REM desde wearable
  • Motor TLR: emisión automática del Tótem durante ventanas REM detectadas, fade-in de 90 seg
  • Dashboard de analítica: IRO semanal con tendencia, tasa de lucidez, calidad REM estimada, mejor técnica por perfil
  • Detección de patrones recurrentes en el diario (señales candidatas para RC personalizado) via Claude API
Criterio de éxito
La tasa de lucidez del usuario sube ≥20% después de 4 semanas de uso del motor TLR activo vs. las 4 semanas previas solo con técnicas manuales.
  • BESupabase: Auth, PostgreSQL, Storage para diario y métricas
  • BEEdge Functions: scoring IRO, análisis de patrones, protocolo adaptativo semanal
  • IAClaude API para análisis semántico del diario onírico
  • HWHealthKit / Google Fit API — requiere app wrapper nativo o bridge PWA
  • FEPush notifications via Web Push + VAPID keys
Fase 03 · 6–9 meses
Mobile nativo
React Native · Expo · App Store / Google Play
📱
  • App React Native + Expo — base de código única para iOS y Android
  • Notificaciones en background para RC diurno (no depende de que la app esté abierta)
  • Motor TLR nativo con acceso directo a sensores del dispositivo (acelerómetro, HRV, micrófono)
  • Whisper on-device (Expo MLKit) para voz-a-texto al despertar — sin envío de audio a servidores externos
  • Modo offline-first completo: sincronización en background cuando hay conectividad
  • Publicación en App Store y Google Play con revisión médica de claims
Criterio de éxito
Retención D30 > 40% — al menos 4 de cada 10 usuarios que instalan la app siguen usándola activamente al mes de haberla descargado.
  • FEReact Native + Expo SDK — migración desde PWA con reutilización de lógica de negocio
  • IAWhisper on-device: expo-speech o react-native-whisper (modelo small/base cuantizado)
  • HWAcceso nativo a sensores: expo-sensors (acelerómetro), HealthKit bridge
  • BEBackground tasks: expo-background-fetch + expo-task-manager
  • REGRevisión de claims médicos para App Store Review (Apple HIG + FDA wellness exemption)
Fase 04 · 12–18 meses
Clínico + BCI
EEG consumer · API investigadores · LDT clínico
🧠
  • Protocolo LDT (Lucid Dreaming Therapy) para pesadillas crónicas y TEPT — validado clínicamente con IRB
  • Interactive Dreaming mode: detección de señalización ocular + integración BCI externo (Muse, Neurosity)
  • API pública para investigadores: endpoints IRB-ready, consentimiento granular, exportación de datos anonimizados
  • Integración con bandas frontales EEG consumer para detección de REM de alta precisión (>90% vs wearable ~75%)
  • Primer estudio piloto diseñado, ejecutado con datos de la app y aceptado para publicación
Criterio de éxito
Primer estudio piloto publicado (o aceptado para revisión en revista peer-reviewed) usando datos reales recogidos por la app, con metodología IRB y consentimiento informado documentado.
  • HWSDK Muse (InteraXon) + Neurosity Crown — Bluetooth LE + procesamiento de señal EEG en tiempo real
  • IAClasificador REM/NREM sobre señal EEG cruda — modelo edge o inference vía API
  • BEAPI pública con autenticación IRB, endpoints de exportación FHIR-compatible
  • REGIRB (Institutional Review Board) para estudio clínico + GDPR/HIPAA para datos oníricos
  • REGRevisión de clasificación como software médico (SaMD) según MDR / FDA 510(k) si se hacen claims terapéuticos
Arquitectura técnica

Stack por fase

Cada fase introduce solo las capas de complejidad necesarias. Sin over-engineering anticipado.

Fase Frontend Backend IA / ML Hardware Datos
Fase 1 · MVP HTML/CSS/JS Web Audio API Notification API Sin backend localStorage Sin IA algoritmo local IRO Sin HW teléfono básico Únicamente local, sin nube
Fase 2 · PWA PWA Service Worker Web Push Supabase Edge Functions PostgreSQL Claude API análisis diario HealthKit Google Fit Supabase cloud + sync
Fase 3 · Native React Native Expo SDK Supabase background sync Whisper on-device STT Sensores nativos HRV nativo Offline-first, sync diferido
Fase 4 · Clínico React Native BCI overlay Supabase API pública FHIR EEG classifier Claude API Muse Neurosity EEG BLE IRB, GDPR, anonimización
KPIs por fase

Métricas de éxito

Las métricas que determinan si cada fase ha cumplido su objetivo y si tiene sentido invertir en la siguiente.

Fase 1 · MVP
<40%
Tasa de abandono en los primeros 3 días. Mide si el loop diurno–nocturno–mañana es usable sin fricción.
Fase 1 · MVP
7 días
Retención D7: el usuario completa al menos 5 loops en la primera semana. Proxy de adherencia mínima al protocolo.
Fase 2 · PWA
+20%
Incremento en tasa de lucidez reportada tras 4 semanas de uso del motor TLR activo con wearable conectado.
Fase 2 · PWA
IRO +15
Mejora media del Índice de Recuerdo Onírico a las 4 semanas vs. baseline. Predictor validado de lucidez futura.
Fase 3 · Native
>40%
Retención D30: al menos 4 de cada 10 usuarios siguen activos al mes de instalar la app. Benchmark estándar de salud para apps de salud.
Fase 3 · Native
4.2★
Rating mínimo en App Store / Google Play con al menos 100 valoraciones. Indicador de calidad de UX y ausencia de bugs críticos.
Fase 4 · Clínico
1 estudio
Primer estudio piloto publicado o aceptado en revisión con datos de la app, metodología IRB y consentimiento documentado.
Fase 4 · Clínico
>90%
Precisión de detección REM con EEG consumer integrado vs. PSG de referencia. Umbral para claims clínicos defensables.
Análisis competitivo

Bdreams vs. el mercado

Las apps existentes tienen protocolos incompletos, UX de 2015 o carecen de base científica actualizada. Ninguna cierra el loop completo.

App RC Pavloviano Motor TLR / REM Diario + IA Gamificación BCI / EEG Base científica UX moderno
Lucid Dreamer Parcial No Básico No No Moderada No · 2017
DreamOn No TLR simple (sin detección REM real) No No No Baja No · abandonada
Awoken No Diario sin IA Mínima No Moderada No · 2016
Mindsync No No No No EEG externo (hardware propio caro) Parcial Sí · nicho
Bdreams ★ Sí · Pavloviano Sí · Motor TLR + REM Sí · Claude API Sí · 5 niveles Fase 4 · Muse + Neurosity Muy alta · IRB Sí · 2026
El gap que nadie ha cerrado

Ninguna app actual implementa los tres pilares simultáneamente: condicionamiento pavloviano diurno + motor TLR con detección REM real + diario analítico con IA. El loop completo es la ventaja competitiva de Bdreams. Y ninguna lo tiene.

Gestión de riesgos

Riesgos y mitigaciones

Los cuatro riesgos principales identificados y sus estrategias de mitigación específicas.

🧘
Riesgo 1 · Adherencia
El usuario abandona antes del efecto

El protocolo tarda entre 2 y 4 semanas en producir resultados medibles. La mayoría de los usuarios de apps de salud abandona antes de los 7 días. Sin adherencia, el producto no puede demostrar su eficacia.

Mitigación

Gamificación con feedback inmediato desde el día 1 (IRO diario visible, streak, niveles). Onboarding que fija expectativas realistas de tiempo. Notificaciones contextuales (no spam) basadas en el momento del ciclo. WBTB como quick win — primera lucidez posible en la primera semana para usuarios constantes.

📡
Riesgo 2 · Detección REM
Precisión insuficiente del wearable consumer

Apple Watch y Garmin tienen ~70–80% de precisión en detección REM vs. PSG clínico. Un 20–30% de falsas activaciones (TLR durante NREM profundo) puede interrumpir el sueño y generar desconfianza en el producto.

Mitigación

Diseño probabilístico: el motor TLR solo activa cuando la confianza en ventana REM supera el 70%. Disclaimer explícito de precisión en la UI. Modo "conservador" activado por defecto (menos disparos, más seguros). La Fase 4 con EEG consumer sube la precisión al +90% para usuarios que necesitan máxima fiabilidad.

⚖️
Riesgo 3 · Regulación médica
Claims terapéuticos y clasificación SaMD

Si Bdreams hace claims sobre tratamiento de TEPT o pesadillas crónicas, puede ser clasificado como Software as a Medical Device (SaMD) bajo FDA 510(k) o MDR europeo — lo que implica ensayos clínicos, registro y coste prohibitivo para una fase temprana.

Mitigación

Hasta la Fase 4 los claims se limitan a "wellness" y "entrenamiento de habilidades" — categoría exenta de regulación médica. El protocolo LDT clínico se introduce solo en Fase 4 con IRB y asesoría legal especializada. En Fases 1–3, ningún material menciona diagnóstico ni tratamiento de enfermedades.

🔒
Riesgo 4 · Privacidad onírica
Datos personales de alta sensibilidad

El diario onírico captura contenido psicológico profundo (traumas, emociones, relaciones). Combinado con datos de sueño biométricos, constituye una de las categorías de datos más sensibles que una app puede manejar. Una brecha sería devastadora para la confianza.

Mitigación

Whisper on-device en Fase 3: el audio nunca sale del dispositivo. Cifrado end-to-end del diario en Supabase (pgcrypto). Consentimiento granular: el usuario controla qué datos comparte con la API de análisis. Fase 4: datos de investigación completamente anonimizados con k-anonimidad antes de cualquier exportación. Privacy-first como diferenciador de marca explícito.

La visión de Bdreams

En 18 meses, Bdreams puede pasar de un loop vanilla en el navegador a ser la primera plataforma que conecta el condicionamiento pavloviano diurno, el motor TLR nocturno y el análisis de diario con IA con un estudio clínico publicado detrás. Eso no existe todavía. Ese es el punto.