7. Stage del Proyecto y Deployment

Descripción

En esta cápsula vas a entender cómo el stage de tu proyecto (MVP, Growth, Scale) cambia la estrategia de deployment recomendada. La misma app AI puede necesitar una estrategia diferente cuando tiene 10 usuarios que cuando tiene 10,000. Al terminar, sabrás cuándo y cómo evolucionar tu deployment sin reescribir todo.

Contexto: La decision matrix de la cápsula anterior evalúa tu situación actual. Pero las situaciones cambian. Un MVP que arranca en Railway puede necesitar migrar a AWS cuando crece. Esta cápsula te prepara para esas transiciones — y te dice cuándo NO migrar (porque muchos migran prematuramente).

Los Tres Stages de un Proyecto AI

MVP (Minimum Viable Product)

Usuarios:     1-100
Tráfico:      <1K requests/día
Equipo:       1-2 developers
Presupuesto:  $0-50/mes
Objetivo:     Validar que la idea funciona
Duración:     1-3 meses

En MVP, tu prioridad es velocidad de iteración. No estás optimizando para escala — estás descubriendo si tu producto tiene sentido. Cada hora que pasas configurando infraestructura es una hora que no pasas hablando con usuarios o mejorando prompts.

Growth (Crecimiento)

Usuarios:     100-10,000
Tráfico:      1K-50K requests/día
Equipo:       2-5 developers
Presupuesto:  $50-500/mes
Objetivo:     Escalar lo que ya funciona
Duración:     3-12 meses

En Growth, tu prioridad es estabilidad + escalabilidad controlada. El producto funciona, tienes usuarios reales, y necesitas que no se caiga. Empiezas a pensar en monitoring, SLAs informales, y capacidad.

Scale (Escala)

Usuarios:     10,000+
Tráfico:      50K+ requests/día
Equipo:       5+ developers + ops
Presupuesto:  $500+/mes
Objetivo:     Operar de forma confiable a volumen
Duración:     12+ meses

En Scale, tu prioridad es confiabilidad + eficiencia operativa. Tienes equipo dedicado, SLAs formales, y el coste de downtime es alto. Inviertes en infraestructura porque el ROI lo justifica.

Estrategia de Deployment por Stage

MVP: Velocidad sobre todo

Estrategia recomendada: MANAGED (Railway, Render)

Por qué:
├── Deploy en minutos (git push → online)
├── Free tier cubre el volumen
├── Zero ops (no pierdes tiempo en infra)
├── Si el producto falla, no invertiste en infra
└── Fácil de migrar después (Docker es portable)

Alternativa: LOCAL (Docker Compose en laptop)
├── Para demo y desarrollo
├── Antes de tener dominio público
└── Si los datos no pueden salir de tu máquina

# MVP deployment: lo más simple posible
# main.py — Todo en un archivo
from fastapi import FastAPI
from openai import OpenAI
import os

app = FastAPI()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

@app.get("/health")
def health():
    return {"status": "ok"}

@app.post("/ask")
def ask(prompt: str):
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=500
    )
    return {"answer": r.choices[0].message.content}

# Deploy en Railway: 3 comandos
railway login
railway init
railway up
# URL pública en 2 minutos

Lo que NO haces en MVP:

• ❌ Kubernetes
• ❌ Multi-region
• ❌ Auto-scaling complejo
• ❌ Infrastructure as Code (Terraform)
• ❌ SageMaker
• ❌ Microservicios

Growth: Estabilidad + Escalabilidad controlada

Estrategia recomendada: MANAGED (pro) o LOCAL (VPS con Docker)

Por qué:
├── Tráfico predecible, necesitas uptime
├── Health checks y monitoring son necesarios
├── Docker Compose te da control sin complejidad
├── VPS con coste fijo es predecible
└── Puedes agregar Redis, workers, bases de datos

Alternativa: SERVERLESS (Lambda)
├── Si tráfico es muy variable (picos)
├── Para componentes asíncronos (procesamiento batch)
└── Si quieres zero ops en componentes específicos

# Growth: Docker Compose multi-service
# docker-compose.yml
services:
  api:
    build: ./api
    ports:
      - "8000:8000"
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - REDIS_URL=redis://cache:6379
    depends_on:
      cache:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  cache:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s

  worker:
    build: ./worker
    environment:
      - REDIS_URL=redis://cache:6379
    depends_on:
      - cache

