Experimentar antes de escalar

El riesgo que importa

No todos los riesgos merecen un spike. El que importa es el que, si falla, tira abajo el resto del plan: un proveedor que no entrega la API que prometió, un volumen que el modelo actual no aguanta, una regla de negocio que nadie puede escribir sin discutirla. El resto es implementación. Se resuelve después.

Cómo se ve un experimento de verdad

Cabe en una o dos semanas. Tiene una pregunta que se responde con sí, no, o “no de esta forma”. Entrega algo que se puede romper: un flujo extremo a extremo, una integración real, un recorte de datos de producción — no un deck ni un prototipo que solo se ve bien en una demo.

Si al final no se puede matar la idea, no era un experimento. Era el proyecto disfrazado de spike.

Qué se mata y qué se escala

Se mata lo que no sobrevive al contacto con el dato real. Se escala lo que ya movió una operación, aunque sea chica: un tramo automatizado, un módulo que el equipo interno usó una semana sin que lo empujáramos. Recién ahí vale la pena hablar de fases, de CI/CD, de lo que viene después.

Construir la catedral primero es tentador. También es la forma más rápida de pagar mantenimiento por un sistema que nadie usa.

Qué pedimos al cliente

Acceso al proceso real, no a la versión pulida. Una persona que pueda decir “así se hace hoy” sin pasar por tres aprobaciones. Y permiso para volver con un “esto no se sostiene” si el experimento lo demuestra. Si eso no está sobre la mesa, todavía no hay proyecto — hay una conversación pendiente.