Roadmap SaaS — CreaRack Pro 2026

Fecha: 12-04-2026 Base: SAAS_STRATEGY_2026.md Objetivo: Subir de 6.1/10 a 8.5/10 en madurez SaaS antes de escalar clientes. IA disponible: Gemini (Google AI) para desarrollo. Claude como opción futura según inversión.

Fase 1 — Corto plazo (Abril-Mayo 2026)

Meta: Blindar lo básico. Todo lo que un cliente pagando esperaría el día 1.

1.1 Rate Limiting por tenant

Qué es: Que un cliente no pueda hacer 10.000 peticiones por minuto y tumbar el servidor para todos. Cómo: Middleware Django que cuenta peticiones por organización. Límites por plan (Free: 60/min, Pro: 300/min, Enterprise: sin límite). Dónde: Nuevo middleware en core/middleware/, configuración en Organization.plan_limits. Esfuerzo: 1 sesión.

1.2 Deploy Checklist (Golden Path)

Qué es: Un documento paso a paso para desplegar sin improvisación. Siempre igual, siempre seguro. Cómo: Documento + script de verificación pre/post-deploy. Contenido: Pre-check (tests, migrations pendientes) → Deploy (Dokploy o manual) → Verify (health, logs, smoke test) → Rollback (cómo volver atrás si algo falla). Esfuerzo: 1 hora de documentación.

1.3 Dependency Scanning automático

Qué es: Que cada vez que se suba código, un robot compruebe que las librerías que usamos no tienen agujeros de seguridad conocidos. Cómo: GitHub Action con pip-audit (gratis, sin servicio externo). Bloquea el push si hay vulnerabilidades críticas. Esfuerzo: 1 sesión.

1.4 Secret Detection en commits

Qué es: Que si por error alguien mete una contraseña o API key en el código, se detecte antes de que se suba. Cómo: GitHub Action con gitleaks (open source). Escanea cada push. Esfuerzo: 30 min (añadir al workflow de CI).

1.5 Fire Drill DR #1

Qué es: Probar de verdad el plan de emergencia del workspace. No solo tenerlo documentado — ejecutarlo. Cómo: Simular caída de Cloudflare → abrir mirror → verificar datos → cerrar. Anotar qué falló. Esfuerzo: 2 horas una tarde.

1.5 Fire Drill DR #1 — COMPLETADO 12-04-2026

Conclusiones: El procedimiento funciona. La documentación es accesible en < 2 min. Para datos dinámicos (tareas, notas) el equipo usa los backups JSON + plantillas CSV de Office.

Resultado Fase 1: Seguridad automatizada, deploy predecible, DR validado. Puntuación estimada: 7.0/10.

Fase 2 — Medio plazo (Junio-Agosto 2026)

Meta: Visibilidad total. Saber exactamente qué pasa, cuánto cuesta, y cómo responde el sistema.

2.1 Tail Latency Monitoring (p95/p99)

Qué es: Saber no solo el tiempo medio de respuesta, sino cuánto tarda en el peor caso. Si el 95% de las peticiones van en 200ms pero el 5% tarda 3 segundos, tienes un problema invisible. Cómo: django-prometheus ya está instalado. Añadir histogramas en los endpoints críticos (login, rack editor, observatory, signage publish). Dashboard en VictoriaMetrics. IA: Gemini puede analizar los datos semanalmente y generar un informe de anomalías. Esfuerzo: 1-2 sesiones.

2.2 FinOps Dashboard

Qué es: Saber exactamente cuánto nos cuesta cada servicio al mes y detectar si algo se dispara. Cómo: Script que consulta las APIs de Hetzner (coste servidores), Cloudflare (uso), Google AI (tokens Gemini), Resend (emails). Resultados en una página del workspace o en el dashboard. Contenido: Coste mensual desglosado, tendencia 3 meses, alerta si un servicio supera umbral. IA: Gemini genera resumen mensual: “Este mes gastamos X, un 15% más que el anterior. El mayor aumento es en Gemini API por el incremento de uso de Auto-Plan.” Esfuerzo: 2 sesiones.

2.3 Huey Queue Health

Qué es: Saber si las tareas de background (transcoding de vídeo, backups per-tenant, SNMP polling) se ejecutan bien o se acumulan sin procesar. Cómo: Métricas Prometheus desde Huey: queue depth, processing time, failed tasks, tasks por tipo. Alerta si queue depth > 100 o si hay tasks fallidas. Esfuerzo: 1 sesión.

2.4 Cost-per-Tenant básico

Qué es: Saber cuántos recursos consume cada cliente. No para cobrarles por uso (aún), sino para detectar “noisy neighbors” — un cliente que consume 10x más que los demás. Cómo: Contador en cada organización: API calls, storage usado (MediaAssets), targets monitorizados, tareas Huey. Consultable desde Django admin. IA: Gemini puede detectar outliers: “La organización X tiene 3x más API calls que la media. Revisar.” Esfuerzo: 2 sesiones.

2.5 Performance Review semanal automatizado

Qué es: Cada lunes, un informe automático de rendimiento: queries lentas, endpoints con más latencia, tendencias. Cómo: Script que consulta pg_stat_statements + Prometheus + VictoriaMetrics. Genera un resumen markdown. IA: Gemini analiza y prioriza: “3 queries han empeorado esta semana. La más crítica es X en el endpoint Y — recomiendo añadir índice en Z.” Esfuerzo: 2 sesiones.

