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. Tasa de finalización: la banda general del sector está en 30-40%, y por encima del 50% es excelente para contenido curado.
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.

## Las tres preguntas que hay debajo de cada cifra

Cuando le enseñas una métrica a alguien que decide con ella, hay tres cosas que tiene que poder contestar, y si no las tienes preparadas la conversación se te va de las manos. ¿Sobre quién está calculada? Una retención del 38% no significa nada hasta que se dice de quién: ¿de los que se registraron, o de los que llegaron a ver algo? Las dos son legítimas y la segunda siempre sale más alta; elige la que puedas defender y di cuál es al lado del número. ¿Con cuánta gente? Una cohorte de treinta personas da una curva preciosa y no significa nada: por debajo de un par de cientos, la curva se mueve más por azar que por producto, y si tus cohortes son pequeñas, agrúpalas por mes en vez de por semana. ¿Comparado con qué? Un 42% de finalización no es bueno ni malo hasta que hay una referencia del sector al lado -- y la referencia hay que traerla tú, porque un inversor de streaming las conoce y así la conversación pasa de "demuéstrame que esto es bueno" a "hablemos de por qué".

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

Esto lo haces por la tarde, no ahora: la réplica te la da Daniel a las 14:00, y hasta entonces no tienes con qué mirar. Lo apuntas aquí porque es el siguiente paso en cuanto tengas la conexión -- primero se negocia el acceso, después se miran los datos. La tabla playbacks es tu mina de oro: acumula unos 3,8 millones de reproducciones, aunque sólo se conservan las de las últimas 3 semanas (un cron de Daniel borra lo anterior para que la base no crezca sin control). Trae user_id, content_id, started_at, ended_at, watch_seconds y un flag completed. Le falta contexto -- calidad de reproducción, o en qué punto exacto abandonó alguien -- pero tiene lo esencial para calcular DAU, retención corta y engagement con comportamiento real.

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: 2024-09-23
14-- ultima_reproduccion: 2024-10-14 (hoy)
15-- total_playbacks: 165.751
16-- usuarios_unicos: 14.270
17-- contenidos_vistos: 1.089
18-- avg_watch_seconds: 1.847 (~31 min)
19-- pct_completados: 45.2%

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:

• ▹Máquina pequeña donde corren los tres scripts: 10 EUR/mes
• ▹Almacenamiento en S3 (menos de 5 GB): ~0,15 EUR/mes
• ▹DuckDB, Python y cron: 0 EUR (libres)
• ▹Metabase: 0 EUR -- ya está instalado y se queda donde está; sólo cambia a qué apunta
• ▹Réplica de lectura: 0 EUR para nuestro presupuesto -- la instancia ya existe y la paga infraestructura. Ojo con leer eso como "es gratis": no lo es, simplemente lo paga otro. Cuando la pidas, sabe que estás pidiendo dinero de alguien, no un favor
• ▹TOTAL que pido: unos 11 EUR/mes, sobre un techo de 15

Y una ausencia deliberada en el dibujo: los logs del reproductor en CloudWatch no están. Existen, pero son de formato libre y no estructurado, y meterlos esta semana costaría más de lo que aportan cuando ya tienes los eventos de reproducción en la base. Se quedan fuera a propósito, y eso es una decisión, no un olvido: cuando alguien pregunte por la calidad de reproducción o por los errores del player, ahí es donde habrá que ir a buscarlos.

## Elegir barato y elegir simple no son lo mismo

Antes de justificar pieza por pieza, ordena los dos motivos, porque vas a tener esta conversación en cualquier startup. A este tamaño, guardar los datos no cuesta nada en ninguna parte: cinco gigas son céntimos en cualquier sitio. Lo que cambia entre unas herramientas y otras no es el almacenamiento, es cómo se cobra el cálculo: hay motores que cobran por lo que consultas y se apagan solos cuando nadie los usa, y otros que cobran por estar encendidos y cuestan lo mismo un martes que un domingo. Con los primeros, a este volumen, la factura es de unos euros; con los segundos, de cientos, hagas lo que hagas. Así que el precio sí es un argumento, pero sólo si comparas opción por opción y dices cuál es cuál: si lo resumes en "lo nuestro cuesta once euros y lo otro cuatrocientos", alguien mira la letra pequeña y el argumento se te cae.

El argumento que aguanta es otro: cuántas cosas hay que mantener y quién las mantiene. Un almacén gestionado añade una cuenta, unos permisos, un modelo de coste que hay que vigilar y una herramienta más que aprender, y tú eres una persona sola con cinco días. Un motor embebido y unos ficheros en un cubo caben en tu cabeza y en tu portátil. La diferencia se nota cuando la empresa crece: el precio se multiplica por diez y sigue siendo pequeño, pero el número de piezas que mantener se multiplica por diez y deja de serlo. Por eso los disparadores de migración que escribes hoy son por volumen y por personas, no por euros.

## 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.

## Decisión: qué datos personales entran en el lake

Esta decisión se toma hoy porque el lunes es gratis y el jueves ya no. En cuanto el pipeline haya escrito una semana de datos, sacar una columna del lake significa reprocesar; y en cuanto alguien haya construido un panel encima, significa además discutirlo. Lo que hay encima de la mesa: el fichero de usuarios trae veinte mil correos electrónicos y el nombre visible, el de pagos trae el método de pago de cada suscripción, y el de reproducciones trae el historial de visionado completo de cada persona.

