Platform Engineering

El dolor

Llegas a esta página probablemente porque alguno de estos te suena:

• El platform team interno tiene 4 personas y atiende a 60 ingenieros de producto. La cola de tickets crece más rápido que la capacidad de resolverlos.
• El deploy a producción toma 6 semanas y cada release necesita 3 reuniones de coordinación. Los managers ya no preguntan “cuándo sale” porque la respuesta daña la moral.
• Hay observabilidad pero nadie correlaciona costos con uso real ni con contratos. El CFO pide “explíquenme por qué la factura de Datadog subió 40%” y la respuesta honesta es “no sabemos”.
• Compliance pide trazabilidad de quién deployó qué y cuándo. El equipo tiene los logs pero no los correlaciona con tickets ni con changes. Cada auditoría consume 2 semanas de un staff engineer.
• Hay un IDP comprado o un platform-as-product proyecto interno que lleva 18 meses y todavía no está en producción.

Ninguno de estos es un problema de herramientas. Es un problema de plataforma sin opinionatedness — no hay decisión clara sobre qué se ofrece, qué se prohíbe, y quién es responsable de cada capa.

Lo que CultureTech prepara

Un Staff Engineer embebido en el equipo del cliente durante 3-6 meses, con foco en uno de estos dominios (no los cinco al mismo tiempo):

• Internal Developer Platform opinionada — Backstage o equivalente custom, con catálogo de servicios real, scoring de madurez, y golden paths para los 3-5 tipos de servicio que la organización efectivamente construye. No “platform that does everything” — platform que cubre el 80% de los casos rápidamente.
• FinOps con causa-efecto — cruzar la observabilidad técnica con attribution de costos. El output es: cuánto cuesta servir cada feature, cada cliente, cada query. Con eso, decisiones de retiro o rediseño dejan de ser políticas.
• SRE con SLOs auditables — burn rate alerting, error budgets que se respetan, postmortems con timeline reconstruido. En banca regulada esto se traduce a evidencia para CMF y reguladores equivalentes.
• Observabilidad semántica — vía Aether Telemetry (producto del laboratorio). El cambio versus OTel tradicional: cada trace, métrica o log lleva contexto contractual (qué SLA, qué cliente, qué tier). Permite detectar drift entre lo que el contrato dice y lo que el servicio entrega, no solo el latency p99.
• GitOps + IaC con cadena de custodia — todo cambio a infra pasa por git, todo merge va con signature criptográfica, todo deploy va con un attestation SLSA L3 o L4. Aplica especialmente a Kubernetes y workloads sensibles.

El engagement no entrega slideware ni “estrategia”. Entrega código en tu repo, dashboards en tu Grafana, runbooks en tu wiki, y tu equipo operándolo.

Para quién es

• Organizaciones con más de 50 ingenieros y un platform team interno existente (de 3 a 10 personas) que necesita capacidad senior para desbloquear o redirigir.
• Sectores donde regulación cruza con velocidad — banca, salud, telco, GovTech. El servicio asume compliance como restricción dura, no como capa decorativa.
• CTOs/VPEs que reconocen que el problema no se resuelve contratando 3 mid-level más, sino con una intervención senior corta y enfocada.

No es

• Body shop con junior pricing-by-the-hour. El engagement es capacidad senior con foco en outcome, no horas vendidas.
• Consultoría con entregable Word. Si lo que entregamos no compila, no entregamos.
• “Estrategia digital.” Eso lo hacen otros, mejor.
• Sustituto del platform team interno. Es un acelerador. El equipo cliente opera lo construido al cerrar el engagement — sin lock-in, sin retainer obligatorio.

Cómo se cruza con el portafolio

• Aether Telemetry — la capa de observabilidad semántica que instrumenta el platform engineering cuando el cliente acepta el producto del laboratorio. Es la pieza que diferencia el resultado vs un platform team que solo opera OTel.
• Themis — agentes AIOps SRE que consumen las señales de Aether para automatizar runbooks. Aplica en fases avanzadas del engagement, cuando los SLOs ya están establecidos.
• OTel Strangler Fig — el playbook de migración OpenTelemetry sin big-bang que usamos como approach base cuando la organización tiene observabilidad legacy fragmentada.
• Agentic SRE — patrón de introducción de agentes IA en el ciclo SRE sin perder rigor operacional.

Cuándo activa

Q3 2026. Antes de eso, el engagement está bloqueado por la certificación SII de Thoth y la dedicación operacional necesaria para operar el primer cliente real. La conversación previa está abierta — agendar discovery no compromete inicio de trabajo, pero sí permite alinear scope y expectativas con anticipación.

El proceso es: discovery semana (sin costo) → propuesta con scope acotado a un dominio → engagement de 3-6 meses → handoff documentado. Sin retainer obligatorio post-engagement.