DevOps Mínimo Viable: lo que toda startup necesita antes de salir a producción

No necesitas Kubernetes. Probablemente no necesitas microservicios. Y desde luego no necesitas un equipo de SRE dedicado en esta fase. Pero sí necesitas una base de DevOps. Sin ella, cada despliegue es una ruleta rusa y cada incidencia en producción se convierte en un incendio que apagar a las 3 de la mañana.

He visto startups con producto sólido y tracción real perder semanas por no tener un pipeline de CI/CD decente. Y he visto otras gastar meses montando infraestructura de nivel enterprise cuando tenían 3 ingenieros y 0 clientes de pago. Ambos extremos son errores. Lo que necesitas es el DevOps Mínimo Viable.

El checklist del DevOps Mínimo Viable

Estos son los 8 elementos que toda startup necesita antes de poner un producto en manos de usuarios reales. No es negociable. Si te falta alguno, estás acumulando deuda operativa que te explotará en la cara en el peor momento posible.

1. Control de versiones con estrategia de ramas

Parece obvio, pero la cantidad de startups que trabajan directamente sobre main sin ninguna estrategia de ramas es asombrosa.

Tienes dos opciones razonables:

• Trunk-based development. Ramas de vida corta (horas, no días), merges frecuentes a main, feature flags para el código sin terminar. Ideal para equipos pequeños que despliegan varias veces al día.
• Git Flow simplificado. Ramas de feature, una rama develop, releases desde main. Más estructura, útil cuando necesitas entornos de staging bien definidos.

Para la mayoría de startups en fase temprana, trunk-based con feature flags es la opción correcta. Menos overhead, menos conflictos de merge, ciclos más rápidos.

2. Pipeline de CI: lint, test y build en cada PR

Cada pull request debería pasar por un pipeline automatizado antes de llegar a revisión. Como mínimo:

• Linting. ESLint, Pylint, lo que corresponda a tu stack. No es una cuestión de estética: es prevención de bugs.
• Tests automatizados. Tests unitarios como mínimo. De integración si los tienes. El pipeline falla si falla cualquier test. Sin excepciones.
• Build. Si tu aplicación compila, compílala en CI. Un PR que rompe el build no se mergea. Punto.

Esto te da una red de seguridad básica. No es perfecta, pero es infinitamente mejor que el "en mi máquina funciona".

3. Pipeline de CD: despliegue automatizado a staging y producción

Si haces despliegues a mano — SSH al servidor, git pull, npm run build, rezar — vives peligrosamente. Un pipeline de CD básico hace esto:

• Merge a develop = despliegue automático a staging.
• Merge a main (o tag de release) = despliegue automático a producción.
• Rollback accesible. Un botón o un comando para volver a la versión anterior en menos de 5 minutos.

Desplegar debería ser un evento aburrido. Si cada vez que sales a producción todo el equipo contiene la respiración, tienes un problema de proceso, no de producto.

4. Monitorización básica: uptime, errores, tiempos de respuesta

No necesitas dashboards con 47 métricas. Necesitas saber tres cosas en todo momento:

• ¿Está tu aplicación online? Monitorización de uptime. Si se cae, te enteras en minutos, no cuando un usuario te lo cuenta por Twitter.
• ¿Hay errores? Tasa de errores 5xx, excepciones sin capturar. Herramientas como Sentry son perfectas para esto.
• ¿Es rápida? Tiempos de respuesta de tus endpoints críticos. Si tu API pasa de 200ms a 2 segundos, quieres saberlo antes que tus usuarios.

Las opciones: Datadog si tienes presupuesto, New Relic con su tier gratuito, o incluso CloudWatch si estás en AWS. La herramienta da igual — lo importante es que la monitorización exista y que las alertas le lleguen a alguien que las vaya a ver.

5. Logging centralizado y buscable

console.log en producción no es logging. Los logs dispersos en 3 servidores distintos no sirven de nada cuando tienes una incidencia a las 11 de la noche.

Necesitas logs centralizados en un sitio donde puedas buscarlos. Las opciones:

• ELK Stack (Elasticsearch, Logstash, Kibana). Potente, pero requiere mantenimiento si lo alojas tú mismo.
• CloudWatch Logs si estás en AWS. Fácil de configurar, buscable, integrado.
• Papertrail o Logtail. Simples, baratos, suficientes para una startup en fase temprana.

La regla de oro: si un usuario te reporta un bug, deberías poder encontrar el log correspondiente en menos de 5 minutos.

6. Backups y recuperación: copias de la base de datos con restauración probada

Tener backups no cuenta si nunca has probado a restaurarlos. Esto es lo mínimo:

• Backups automáticos diarios de tu base de datos. Si usas RDS o Cloud SQL, esto viene de serie.
• Retención mínima de 7 días. Idealmente 30.
• Restauración probada. Al menos una vez al trimestre, restaura un backup en un entorno de prueba y verifica que los datos están ahí. Si nunca has probado tu restauración, no tienes backups — tienes una ilusión de seguridad.