La pregunta que decide lo primero es de dos minutos: por qué campo se cruzan los ficheros entre sí. Si las suscripciones y los pagos se unen al padrón por identificador de usuario -- y se unen -- entonces el correo no hace falta en el lake y se queda en la base de datos de la aplicación, donde sí se usa para escribir a la gente. Si resultara ser la clave de unión, la decisión sería otra: entraría, pero en una zona con acceso restringido y nunca en las tablas de métricas. Con el método de pago, lo mismo: el importe y el plan hacen falta para calcular ingresos, el método de pago no lo necesita ninguna métrica de la semana y arrastra sus propias obligaciones. Se queda fuera.

• ▹Cuánto se guarda (hay que cerrarlo con Marta, porque es una decisión de negocio). Una propuesta razonable: el historial al detalle doce meses, y de ahí hacia atrás agregado por mes. Doce meses es una decisión de negocio, no un plazo legal, y se escribe con su motivo: qué métricas hay que poder recalcular hacia atrás. Y con lo que se pierde escrito al lado, porque se pierde algo: con el detalle agregado ya no se pueden rehacer cohortes de más de un año ni una retención a siete días de una cohorte antigua, y las dos están en el catálogo de métricas. Lo que se gana, y es lo que hace barata la política, es que el agregado por mes ya no identifica a nadie.
• ▹Quién puede ver qué (hay que cerrarlo con Daniel, que es quien da los accesos). Una fila por fichero: qué datos personales contiene y quién tiene acceso. Va en el modelo de acceso del documento de estrategia, no en el catálogo de métricas, porque esto no son métricas.
• ▹Y qué pasa si alguien pide que borren sus datos. Para contestarlo hay que saber, ANTES de que pase, en qué ficheros del lake aparece el identificador de esa persona. Eso es un catálogo de datos, y es la única razón por la que un catálogo pasa de ser buena práctica a ser urgente.

## 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

Daniel te pregunta: "¿Y si la ronda sale bien y pasamos de 15K a 150K MAU en 6 meses?" Es la pregunta que hace un CTO cuando alguien le propone un stack barato, y es buena. 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": "Mas de 100M filas de eventos acumuladas, o mas de 5 personas "
10                   "consultando el dashboard a la vez de forma habitual",
11        "effort": "2 horas (cambiar connection string)",
12        "cost_delta": "+50-150 EUR/mes",
13    },
14    "postgres_to_kinesis": {
15        "trigger": "Más de 500K eventos/día o necesidad de real-time",
16        "effort": "1 semana",
17        "cost_delta": "+30 EUR/mes",
18    },
19    "metabase_to_looker": {
20        "trigger": "Más de 50 usuarios de BI o necesidad de gobernanza",
21        "effort": "2-3 semanas (migrar dashboards)",
22        "cost_delta": "+1000 EUR/mes",
23    },
24}
25
26# Cuando se activa cada trigger. El SUPUESTO manda, asi que va escrito al lado:
27# una estimacion sin supuesto no se puede discutir ni corregir.
28#
29# - cron -> Airflow: cuando haya un segundo data engineer o mas de 15 pipelines.
30#   (Con una persona y 3 scripts, Airflow es mas trabajo que el que ahorra.)
31#
32# - PG -> Kinesis: cuando se implemente event tracking en tiempo real. Ojo: ese
33#   mismo cambio multiplica por decenas las filas al dia, asi que ADELANTA el
34#   trigger de DuckDB de abajo.
35#
36# - DuckDB -> Redshift: hay que separar los dos motivos, porque dan fechas muy
37#   distintas.
38#     Por VOLUMEN: hoy entran ~7.400 filas/dia. Aun suponiendo que la ronda
39#     salga y el trafico crezca 10x en 6 meses (74.000/dia), de 3,8M a 100M
40#     hay mas de dos anos. Antes del ano 2 no pasa, salvo que se implemente
41#     el event tracking de arriba.
42#     Por CONCURRENCIA: mucho antes. En cuanto marketing y contenido usen el
43#     dashboard a diario, DuckDB embebido se queda corto.
44#   Y esa es la leccion: el trigger que se cumple primero casi nunca es el que
45#   uno esperaba.
46#
47# - Metabase -> Looker: cuando el equipo de analytics pase de 5 personas.

## Resumen del Día 1

• ▹Definiste las 5 métricas clave para inversores: DAU/MAU, retention, engagement, monetización, contenido
• ▹Comprobaste qué histórico hay de verdad -- tres semanas de reproducciones, no catorce meses -- y apuntaste qué métricas se pueden calcular con eso y cuáles no
• ▹Diseñaste la arquitectura completa por ~11 EUR/mes (techo: 15): PostgreSQL replica -> Python/cron -> S3 Parquet -> DuckDB -> Metabase
• ▹Documentaste justificación de cada componente con plan de escalabilidad (cuándo y cómo migrar)
• ▹Decidiste qué datos personales NO entran en el lake, y dejaste escritas las tres que necesitan una conversación: cuánto se guarda el historial, quién lo ve y cómo se borraría a petición
• ▹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