Lo que agregas en Growth:

• ✅ Health checks
• ✅ Caching (Redis)
• ✅ Environment config (dev/staging/prod)
• ✅ Basic monitoring (UptimeRobot, logs)
• ✅ Automated deploys (GitHub Actions)
• ✅ Error tracking (Sentry)

Scale: Confiabilidad + Eficiencia

Estrategia recomendada: SELF-HOSTED (AWS) o SERVERLESS (Lambda) o HYBRID

Por qué:
├── Tráfico justifica inversión en infra
├── Equipo de ops puede mantener la complejidad
├── SLAs formales requieren redundancia
├── Cost optimization tiene ROI significativo
└── Multi-region si tienes usuarios globales

El equipo de ops absorbe la complejidad que en MVP/Growth era inaceptable.

Lo que agregas en Scale:

• ✅ Auto-scaling (horizontal)
• ✅ Load balancing
• ✅ Multi-region (si es necesario)
• ✅ Observability completa (métricas, traces, logs)
• ✅ Disaster recovery y backups automáticos
• ✅ Infrastructure as Code (Terraform/Pulumi)
• ✅ Runbooks operativos detallados

Cuándo Migrar de Stage

Señales de que necesitas migrar

MVP → Growth (migrar cuando):
├── Tienes usuarios reales que dependen del servicio
├── Downtime causa impacto (no solo inconveniencia)
├── Free tier se queda corto (RAM, CPU, requests)
├── Necesitas features que la plataforma no tiene
└── El producto está validado y vas a seguir invirtiéndole

Growth → Scale (migrar cuando):
├── Tráfico supera la capacidad de un solo servidor
├── Necesitas SLAs formales (99.9% uptime)
├── Tienes equipo de ops (o budget para contratar)
├── Cost optimization de >$500/mes justifica la migración
└── Compliance o regulación requiere control total

Señales de que NO debes migrar (migración prematura)

NO migres si:
├── "AWS es lo que usan las empresas serias" → Eso no es un requirement
├── "Necesitamos Kubernetes" con 50 usuarios → Overkill extremo
├── "Deberíamos estar en multi-region" con tráfico local → Innecesario
├── "El free tier tiene limits" → ¿Los estás alcanzando?
└── "Quiero aprender AWS en producción" → Aprende en LocalStack, no con dinero real

La migración prematura es uno de los errores más costosos en startups: semanas de trabajo de ingeniería para migrar a una infra que no necesitas. Ese tiempo podría haberse invertido en mejorar el producto.

Patrones de Migración por Stage

Patrón 1: Railway → VPS con Docker

Cuándo: El tráfico supera el plan de Railway, o necesitas más control (custom networking, volúmenes persistentes, SSH access).

# Paso 1: Tu app ya tiene Dockerfile (Railway lo usa)
# No hay cambio de código — solo de hosting

# Paso 2: Provisionar VPS
# DigitalOcean, Linode, o Hetzner ($12-48/mes)

# Paso 3: Setup en VPS
ssh root@tu-vps
apt update && apt install docker.io docker-compose-plugin
git clone tu-repo
cp .env.production .env
docker compose up -d

# Paso 4: Dominio y SSL
# Caddy como reverse proxy (auto-SSL)

Effort: 2-4 horas. Riesgo: bajo (mismo Docker container).

Patrón 2: VPS → AWS (Lambda + S3)

Cuándo: Necesitas servicios AWS específicos (S3 para storage, Lambda para procesamiento event-driven, SageMaker para modelos).

# Tu código con abstraction layer (Módulo 6)
import os

ENVIRONMENT = os.environ.get("ENVIRONMENT", "local")

def get_storage_client():
    """Retorna client de storage según entorno."""
    import boto3
    
    if ENVIRONMENT == "local":
        return boto3.client("s3", endpoint_url="http://localhost:4566")
    else:
        return boto3.client("s3")  # AWS real

Effort: 1-2 semanas. Riesgo: medio (nuevos servicios, IAM, networking).

Patrón 3: Managed → Hybrid (Container + Lambda)