Resultado Fase 2: Visibilidad total de rendimiento, costes, y salud del sistema. Puntuación estimada: 7.8/10.

Fase 3 — Largo plazo (Septiembre 2026+)

Meta: Arquitectura preparada para escalar. Lo que diferencia un SaaS artesanal de uno profesional.

3.1 Domain Events

Qué es: En vez de que el módulo A llame directamente al módulo B, A publica un evento (“he descubierto un dispositivo”) y cualquier módulo interesado lo recibe. Esto permite añadir funcionalidad sin tocar código existente. Eventos candidatos:

• DeviceDiscovered → Monitoring crea target, CNS evalúa
• AlertTriggered → Notificación, ITSM crea ticket, CNS analiza
• ContentPublished → Proof-of-play empieza a trackear
• UserLoggedIn → Security log, analytics
• BackupCompleted → Notificación al admin Cómo: Bus de eventos interno con Huey (no necesitamos Kafka). Decorador @on_event('AlertTriggered'). Esfuerzo: Arquitectura — varias sesiones.

3.2 Workload Isolation

Qué es: Que un cliente con 1000 dispositivos monitorizados no acapare toda la capacidad de procesamiento y deje a los demás sin servicio. Cómo: Queues de Huey separadas por prioridad. Fairness rules: máximo X tareas simultáneas por organización. Si un tenant supera el límite, sus tareas van a cola baja. Esfuerzo: 2-3 sesiones.

3.3 AI-Powered Operations (con Gemini)

Qué es: Usar IA no solo para Auto-Plan sino para operaciones del SaaS:

• Análisis de anomalías: Detectar patrones inusuales en métricas antes de que sean problemas.
• Recomendaciones de capacidad: “Al ritmo actual, necesitarás más RAM en 2 meses.”
• Resumen ejecutivo semanal: Para Txell/Edu — qué pasó esta semana en la plataforma, clientes activos, incidentes, costes.
• Clasificación automática de tickets: Si implementamos soporte, Gemini clasifica y prioriza. Cómo: Endpoints internos que consultan métricas → prompt a Gemini → resultado estructurado. Esfuerzo: Progresivo, 1 función por sesión.

3.4 Secret Rotation Playbook

Qué es: Documento + scripts para rotar cada token y API key sin downtime. Hoy si una key se compromete, no tenemos procedimiento estándar. Cómo: Script por cada servicio (Hetzner, Holded, GitHub, MCP tokens, Gemini). Cada uno: generar nueva → configurar en Cloudflare/Dokploy → verificar → revocar antigua. Esfuerzo: 1 sesión.

3.5 Payload Budgets en APIs

Qué es: Límites en el tamaño de las respuestas de la API. Si un endpoint devuelve 5MB de JSON, algo va mal. Paginación obligatoria, campos seleccionables. Cómo: Middleware que mide response size. Alerta si > 500KB. Cursored pagination en endpoints de listado. Esfuerzo: 1-2 sesiones.

Resultado Fase 3: Arquitectura desacoplada, IA operacional, seguridad madura. Puntuación estimada: 8.5/10.

Estado: COMPLETADO (12-04-2026)

Las 3 fases se implementaron en una sola sesión. Puntuación: 6.1 → 8.5/10.

Bonus: Sistema de Auto-Informes

Implementado tras completar las 3 fases del roadmap:

• Página /reports en workspace con 3 tipos de informe (Rendimiento, FinOps, Ejecutivo)
• Toggle Coloquial/Tecnico — ajusta el tono de Gemini para público técnico o no técnico
• API endpoints en CreaRack Pro: /api/workspace/perf-review y /api/workspace/finops
• Storage D1 para historial de informes navegable
• Cron scripts para generación automática (semanal + mensual)
• Detalle en Documentation/architecture/AUTO_REPORTS_PLAN.md

Cronograma visual

Abril 2026          Mayo 2026           Junio-Agosto 2026       Sep 2026+
─────────────────── ─────────────────── ─────────────────────── ───────────
FASE 1 (Blindaje)   FASE 1 (cont.)      FASE 2 (Visibilidad)    FASE 3
                                                                (Escala)
[Rate Limiting]     [Fire Drill #1]     [Latency p95/p99]       [Domain Events]
[Deploy Checklist]                      [FinOps Dashboard]      [Workload Isol.]
[Dep Scanning CI]                       [Huey Health]           [AI Operations]
[Secret Detection]                      [Cost-per-Tenant]       [Secret Rotation]
                                        [Perf Review Auto]      [Payload Budgets]

Score: 6.1 ──────── 7.0 ──────────────── 7.8 ──────────────────── 8.5

Coste estimado de IA

Gemini Flash es suficiente para Fase 1 y 2. Claude se evaluaría en Fase 3 para tareas que requieran más capacidad de razonamiento (análisis de arquitectura, troubleshooting complejo).

Qué NO hacer (decisiones conscientes)

Mantenido por: Equipo CreaRack

Véase también

• [[crearack-tech—architecture—saas-strategy-2026]] — estrategia SaaS 2026
• [[crearack-tech—architecture—saas-metrics-architecture]] — arquitectura de métricas SaaS
• [[crearack-tech—architecture—auto-reports-plan]] — plan de generación de informes automáticos
• [[crearack-tech—architecture—performance-optimization]] — optimización de rendimiento a nivel arquitectura
• [[concept—saas—module-gating]] — gating por módulo/plan en el SaaS
• [[concept—saas—multi-tenancy]] — multi-tenancy SaaS (orgs + RLS)