7. Paridad de entornos: staging refleja producción

Tu entorno de staging debe parecerse a producción todo lo posible. Misma versión de base de datos, misma configuración de servidor, mismas variables de entorno (con valores distintos, obviamente).

Si algo funciona en staging pero falla en producción, tu staging no sirve. Los problemas más comunes:

• Versiones de dependencias distintas. Staging con Node 18, producción con Node 16. Usa Docker o, como mínimo, .nvmrc para fijar versiones.
• Base de datos distinta. Staging con SQLite, producción con PostgreSQL. No. Usa la misma base de datos en ambos entornos.
• Datos de prueba irreales. Tu staging tiene 10 registros. Tu producción, 100.000. Los problemas de rendimiento no aparecen con 10 registros.

8. Gestión de secretos: cero credenciales hardcodeadas

Si hay una API key, una contraseña de base de datos o un token de acceso en tu código fuente, tienes un problema de seguridad que explotará; solo es cuestión de tiempo.

Lo mínimo:

• Variables de entorno para todos los secretos. Nunca en el código, nunca en el repositorio.
• .env en .gitignore. Siempre. Sin excepciones.
• Rotación de secretos. Si un secreto se filtra, deberías poder rotarlo en minutos, no en horas.

Herramientas como AWS Secrets Manager, HashiCorp Vault o incluso el gestor de secretos integrado en GitHub Actions son suficientes para empezar.

Lo que NO necesitas (todavía)

Tan importante como lo que necesitas es lo que no. Estas son las trampas de sobreingeniería más comunes:

• Kubernetes. A menos que tengas un equipo de más de 10 ingenieros y necesidades reales de orquestación de contenedores, Kubernetes es complejidad que no aporta valor. Un montaje simple con ECS, Railway o Fly.io es más que suficiente.
• Service mesh. Istio, Linkerd... soluciones a problemas que no tienes con 3 microservicios (que, de todos modos, probablemente deberían ser un monolito).
• Dashboards de métricas a medida. Grafana con 15 paneles no te hace más rápido. Las alertas básicas sí.
• Failover multirregión. Si tu startup tiene 500 usuarios, no necesitas redundancia geográfica. Necesitas un uptime sólido en una región.

La regla: si no puedes explicar en una frase por qué necesitas una herramienta o una práctica, probablemente no la necesitas.

Cuándo subir de nivel

El DevOps Mínimo Viable no es el destino — es el punto de partida. Deberías empezar a invertir en infraestructura más robusta cuando:

• Tienes clientes de pago. Ahora hay SLAs implícitos. El downtime cuesta dinero real.
• Tu equipo supera los 5 ingenieros. Más gente = más necesidad de automatización, mejores entornos de desarrollo, pipelines más sofisticados.
• Tienes requisitos regulatorios. Si manejas datos sanitarios, financieros o personales con obligaciones de cumplimiento, tu infraestructura tiene que reflejarlo.

Herramientas según presupuesto

Presupuesto cero (free tier): GitHub Actions para CI/CD, Vercel o Railway para hosting, Sentry gratuito para errores, UptimeRobot para monitorización de uptime. Esto te cubre sorprendentemente bien hasta los primeros miles de usuarios.

Presupuesto medio (200-500 €/mes): AWS con Terraform para infraestructura como código, GitHub Actions o CircleCI para CI/CD, Datadog o New Relic para monitorización, ELK gestionado o CloudWatch para logs.

Presupuesto enterprise (1.000+ €/mes): Servicios gestionados de AWS o GCP, ECS o EKS para contenedores, la suite completa de Datadog, PagerDuty para gestión de incidencias, Terraform Cloud para gestión de estado.

El perfil que necesitas

Montar todo esto no requiere un equipo de DevOps. Requiere un ingeniero senior que ya lo haya hecho antes. Alguien que distinga lo necesario de lo aspiracional, que pueda configurar un pipeline de CI/CD en un día — no en un sprint — y que entienda que la infraestructura está al servicio del producto, no al revés.

En Conectia tenemos ingenieros senior de DevOps e infraestructura que han construido exactamente esta base para startups — sin sobreingeniería, sin soluciones enterprise para problemas de startup. Todos han pasado nuestro vetting técnico liderado por CTOs, donde evaluamos experiencia real en producción, no certificaciones. Y respondemos en menos de 72 horas.

El DevOps Mínimo Viable no es glamuroso. No vas a escribir un post en LinkedIn presumiendo de tu pipeline de CI. Pero es la diferencia entre una startup que puede iterar con confianza y una a la que le da miedo desplegar en viernes.

---

¿Necesitas un ingeniero DevOps senior que siente las bases sin sobreingeniería? Habla con un CTO — la infraestructura adecuada para tu fase, lista en días.