Día 1 -- Estrategia y arquitectura desde cero

### Lunes, 9:00 AM -- La pizarra en blanco

Llegas a la oficina de StreamVibe -- un espacio de coworking en Malasaña con plantas, café de especialidad y una pizarra enorme que nadie usa. Marta te intercepta antes de que te sientes: "He conseguido reunión con Meridian Capital el viernes a las 11:00. Son el fondo que invertió en Filmin en su día. Si les muestro tracción real -- usuarios que vuelven, engagement creciendo, contenido que funciona -- tenemos la Serie A. ¿Puedes tener algo para entonces?"

Cinco días. Para ir de cero absoluto a un dashboard con métricas reales que un VC pueda mirar y decir "está startup tiene product-market fit". En SmartFactory habrías dicho "necesito un sprint de discovery y otro de implementación". Pero esto es una startup de 30 personas con 8 meses de runway. No hay sprints. No hay Jira. Hay un deadline real y una CEO que necesita cerrar financiación para que la empresa sobreviva.

Lo primero es lo primero. Antes de escribir una sola línea de código, necesitas responder tres preguntas fundamentales: ¿qué vamos a medir? ¿con qué arquitectura? ¿cuánto va a costar? En TaskFlow aprendiste que las métricas equivocadas son peor que no tener métricas -- porque te hacen tomar decisiones equivocadas con falsa confianza. Y en NeoBank aprendiste que una hora de diseño te ahorra una semana de reescritura.

### Paso 1: ¿Qué métricas quiere un inversor de streaming?

Tu experiencia en TaskFlow te enseñó a pensar como un Product Manager. Un inversor de Serie A en una plataforma de streaming de contenido on-demand quiere ver exactamente 5 cosas, en este orden de importancia:

1. 01.CRECIMIENTO: DAU y MAU creciendo mes a mes. Ratio DAU/MAU (stickiness) idealmente > 20%. Demuestra que el producto es parte del hábito del usuario.
2. 02.RETENCIÓN: Curva de retención D1/D7/D30 por cohorte. Si D7 > 35% en contenido on-demand, la historia es "los usuarios vuelven". Eso es oro para un VC.
3. 03.ENGAGEMENT: Watch time total y por usuario. Sesión media > 20 min indica producto sticky. Completion rate > 60% indica que el contenido es bueno.
4. 04.MONETIZACIÓN: Tasa de conversión free->premium, churn mensual < 5%, ARPU, LTV estimado. El inversor quiere ver un modelo económico que funciona.
5. 05.CONTENIDO: Qué contenido impulsa retención y conversión. Esto diferencia StreamVibe de "otro streaming más".

Para el viernes, Marta necesita al menos los tres primeros con datos reales. Monetización se puede contar con los datos de subscriptions que ya existen. Contenido es el bonus que dejará a Meridian con la boca abierta si lo tienes.

### Paso 2: ¿Qué datos tenemos para calcular esas métricas?

Revisas la base de datos de producción (en modo lectura, con la réplica que Daniel te ha dado). La tabla playbacks es tu mina de oro: tiene 3 millones de filas con user_id, content_id, started_at, ended_at, watch_seconds y un flag completed. No es perfecta -- le falta contexto (dispositivo, calidad, sesión) -- pero tiene lo esencial para calcular DAU, retention y engagement con datos históricos de 14 meses.