Cuándo: Tu API principal corre bien en managed, pero necesitas procesamiento batch asíncrono que no cabe en el request/response cycle.

Antes (todo en Railway):
  User → Railway (FastAPI) → procesa todo síncronamente

Después (hybrid):
  User → Railway (FastAPI) → respuesta inmediata
                            → SQS → Lambda → procesamiento batch
                            → S3 → resultado disponible

Effort: 1 semana. Riesgo: bajo-medio (agrega complejidad, pero Railway sigue corriendo).

La Regla del "No Migres Hasta que Duela"

El principio

Migra de estrategia de deployment cuando la actual te cause dolor real — no dolor anticipado.

Dolor real:
├── "El servicio se cae 2 veces/semana por límites de memoria"
├── "Los requests timeout porque el VPS no puede con el tráfico"
├── "La factura de Railway es $200/mes y un VPS haría lo mismo por $48"
└── "Compliance nos obliga a tener los datos en nuestro propio servidor"

Dolor anticipado (no migres por esto):
├── "Algún día tendremos millones de usuarios"
├── "Las empresas serias usan AWS"
├── "No quiero que nos pille el crecimiento"
└── "Mi amigo migró y le fue bien"

Premature optimization kills startups

El tiempo que gastas migrando a AWS es tiempo que no gastas mejorando tu producto. Si tu producto no tiene product-market fit, la infraestructura es irrelevante. Primero valida, después optimiza.

Tiempo perdido en migración prematura:
├── Aprender AWS/IAM/Lambda:           20-40 hrs
├── Migrar código y CI/CD:             10-20 hrs
├── Testing y debugging:               10-20 hrs
├── Documentación y runbooks:          5-10 hrs
├── Total:                             45-90 hrs

Cosas que podrías hacer en 45-90 hrs:
├── Entrevistar 30 usuarios
├── Implementar 5 features nuevas
├── Mejorar 100 prompts
├── Reducir latencia de inferencia 50%
└── Lanzar 3 experimentos de product

Decision Matrix por Stage

Template rápido

Troubleshooting

Problema 1: "Mi manager quiere AWS desde el día 1"

Solución: Presenta números. "Railway cuesta $0/mes en MVP y nos pone online en 2 horas. AWS cuesta $200+/mes (incluyendo mi tiempo de setup) y tarda 2 semanas. Propongo Railway para MVP, con migration path documentado a AWS si validamos el producto."

Problema 2: "Migré prematuramente y ahora todo es más complejo"

Solución: Evalúa si puedes simplificar. Si migraste a AWS pero solo usas EC2 (sin Lambda, S3, SageMaker), un VPS con Docker Compose hace lo mismo con menos complejidad. La migración inversa (simplificar) también es una opción válida.

Problema 3: "No sé si estoy en MVP o Growth"

Solución: Pregúntate: "¿Alguien se queja si mi servicio se cae por 1 hora?" Si la respuesta es nadie (o solo tú), estás en MVP. Si usuarios reales se quejan, estás en Growth.

Ejercicios Prácticos

Ejercicio 1: Identifica tu stage

Clasifica tu proyecto actual (o uno que conozcas) en MVP, Growth o Scale. Justifica con métricas reales.

Proyecto: App de Q&A sobre documentación interna
Stage: MVP → Growth (transición)

Evidencia:
- Usuarios: 45 activos (pasamos de 10 hace 2 meses)
- Tráfico: ~800 req/día (creciendo 20%/mes)
- Equipo: 1 developer
- Downtime impacto: Medio (equipos de soporte la usan diario)
- Presupuesto: $0 actual (Railway free tier)

Diagnóstico: Estamos en la transición MVP → Growth
- Ya tenemos usuarios que dependen del servicio
- El free tier todavía alcanza pero estamos al 70% del límite
- Necesitamos health checks y basic monitoring

Plan: Migrar a Railway Pro ($5/mes) y agregar UptimeRobot.
No migrar a AWS — no hay justificación todavía.

Ejercicio 2: Plan de migración a 12 meses

Crea un timeline de 12 meses para tu proyecto, indicando en qué mes harías cada migración (si aplica) y por qué.

Timeline: App RAG documentación

