DevOps Mínimo Viable: Lo que Toda Startup Necesita Antes de Ir a Producción
No necesitas Kubernetes. Probablemente no necesitas microservicios. Definitivamente no necesitas un equipo de SRE dedicado a esta altura. 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 que perdieron semanas por no tener un pipeline de CI/CD decente. Y he visto otras que gastaron meses montando infraestructura de empresa grande 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 va a explotar en la cara en el peor momento posible.
1. Control de versiones con branching strategy
Esto parece obvio, pero la cantidad de startups que trabajan directamente sobre main sin estrategia de branching es sorprendente.
Tienes dos opciones razonables:
- Trunk-based development. Branches cortas (horas, no días), merge frecuente a main, feature flags para código no terminado. Ideal para equipos pequeños que despliegan varias veces al día.
- Git Flow simplificado. Branches de feature, una branch de develop, releases desde main. Más estructura, útil cuando necesitas staging environments claros.
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, build en cada PR
Cada pull request debe pasar por un pipeline automatizado antes de que nadie la revise. Mínimo:
- Linting. ESLint, Pylint, lo que corresponda a tu stack. Esto no es estética — es prevención de bugs.
- Tests automatizados. Unit tests como mínimo. Integration tests si los tienes. El pipeline falla si algún test falla. Sin excepciones.
- Build. Si tu aplicación compila, compila en CI. Un PR que rompe el build no se mergea. Punto.
Esto te da una red de seguridad básica. No perfecta, pero infinitamente mejor que "funciona en mi máquina."
3. Pipeline de CD: despliegue automatizado a staging y producción
Si estás haciendo despliegues manuales — SSH al servidor, git pull, npm run build, rezar — estás viviendo 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.
El despliegue debe ser un evento aburrido. Si cada vez que despliegas 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 tuitea.
- ¿Hay errores? Tasa de errores 5xx, excepciones no capturadas. 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 de que tus usuarios lo noten.
Las opciones: Datadog si tienes presupuesto, New Relic con su tier gratuito, o incluso CloudWatch si estás en AWS. Lo importante no es la herramienta — es que la monitorización exista y que las alertas lleguen a donde alguien las vea.
5. Logging centralizado y buscable
console.log en producción no es logging. Los logs dispersos en 3 servidores diferentes no son útiles cuando tienes una incidencia a las 11 de la noche.
Necesitas logs centralizados en un sitio donde puedas buscar. Las opciones:
- ELK Stack (Elasticsearch, Logstash, Kibana). Potente, pero requiere mantenimiento si lo hosteas tú.
- CloudWatch Logs si estás en AWS. Fácil de configurar, buscable, integrado.
- Papertrail o Logtail. Simples, baratos, suficientes para startups en fase temprana.
La regla de oro: si un usuario te reporta un error, deberías poder encontrar el log correspondiente en menos de 5 minutos.
6. Backup y recovery: backups de base de datos con restore probado
Tener backups no cuenta si nunca has probado 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.
- Restore probado. 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 restore, no tienes backups — tienes una ilusión de seguridad.
7. Paridad de entornos: staging espeja producción
Tu entorno de staging debe ser lo más parecido posible a producción. Misma versión de base de datos, misma configuración de servidor, mismas variables de entorno (con valores diferentes, obviamente).
Si algo funciona en staging pero falla en producción, tu staging no sirve. Los problemas más comunes:
- Versiones diferentes de dependencias. Staging con Node 18, producción con Node 16. Usa Docker o al menos
.nvmrcpara fijar versiones. - Base de datos diferente. 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 tiene 100.000. Los problemas de rendimiento no aparecen con 10 registros.
8. Gestión de secretos: cero credenciales hardcodeadas
Si hay una API key, contraseña de base de datos, o token de acceso en tu código fuente, tienes un problema de seguridad que es cuestión de tiempo que explote.
Lo mínimo:
- Variables de entorno para todos los secretos. Nunca en el código, nunca en el repositorio.
.enven.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 de GitHub Actions son suficientes para empezar.
Lo que NO necesitas (todavía)
Tan importante como lo que necesitas es lo que no necesitas. Estos son los over-engineering traps 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 te aporta valor. Un simple ECS, Railway, o Fly.io es más que suficiente.
- Service mesh. Istio, Linkerd... soluciones a problemas que no tienes con 3 microservicios (que probablemente deberían ser un monolito).
- Dashboards de métricas custom. Grafana con 15 paneles no te hace más rápido. Las alertas básicas sí.
- Multi-region failover. Si tu startup tiene 500 usuarios, no necesitas redundancia geográfica. Necesitas un buen uptime en una región.
La regla: si no puedes explicar en una frase por qué necesitas una herramienta o 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 de salud, financieros o personales con requerimientos de cumplimiento, tu infraestructura necesita reflejar eso.
Herramientas por presupuesto
Presupuesto cero (free tier): GitHub Actions para CI/CD, Vercel o Railway para hosting, Sentry free para errores, UptimeRobot para monitorización de uptime. Esto te cubre sorprendentemente bien hasta tus 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 managed o CloudWatch para logs.
Presupuesto enterprise (€1.000+/mes): Servicios managed de AWS o GCP, ECS o EKS para contenedores, Datadog full suite, 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 haya hecho esto antes. Alguien que sepa la diferencia entre lo necesario y lo aspiracional, que pueda configurar un pipeline de CI/CD en un día — no en un sprint — y que entienda que la infraestructura debe servir al producto, no al revés.
En Conectia, tenemos ingenieros senior de DevOps e infraestructura que han montado exactamente este tipo de fundación para startups. No over-engineering, no soluciones enterprise para problemas de startup. El stack correcto para tu fase actual, configurado para escalar cuando lo necesites.
Cada ingeniero pasa por nuestro proceso de vetting técnico liderado por CTOs. Evaluamos experiencia real en producción, no certificaciones. Y están disponibles en 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 que tiene miedo de hacer deploy un viernes.
¿Necesitas un ingeniero DevOps senior que monte las bases sin sobre-ingeniería? Habla con un CTO — infraestructura correcta para tu fase, lista en días.