1-- Exploración rápida de la tabla playbacks (en la réplica de lectura)
2SELECT 
3    MIN(started_at) AS primera_reproduccion,
4    MAX(started_at) AS ultima_reproduccion,
5    COUNT(*) AS total_playbacks,
6    COUNT(DISTINCT user_id) AS usuarios_unicos,
7    COUNT(DISTINCT content_id) AS contenidos_vistos,
8    AVG(watch_seconds) AS avg_watch_seconds,
9    SUM(CASE WHEN completed THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS pct_completados
10FROM playbacks;
11
12-- Resultado:
13-- primera_reproduccion: 2023-01-15
14-- ultima_reproduccion: 2024-03-15 (hoy)
15-- total_playbacks: 3.147.892
16-- usuarios_unicos: 38.421
17-- contenidos_vistos: 1.089
18-- avg_watch_seconds: 1.847 (~31 min)
19-- pct_completados: 42.3%

Esto es suficiente. Con la tabla playbacks calculas DAU/MAU (usuarios que reproducen por día/mes). Con playbacks + users calculas retention por cohorte de registro. Con playbacks + content calculas engagement y completion por tipo de contenido. No necesitas event tracking sofisticado para el MVP del viernes -- necesitas extraer estos datos de producción sin matar la base.

### Paso 3: Diseñar la arquitectura -- las restricciones

Las restricciones que definen tu diseño son claras:

• ▹PRESUPUESTO: Máximo 15 EUR/mes. StreamVibe tiene 8 meses de runway y cada euro cuenta.
• ▹EQUIPO: Tú solo. Nadie más va a mantener esto. Si es complejo, se rompe y no hay quien lo arregle.
• ▹VOLUMEN: 15K MAU, ~7K reproducciones/día actuales. Modesto. No necesitas Spark ni Kafka.
• ▹PRODUCCIÓN INTOCABLE: Daniel no te deja hacer queries pesadas en prod. Tienes una réplica de lectura.
• ▹TIEMPO: 5 días para el MVP. No puedes pasar 3 días configurando Airflow o Kubernetes.
• ▹ESCALABILIDAD FUTURA: Si la Serie A sale bien, 10x usuarios en 6 meses. El diseño debe poder escalar sin reescritura total.

### La arquitectura: pragmatismo absoluto

En NeoBank usabas Spark, Redshift y Airflow. En SmartFactory, Kafka con 5 brokers y Iceberg. Aquí no necesitas nada de eso. La tentación del senior es sobreingeniería -- aplicar el stack del trabajó anterior al problema actual. Resiste esa tentación. El stack correcto para StreamVibe hoy es el más simple posible que resuelva el problema:

### Justificación de cada decisión

ETL -- Python scripts con cron. ¿Por qué no Airflow? Porque eres una persona sola. Airflow necesita Docker, un scheduler, un webserver, una base de metadatos y supervisión. Para 3-4 scripts que corren una vez al día, cron es perfecto. Tiene 50 años de historia y nunca falla. Cuando tengas 20+ pipelines y un equipo de 3 personas, migras a Airflow en un día (ya lo has hecho antes, en SmartFactory).

Lake -- S3 con formato Parquet organizado en zonas raw/silver/gold. Es el estándar de la industria que conoces desde FlashRoute. Cuesta céntimos por GB, cualquier herramienta del ecosistema sabe leer Parquet de S3, y la estructura de zonas te permite tener datos crudos siempre disponibles para reprocesar si algo sale mal.

Analytics -- DuckDB. Esta es la decisión más contraintuitiva para alguien que viene de Redshift (NeoBank) o Spark (SmartFactory). Pero para 15K usuarios y 7K reproducciones diarias, DuckDB lee Parquet de S3 directamente, es columnar, gratuito, single-binary y procesa 10 millones de filas en menos de un segundo. No necesitas un cluster para esto. Cuando llegues a 500K eventos/día (post Serie A), migras a Redshift Serverless en 2 horas -- el SQL es compatible.

BI -- Metabase open source. Ya está instalado (Daniel lo puso hace 6 meses para queries ad-hoc). Es gratuito, soporta SQL nativo y Custom Questions, dashboards con filtros y auto-refresh. Para una startup de 30 personas es más que suficiente. No necesitas Looker (1000 EUR/mes) ni Tableau (70 EUR/usuario/mes).

Lo que hace especial a está arquitectura no es ninguno de sus componentes por separado -- es la COHERENCIA del conjunto. Cada pieza habla con la siguiente de forma natural: PostgreSQL exporta CSV/Parquet que Python lee, Python escribe Parquet en S3, DuckDB lee Parquet de S3 directamente, Metabase conecta a DuckDB por JDBC. No hay pegamento frágil entre piezas. No hay 15 herramientas que configurar. Es un flujo lineal y predecible que una persona puede entender, mantener y debuggear sola.

### La reunión con Daniel -- convencer sin amenazar

A las 14:00 te sientas con Daniel en la sala pequeña. Necesitas que te dé acceso a una réplica de lectura de PostgreSQL y que su equipo no bloquee tu trabajó. La clave que aprendiste en AdPulse sobre gestión de stakeholders técnicos: no les digas lo que VAN a hacer, pregúntales cómo PREFIEREN que lo hagas.

Le presentas tu plan en 3 minutos:

1. 01."Necesito leer datos de la base para calcular métricas. NO voy a escribir en prod ni hacer queries pesadas."
2. 02."Lo ideal es una réplica de lectura. Si ya tienes una, perfecto. Si no, la monto en 20 minutos con RDS."
3. 03."Voy a extraer datos una vez al día a las 3 AM (cuando no hay tráfico) y volcarlos a S3 en Parquet."
4. 04."Nunca voy a conectar Metabase directamente a producción. Apuntará a DuckDB con datos ya procesados."
5. 05."Si en algún momento necesito algo del equipo de backend, te lo pido con 24h de antelación y con scope exacto."

Daniel respira aliviado. "Perfecto. Ya hay una réplica de lectura -- la monté para los backups nocturnos pero nadie la usa. Te doy el connection string. Y gracias por no querer tocar prod directamente, el anterior candidato que entrevistamos quería conectar Tableau directo a la base de producción y casi me da algo."

### Plan de escalabilidad -- cuándo migrar cada pieza

Rafa te pregunta: "¿Y si la ronda sale bien y pasamos de 15K a 150K MAU en 6 meses?" Buena pregunta. Tu respuesta documenta los puntos de quiebre:

En SmartFactory aprendiste a pensar siempre en "qué pasa cuando esto crezca 10x". No para construir hoy para 10x (sobreingeniería), sino para SABER qué vas a tener que cambiar y cuánto va a costar. Eso te permite decirle a Daniel con confianza: "Este stack funciona para los próximos 6-8 meses. Sé exactamente qué cambiar cuando sea el momento, y ningún cambio requiere reescritura completa."

La clave de una buena arquitectura de datos para startup no es que sea perfecta -- es que sea MODULAR. Cada pieza se puede reemplazar independientemente sin afectar al resto. Si mañana DuckDB no es suficiente, cambias a Redshift sin tocar el pipeline de ingesta ni el dashboard. Si cron se queda corto, migras a Airflow sin tocar la lógica de transformación. Esto lo aprendiste en NeoBank: "desacoplamiento es la mejor inversión en arquitectura".

1# Plan de escalabilidad documentado
2SCALE_TRIGGERS = {
3    "cron_to_airflow": {
4        "trigger": "Más de 15 pipelines o equipo > 2 personas",
5        "effort": "1 semana",
6        "cost_delta": "+20 EUR/mes (Docker en EC2)",
7    },
8    "duckdb_to_redshift": {
9        "trigger": "Más de 100M filas acumuladas o > 3 analistas concurrentes",
10        "effort": "2 horas (cambiar connection string)",
11        "cost_delta": "+50-150 EUR/mes",
12    },
13    "postgres_to_kinesis": {
14        "trigger": "Más de 500K eventos/día o necesidad de real-time",
15        "effort": "1 semana",
16        "cost_delta": "+30 EUR/mes",
17    },
18    "metabase_to_looker": {
19        "trigger": "Más de 50 usuarios de BI o necesidad de gobernanza",
20        "effort": "2-3 semanas (migrar dashboards)",
21        "cost_delta": "+1000 EUR/mes",
22    },
23}
24
25# Estimación de cuándo se activan con crecimiento 10x post Serie A:
26# - cron -> Airflow: mes 3-4 post ronda (cuando contrates al 2o DE)
27# - DuckDB -> Redshift: mes 6-8 (cuando acumules >100M filas)
28# - PG -> Kinesis: mes 4-5 (cuando implementes event tracking real-time)
29# - Metabase -> Looker: mes 12+ (cuando el equipo de analytics crezca a 5+)

### Resumen del Día 1

• ▹Definiste las 5 métricas clave para inversores: DAU/MAU, retention, engagement, monetización, contenido
• ▹Verificaste que los datos históricos (3M playbacks, 14 meses) son suficientes para el MVP
• ▹Diseñaste arquitectura completa a 12 EUR/mes: PostgreSQL replica -> Python/cron -> S3 Parquet -> DuckDB -> Metabase
• ▹Documentaste justificación de cada componente con plan de escalabilidad (cuándo y cómo migrar)
• ▹Convenciste a Daniel de darte acceso a la réplica sin fricciones
• ▹Tienes todo listo para implementar mañana: acceso a datos, diseño claro, herramientas identificadas