Mes 1-3 (MVP):
  Deployment: Railway free tier
  Trigger para migrar: Free tier limits

Mes 4-6 (Growth early):
  Deployment: Railway Pro ($5/mes)
  Agregar: Redis cache, health checks
  Trigger para migrar: >200 usuarios o >5K req/día

Mes 7-9 (Growth):
  Deployment: VPS Docker Compose ($24/mes)
  Agregar: Monitoring (UptimeRobot + Sentry), CI/CD
  Trigger para migrar: >500 concurrent users o need para servicios AWS

Mes 10-12 (Growth → Scale):
  Evaluación: ¿Necesitamos AWS?
  Si sí: Migración con LocalStack (Módulos 4-6 de esta guía)
  Si no: Seguir en VPS, optimizar
  Agregar: Load balancing si hay picos

Ejercicio 3: Cálculo de "premature optimization"

Tu equipo quiere migrar a AWS ahora (en stage MVP). Calcula: (a) horas de trabajo para migrar, (b) valor de esas horas en mejoras de producto, (c) cuándo la migración tendría ROI positivo.

(a) Horas de migración a AWS:
  - Aprender Lambda + API Gateway + IAM:     15 hrs
  - Configurar CI/CD para AWS:               8 hrs
  - Migrar código y testing:                 12 hrs
  - Documentar:                              5 hrs
  Total:                                     40 hrs

(b) Valor alternativo (40 hrs de mejoras):
  - 15 entrevistas de usuario
  - 3 features nuevas
  - Reducir latencia 30% con prompt optimization
  - Implementar caching (ahorro 30% en API costs)

(c) ROI de migración:
  Railway Pro: $20/mes
  AWS Lambda: $5/mes (a nuestro volumen)
  Ahorro: $15/mes
  Horas invertidas: 40 hrs × $50/hr = $2,000
  
  Break-even: $2,000 / $15 = 133 meses = 11 AÑOS
  
  Conclusión: La migración a AWS NO tiene ROI en MVP.
  Migrar solo cuando Railway cause dolor real.

Ejercicio 4: Checklist de "dolor real"

Crea un checklist de 5 señales de dolor real que justificarían migrar de tu estrategia actual. Sé específico con métricas.

## Checklist de migración: Railway → VPS/AWS

Migrar cuando AL MENOS 2 de estos se cumplan:

- [ ] Límite de memoria alcanzado (>90% de los 512MB del plan)
- [ ] Requests timeout >5% del total (cold starts o CPU limit)
- [ ] Factura de Railway > $50/mes (un VPS haría lo mismo por $24)
- [ ] Feature bloqueado por la plataforma (ej: WebSockets, volumes)
- [ ] Compliance require control de datos (SOC2, HIPAA)

NO migrar si:
- Solo una señal se cumple (optimiza primero)
- La señal es anticipada, no actual
- No tienes tiempo para hacer la migración bien (>20 hrs)

Resumen

• Los 3 stages (MVP, Growth, Scale) tienen prioridades de deployment fundamentalmente diferentes.
• MVP: Velocidad sobre todo. Managed platforms (Railway/Render). Zero ops.
• Growth: Estabilidad + escalabilidad controlada. Docker Compose en VPS o managed pro.
• Scale: Confiabilidad + eficiencia. AWS, hybrid, o self-hosted con equipo de ops.
• No migres prematuramente. La migración prematura es uno de los errores más costosos en startups.
• Migra cuando haya dolor real (métricas, no sentimientos): downtime, limits alcanzados, costes excesivos.
• Documenta triggers de migración con métricas específicas en tu decision matrix.
• El ROI de migrar casi nunca es positivo en MVP. El tiempo se invierte mejor en producto.

Recursos Adicionales

1. The Twelve-Factor App — Principios para apps cloud-native que facilitan migración entre stages
2. Startup CTO's Handbook — Guía para CTOs sobre decisiones de infraestructura
3. Choose Boring Technology — Ensayo clásico sobre por qué elegir tech aburrida
4. The Pragmatic Engineer — Blog sobre ingeniería y decisiones de infraestructura
5. Running in Production Podcast — Casos reales de deployment en producción
6. Railway Blog — Scaling Stories — Historias de escalamiento en Railway