Análisis — LPDI
Generado por el equipo de agentes PMO | 2026-03-09
Documentos analizados (10)
3. Anexo-2-Plan-Inversion-Productividad_FMT_SDDE-V3-1.pdf
1. Arquitectura_Contenidos_SvelteKit_Supabase_Prisma_Cloudflare_LPDI_v01.pdf
ANALISIS ESTRATEGICO LPDI - COMITE FEBRERO 2026.pdf
ANALISIS ESTRATEGICO LPDI - COMITE FEBRERO 2026.docx
OFERTA DE VALOR LPDI - V2 FEBRERO 2026.docx
ESQUEMA TECNOLOGICO LPDI - V.0 01-JUL-2025.pdf
E.3. ESQUEMA GRAFICO MODELO DE CONSTRUCCION DE ECOSISTEMA LPDI - V.0 01-JUL-2025.pdf
A1. REQUERIMIENTO TECNICO SISTEMA LPDI - V.2 26-FEB-2026.docx
B1. MANUAL SUBSISTEMA CONTENIDOS LPDI - V.1 12-FEB-2026.docx
D1. MANUAL SUBSISTEMA RELACIONAMIENTO LPDI - V.2 26-FEB-2026.docx
Tengo toda la información necesaria. Aquí va el análisis completo: --- # 🔍 ANÁLISIS ESTRUCTURADO — SISTEMA LPDI ## 10 documentos analizados | Febrero-Julio 2026 --- ## DOCUMENTO 1: Análisis Estratégico LPDI — Comité Febrero 2026 *(Versiones .docx y .pdf — contenido idéntico)* ### Resumen Ejecutivo Evaluación estratégica del portafolio LPDI usando Porter, McKinsey-GE y BCG. Conclusión: Relacionamiento es la prioridad #1 de inversión (mercado más atractivo, 4.15/5), Contenidos es quick win (ya en producción), Eventos es "perro" que no justifica inversión independiente. El mayor riesgo competitivo no es otra plataforma sino la inercia (Excel + WhatsApp). ### Módulos/Features identificados | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | 1 | Escalamiento adquisición Contenidos | S | Ya en producción, costo marginal bajo | | 2 | MVP Dashboard Relacionamiento | L | 3-5 métricas clave, piloto con 2-3 redes inversión | | 3 | MVP Matchmaking | L | Sin desarrollo, solo diseño conceptual | | 4 | Monitoreo amenaza Dealroom/Crunchbase | S | Vigilancia competitiva periódica | ### Decisiones pendientes - **D1**: Confirmar Relacionamiento como prioridad #1 de inversión → **Requiere input del comité** - **D2**: Definir hitos de validación para Relacionamiento (MVP 90 días) → **Requiere input de Roberto + Frank** - **D3**: Kill criteria para Eventos como módulo independiente (12 meses) → **Requiere input del comité** - **D4**: Asignación de recursos a Contenidos en paralelo → **Requiere confirmación presupuestal** - **D5**: Plan de contingencia si Dealroom/Crunchbase entran a Latam → **Requiere input estratégico** --- ## DOCUMENTO 2: Oferta de Valor LPDI — V2 Febrero 2026 ### Resumen Ejecutivo Documento comercial que posiciona LPDI como "Hub de información y recursos para el ecosistema de emprendimiento e innovación de Latam, España y EEUU". Define 3 módulos (Contenidos, Relacionamiento, Eventos), segmenta clientes (aceleradoras, redes inversión, gobiernos, corporativos) y estima mercado potencial de $2.4M-$9.6M USD anuales (100-200 organizaciones a $2K-$4K/mes). ### Módulos/Features identificados | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | 1 | Bases de datos públicas (eventos, convocatorias) | M | Ya parcialmente en producción | | 2 | Newsletter personalizado por preferencias | M | Requiere motor de segmentación | | 3 | Widget embebible white-label | M | Para sitios de terceros | | 4 | Directorio de startups con filtros de madurez | L | 4 niveles: BRL, TRL, CRL, TMRL | | 5 | Dashboard de inteligencia del ecosistema | L | 15+ visualizaciones | | 6 | Matchmaking startups-inversionistas | L | Core de diferenciación | | 7 | Gestión de Tech Weeks y super eventos | M | Coordinación multi-evento | | 8 | Networking sessions / Ruedas de negocio | L | Logística + integración con directorio | ### Riesgos - ⚠️ Estimación de mercado ($2.4M-$9.6M) es conservadora pero **no validada con pipeline real** - ⚠️ Modelo de pricing ($2K-$4K/mes) puede ser alto para organizaciones Latam con presupuestos limitados - ⚠️ Dependencia de masa crítica de datos: sin datos suficientes, la propuesta de valor se debilita --- ## DOCUMENTO 3: Esquema Tecnológico — V.0 Julio 2025 ### Resumen Ejecutivo Mapa visual de alto nivel del sistema completo con sus 3 subsistemas y todos los módulos descompuestos. Es un blueprint arquitectónico que muestra la amplitud del sistema: desde scraping hasta ruedas de negocio, pasando por newsletters, bootcamps y one-on-one. Nivel de detalle: naming de módulos, sin especificaciones técnicas. ### Módulos/Features identificados | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | 1 | Registro de usuarios al sistema (multi-perfil) | M | Eje transversal a todo | | 2 | Registro contenidos (en app + embebible) | M | Eventos, convocatorias, noticias, podcasts, videos, informes, decks | | 3 | Notificaciones | S | Push + email | | 4 | Landing de consulta embebible | M | Público, marca blanca | | 5 | Newsletter personalizado + genérico | M | Config + personalización + parametrización envíos | | 6 | Scraping de E&C | M | Automatización captura | | 7 | Automatización RRSS | S | Publicación multicanal | | 8 | Tech Weeks (super eventos) | L | Creación, postulaciones, agenda RT, landing, newsletter específico | | 9 | Gestión de eventos (CRUD + tickets + check-in) | L | WhatsApp integrado, staff, asistentes | | 10 | Bootcamps | M | Submódulo de eventos | | 11 | Networking sessions | M | Perfil, config, participantes, WhatsApp | | 12 | One-on-One | M | Perfil individual/institucional, agenda, comunicación interna | | 13 | Rueda de negocios | L | Perfil, config, agenda, logística, WhatsApp | | 14 | Scouting y Matchmaking | L | Startups, inversionistas, gestores, BD decks | | 15 | Carga/descarga masiva de datos | S | CSV, Excel | | 16 | Dashboard de métricas | M | Transversal | | 17 | Soporte técnico | S | Transversal | ### Riesgos - ⚠️ Alcance **extremadamente amplio** para equipo micro (2 personas). Muchos módulos de tallaje L - ⚠️ Integración WhatsApp aparece en 4 módulos distintos — complejidad subestimada - ⚠️ No hay priorización ni secuencia de implementación en este documento --- ## DOCUMENTO 4: Modelo de Construcción de Ecosistema — V.0 Julio 2025 ### Resumen Ejecutivo Framework conceptual de 4 fases (Mapear → Conectar → Atraer → Crear) con 4 objetivos (Conocimiento, Relaciones, Cooperación, Visibilidad) y 4 resultados medibles (Inversión, Innovación, Inteligencia, Influencia). Es el "porqué" detrás del sistema, no un documento técnico. Útil para validar que cada feature del sistema contribuye a al menos uno de los 4 pilares. ### Módulos/Features — N/A Este es un framework estratégico, no un documento de requerimientos. No genera features adicionales pero sí valida la taxonomía: - **Mapear** → Subsistema Contenidos - **Conectar** → Subsistema Relacionamiento + Eventos (networking, matchmaking) - **Crear** → Contenidos (noticias, podcasts, dashboards) - **Atraer** → Relacionamiento (scouting, softlanding, marca) --- ## DOCUMENTO 5: Requerimiento Técnico — V.2 Febrero 2026 ### Resumen Ejecutivo Documento técnico-funcional que detalla los componentes de los subsistemas de Contenidos y Relacionamiento. Define sistema de usuarios (multi-perfil, multi-auth), formularios dinámicos, panel de control con roles (superadmin, curador, registrador), modales embebibles marca blanca, newsletters (genéricos + personalizados), notificaciones por correo, dashboards de métricas, y módulo de matchmaking (conceptualizado pero sin requerimientos formalizados). ### Módulos/Features identificados | # | Feature | Tallaje | Subsistema | |---|---------|---------|------------| | **SISTEMA DE USUARIOS** | | | | | 1 | Registro multi-perfil (email + Google + Teams + magic link) | M | Transversal | | 2 | Creación masiva de usuarios (solo email) | S | Transversal | | 3 | Descarga masiva de datos (xlsx, csv) | S | Transversal | | 4 | Panel admin de perfil + favoritos + compartir | S | Transversal | | **CONTENIDOS** | | | | | 5 | Formularios dinámicos (eventos, convocatorias, noticias) con lógicas complejas | L | Contenidos | | 6 | Modales embebibles marca blanca (consulta pública) | M | Contenidos | | 7 | Panel de control (CRUD + trazabilidad + roles + permisos especiales) | L | Contenidos | | 8 | Flujo de curaduría (pendiente → aprobado → rechazado → eliminado con papelera 30d) | M | Contenidos | | 9 | Super Eventos (creación, asociación, recategorización) | M | Contenidos | | 10 | Código único automático por registro | S | Contenidos | | 11 | Admin de formularios (agregar/editar/reordenar/eliminar preguntas) | M | Contenidos | | 12 | Newsletters genéricos (2 tipos) | M | Contenidos | | 13 | Newsletters personalizados (automáticos por preferencias) | L | Contenidos | | 14 | Formulario personalización preferencias newsletter | M | Contenidos | | 15 | Sistema notificaciones por correo (12+ tipos de notificación) | M | Contenidos | | 16 | Dashboard de contenidos (métricas + gráficas + cruces) | L | Contenidos | | 17 | Admin fuentes de información (organizadores, convocantes, medios) | M | Contenidos | | **RELACIONAMIENTO** | | | | | 18 | Formulario registro startups (simplificado + detallado) | L | Relacionamiento | | 19 | Formulario registro ICG (inversionistas, corporativos, gestores) | L | Relacionamiento | | 20 | Modales embebibles consulta startups e ICG (marca blanca) | M | Relacionamiento | | 21 | Panel de control Relacionamiento (startups + ICG + trazabilidad) | L | Relacionamiento | | 22 | Verificación de equipos de startups | S | Relacionamiento | | 23 | Dashboard de inteligencia del ecosistema (métricas + gráficas avanzadas) | L | Relacionamiento | | 24 | Módulo Networking y Matchmaking | L | Relacionamiento | | 25 | Restricción de privacidad por tipo de usuario | M | Relacionamiento | ### Riesgos - ⚠️ **Matchmaking**: "La UX está conceptualizada pero falta formalizar los requerimientos técnicos por escrito" — **BLOQUEANTE** para estimar este módulo - ⚠️ Múltiples referencias a instructivos externos no incluidos (diseño formularios, UX pendiente) - ⚠️ Permisos granulares complejos (ICG ven campos que usuarios normales no) ### Decisiones pendientes - **D6**: Formalizar requerimientos técnicos del módulo de Matchmaking → **Requiere input de Frank/Roberto** - **D7**: Definir UX de modales de noticias y formularios de Relacionamiento (marcados como "pendiente") - **D8**: Definir métricas específicas del dashboard de inteligencia (tabla mencionada pero no detallada) --- ## DOCUMENTO 6: Arquitectura Técnica Contenidos — V.04 Julio 2025 ### Resumen Ejecutivo Arquitectura técnica del subsistema de Contenidos: SvelteKit 2 (Svelte 5) + Supabase (PostgreSQL + Auth + Storage + Realtime) + Prisma ORM + Cloudflare CDN/R2. Monolito modular con roadmap de 4 fases (24 semanas). Stack optimizado para equipo de 1-5 devs. Incluye modelo de datos, componentes detallados, decisiones arquitectónicas documentadas y consideraciones de seguridad. ### Módulos/Features identificados | # | Feature | Tallaje | Fase | |---|---------|---------|------| | 1 | Setup proyecto (SvelteKit + Supabase + Prisma + Tailwind + shadcn) | M | F1 | | 2 | Auth completo (email, OAuth, magic links, RLS, roles) | M | F1 | | 3 | Modelos Prisma core (Content, Tag, Media, UserProfile, ContentVersion) | M | F1 | | 4 | Admin panel CRUD + editor TipTap + Superforms | M | F1 | | 5 | Landing pública SSR + búsqueda básica | S | F1 | | 6 | RLS en PostgreSQL | S | F1 | | 7 | Newsletter con Resend + Svelte Email | M | F2 | | 8 | Push notifications (OneSignal web) | S | F2 | | 9 | Widget embebible (Svelte Custom Element) | M | F2 | | 10 | Búsqueda avanzada (Meilisearch) | M | F2 | | 11 | Scraping con Firecrawl API | M | F3 | | 12 | Automatización RRSS (Buffer) | S | F3 | | 13 | Carga/descarga masiva CSV/Excel | S | F3 | | 14 | Flujo editorial completo (estados + permisos) | M | F3 | | 15 | App móvil (Capacitor iOS + Android) | M | F4 | | 16 | Push nativo Capacitor + OneSignal | S | F4 | | 17 | Dashboard analytics + Supabase Realtime | L | F4 | | 18 | Reportes PDF/Excel | S | F4 | | 19 | Sugerencia automática de tags (NLP) | M | F4 | | 20 | A/B testing newsletters (Resend) | S | F4 | ### Riesgos - ⚠️ Documento marcado como "BORRADOR v0.04" — no es versión final validada - ⚠️ Roadmap de 24 semanas diseñado para equipo de 1-5 devs humanos — **equipo actual es micro (2 personas)** - ⚠️ Prisma bypasea RLS por defecto — se documenta doble capa de seguridad pero requiere disciplina de implementación ### Decisiones pendientes - **D9**: Validar este documento con equipo y stakeholders (explícitamente mencionado en "Próximos pasos") - **D10**: Confirmar Cloudflare R2 vs Supabase Storage para media pesado (decisión postergada a futuro) --- ## DOCUMENTO 7: Plan de Inversión Productividad (PIP) — SDDE ### Resumen Ejecutivo Formato de solicitud de cofinanciación ante la SDDE (Secretaría de Desarrollo Económico de Bogotá). LPDI S.A.S. (NIT 901.481.576-1, microempresa, Teusaquillo) solicita $10M COP del bono + $10M contrapartida = $20M COP totales. Objetivos: automatizar scraping (400 fuentes), dashboard de métricas (10 métricas), optimizar UX (2 formularios rediseñados). Plazo: 8 semanas. Equipo: Frank Prieto (líder) + Roberto Aguirre (desarrollador) + Daniel Gordillo (RRPP). ### Módulos/Features (alcance PIP — subconjunto del sistema) | # | Feature | Tallaje | Objetivo PIP | |---|---------|---------|--------------| | 1 | Scripts scraping de 400 fuentes de información | L | Obj 1 | | 2 | Dashboard de analíticas privadas (10 métricas, mapas de calor) | L | Obj 2 | | 3 | Rediseño UX formularios startups e inversionistas | M | Obj 3 | | 4 | Interfaz de matchmaking (UX) | M | Obj 3 | ### Riesgos - ⚠️ **Plazo de 8 semanas para 3 objetivos ambiciosos** con equipo de 2 personas - ⚠️ Meta de 50 startups+inversionistas registradas en 2 meses post-implementación — depende de esfuerzo comercial no contemplado - ⚠️ Scraping de 400 fuentes es complejo: cada fuente puede tener estructura diferente ### Datos clave para contexto - Base de datos existente: +2,500 eventos + 570 convocatorias históricas - Aliados: Fomo (API de eventos), Startco, Colombia Tech Week, Perú Tech Week - Financiamiento: $10M COP SDDE + $10M COP contrapartida --- ## DOCUMENTO 8: Manual Subsistema Contenidos — V.1 Febrero 2026 ### Resumen Ejecutivo Manual funcional exhaustivo (~114K chars) del subsistema de Contenidos. Detalla campo por campo los formularios de eventos (30+ campos con lógicas), convocatorias (30+ campos), noticias (15+ campos), newsletters genéricos (2 tipos: eventos+convocatorias y noticias+insights), formulario de personalización de newsletter, directorios (organizadores, convocantes, medios de comunicación con sistema de calidad). Nivel de detalle: tipo de campo, placeholder, advertencias, validaciones, observaciones por campo. ### Módulos/Features identificados (detalle granular) | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | 1 | Formulario dinámico Eventos (7 paneles, 30+ campos, lógicas condicionales) | L | Incluye geolocalización Google Maps, zonas horarias, multi-organizador, temáticas jerárquicas | | 2 | Formulario dinámico Convocatorias (similar complejidad a Eventos) | L | Industrias jerárquicas, tipos de convocatoria, multi-convocante | | 3 | Formulario dinámico Noticias (3 paneles, 15+ campos) | M | Tags dinámicos, nichos de interés, medios de comunicación | | 4 | Modal consulta pública Eventos (6+ filtros, búsqueda, favoritos) | M | Filtros combinables, no sensible a tildes/mayúsculas | | 5 | Modal consulta pública Convocatorias (6+ filtros) | M | Similar a eventos | | 6 | Modal consulta pública Noticias (4+ filtros, tags populares) | M | Similar estructura | | 7 | Newsletter genérico Eventos+Convocatorias (form de config + envío) | M | Selección de contenido, imagen, preview, prueba, programación | | 8 | Newsletter genérico Noticias+Insights (form de config + envío) | M | Insights: evento, podcast, video, informe, custom | | 9 | Formulario personalización preferencias newsletter | M | Cruce automático preferencias-contenido | | 10 | Directorio organizadores de eventos | S | Admin interno | | 11 | Directorio convocantes | S | Admin interno | | 12 | Directorio medios de comunicación (con sistema de calidad ponderada) | M | Evaluación multi-criterio | | 13 | Sistema de creación automática de usuarios desde formularios | M | Si email no existe, crea cuenta | ### Riesgos - ⚠️ Nivel de detalle de lógicas de formularios es **extremadamente granular** — cada campo tiene 3-8 observaciones. Riesgo de sobre-especificación que dificulte implementación ágil. - ⚠️ Lógicas de zonas horarias + ubicación Google Maps + validaciones cruzadas entre campos son complejas --- ## DOCUMENTO 9: Manual Subsistema Relacionamiento — V.2 Febrero 2026 ### Resumen Ejecutivo Manual funcional más extenso (~151K chars) del subsistema de Relacionamiento. Detalla: formulario simplificado de startups (registro rápido + confirmación email + invitación a detallado), formulario detallado de startups (15+ paneles con campos de madurez BRL/TRL/CRL/TMRL, equipo, necesidades granulares), formulario de ICG (inversionistas/corporativos/gestores — campos de propuesta de valor, tesis de inversión, tickets), modales de consulta pública con restricciones de privacidad por nivel de usuario, fichas técnicas detalladas. ### Módulos/Features identificados (detalle granular) | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | 1 | Formulario simplificado startups (6 campos + auth) | M | Registro rápido, confirmación, auto-creación usuario | | 2 | Formulario detallado startups (15+ paneles, 80+ campos) | L | BRL, TRL, CRL, TMRL, equipo, necesidades (20+ subcategorías), deck, video pitch | | 3 | Formulario registro ICG (15+ paneles, 80+ campos) | L | Propuesta de valor (correlación con necesidades startups), tesis de inversión, fuentes de inversión/financiamiento | | 4 | Modal consulta pública Startups (10+ filtros, 3 niveles de acceso) | L | Filtros primarios + secundarios + exclusivos por tipo usuario | | 5 | Modal consulta pública ICG (10+ filtros, 3 niveles de acceso) | L | Misma lógica de acceso escalonado | | 6 | Ficha técnica detallada Startup | M | Modal expandido con toda la info | | 7 | Ficha técnica detallada ICG | M | Modal expandido con toda la info | | 8 | Sistema de privacidad escalonada (público, registrado, ICG/startup) | M | 3 niveles de visibilidad por campo | | 9 | Matchmaking basado en correlación necesidades-propuesta | L | ⚠️ Requerimientos técnicos pendientes | | 10 | Verificación de equipo de startup (validación miembros) | M | Invitaciones por email, tracking | | 11 | Niveles de madurez (BRL 1-9, TRL 1-9, CRL 1-9, TMRL 1-9) | M | 4 ejes × 9 niveles = taxonomía compleja | | 12 | Favoritos + Contactar (cross-subsistema) | S | Integración con networking | ### Riesgos - ⚠️ **Correlación necesidades startup ↔ propuesta de valor ICG** es el corazón del matchmaking. Las subcategorías están definidas pero no hay algoritmo especificado - ⚠️ 4 frameworks de madurez (BRL, TRL, CRL, TMRL) con 9 niveles cada uno — complejidad alta para que usuarios lo completen - ⚠️ Formularios de 80+ campos pueden generar abandono alto — ya se mitiga con formulario simplificado pero el detallado es crítico para matchmaking --- ## ⚠️ INCONSISTENCIAS DETECTADAS ENTRE DOCUMENTOS 1. **BCG vs Resumen Ejecutivo**: El resumen ejecutivo del análisis estratégico dice "Contenidos es una vaca lechera en construcción" pero la matriz BCG lo clasifica como **Interrogante** (no vaca lechera). Inconsistencia menor pero confusa. 2. **Eventos — alcance contradictorio**: El análisis estratégico recomienda "NO invertir como módulo independiente" y "postergar", pero el Esquema Tecnológico (V.0 Jul 2025) muestra un módulo de Eventos completo con Tech Weeks, bootcamps, ruedas de negocios, networking sessions y one-on-one — un alcance enorme. **No hay documento de requerimientos técnicos para Eventos**, lo cual es coherente con la recomendación de postergar, pero el esquema tecnológico no refleja esta decisión. 3. **Equipo y capacidad**: La Arquitectura Técnica asume "equipo de 1-5 devs" con roadmap de 24 semanas. El PIP declara equipo de 2 personas (Frank + Roberto) con plazo de 8 semanas para un subconjunto. El análisis estratégico menciona "recursos limitados, equipo pequeño". **No hay plan de staffing ni de uso de agentes IA** como capacidad de desarrollo, a pesar de que la MEMORY.md lo menciona como contexto. 4. **Matchmaking — gap documental**: Es la feature más estratégica según todos los documentos, pero los requerimientos técnicos dicen explícitamente "La UX está conceptualizada pero falta formalizar los requerimientos técnicos por escrito". **El módulo más importante es el menos especificado.** 5. **Stack tecnológico — arquitectura solo para Contenidos**: Existe documento de arquitectura detallado (SvelteKit+Supabase+Prisma) solo para el subsistema de Contenidos. **No hay documento de arquitectura para Relacionamiento**, que es la prioridad #1. --- # 📊 VISTA CONSOLIDADA ## Total de Módulos/Features con Distribución de Tallaje | Tallaje | Cantidad | % | |---------|----------|---| | **S (Small)** | 18 | 25% | | **M (Medium)** | 33 | 46% | | **L (Large)** | 21 | 29% | | **TOTAL** | **72** | 100% | > ⚠️ **21 features de tallaje L** para un equipo micro de 2 personas es un indicador de riesgo alto de scope creep. ## Top 3 Riesgos | # | Riesgo | Impacto | Probabilidad | |---|--------|---------|--------------| | **1** | **Matchmaking sin especificación técnica**: Es el feature que más diferencia a LPDI y justifica precios premium, pero no tiene requerimientos formalizados ni algoritmo definido. Sin esto, Relacionamiento no puede ser MVP. | Crítico | Alta | | **2** | **Alcance masivo vs capacidad de ejecución**: 72 features (21 Large) con equipo de 2 personas + bono limitado ($20M COP / ~$5K USD). El PIP compromete entregables en 8 semanas que son subconjuntos pequeños del total. No hay plan de priorización end-to-end. | Crítico | Alta | | **3** | **Inercia como competidor principal**: Todos los documentos coinciden en que el enemigo es "Excel+WhatsApp+así siempre lo hemos hecho". Si los formularios son demasiado complejos (80+ campos en startups) o la UX no reduce fricción dramáticamente, LPDI pierde contra la inercia que dice combatir. | Alto | Media | ## Decisiones Críticas Bloqueantes | # | Decisión | Quién decide | Bloquea | |---|----------|--------------|---------| | **D1** | Formalizar requerimientos técnicos del módulo de Matchmaking (algoritmo de correlación necesidades↔propuesta de valor) | Frank + Roberto | MVP Relacionamiento entero | | **D2** | Confirmar secuencia de inversión: ¿Contenidos primero (quick win) o Relacionamiento primero (big bet)? Los docs dicen ambas cosas simultáneamente | Comité | Roadmap y asignación de recursos | | **D3** | Definir arquitectura técnica del subsistema de Relacionamiento (¿mismo stack SvelteKit+Supabase? ¿schema compartido o separado?) | Roberto | Inicio de desarrollo | | **D4** | Alcance del PIP vs alcance total: ¿las 8 semanas del bono SDDE se enfocan en scraping+dashboard+UX como dice el PIP, o se reordena para priorizar Relacionamiento como dice la estrategia? | Frank + Roberto | Ejecución del bono | | **D5** | Kill criteria formal para Eventos: ¿se posterga toda inversión o se implementan features mínimas (publicación de eventos en Contenidos)? | Comité | Scope del esquema tecnológico |