Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
Composable Readiness Check: ¿cuándo compensa realmente lo composable?
La conversación sobre composable commerce ha cambiado. Cualquiera que haya seguido el K5 2026 conoce el tono: menos entusiasmo, más realismo. Elogic, Branch8 y CX Today han descrito en los últimos meses lo que llevamos escuchando en conversaciones con clientes desde hace más tiempo. Lo composable no es una solución universal, y la reconstrucción full stack MACH supera el presupuesto y la capacidad de equipo de la mayoría de las empresas del mid market.
Eso no es un retroceso. Eso es madurez.
Nuestra opinión: la pregunta ya no es "¿composable sí o no?". Es "¿qué grado de composable encaja con nuestro nivel de preparación, nuestro presupuesto y nuestro horizonte temporal?". Este artículo te ofrece un readiness check estructurado para responder exactamente a esa pregunta.
Por qué la reacción contra lo composable está justificada
Entre 2021 y 2024, el sector vendió el composable commerce como una decisión binaria: o desmontabas tu monolito y migrabas a un stack MACH completo, o aceptabas quedarte técnicamente atrás. Esa narrativa produjo proyectos que se alargaron 18 meses, consumieron más presupuesto del previsto y ocuparon equipos que deberían haber estado impulsando el negocio.
La ola de corrección, respaldada por datos de Algolia y otros, muestra que el mercado ahora está diferenciando. El objetivo nunca fue lo composable como declaración arquitectónica. El objetivo es el resultado que lo composable posibilita: iteración de frontend más rápida, mejor experiencia de cliente, menor dependencia del proveedor.
Cuando en 2026 un operador de OXID o Shopware del mid market DACH se pregunta si debería pasar a un stack totalmente composable, la respuesta honesta es: posiblemente no de inmediato, y posiblemente no por completo.
El readiness check: tres escenarios
Escenario A: Full Composable
Estás listo para el full composable cuando se cumplen las cuatro condiciones siguientes:
- Equipo: Tienes un equipo de frontend engineering dedicado de al menos tres desarrolladores con experiencia en Nuxt, Next.js o frameworks comparables.
- Presupuesto: Tu presupuesto de transformación es de 150.000 euros o más y se puede planificar a lo largo de 12 meses.
- Estrategia de backend: Planeas cambiar o ampliar activamente tu backend en los próximos 18 meses (por ejemplo, pasando de Shopware a commercetools).
- Escala: Operas más de dos marcas o más de tres mercados, o planeas hacerlo en un plazo de dos años.
En este caso, un stack MACH completo se amortiza por sí mismo. La capa de frontend puede desarrollarse de forma independiente del backend, y la inversión arquitectónica se mantiene válida a través de varias generaciones de backend.
Escenario B: Headless First
Estás en el escenario headless first cuando el objetivo principal es desacoplar el frontend sin sustituir el backend:
- Estabilidad del backend: Tu backend (OXID, Shopware, Magento) es estable y no se sustituirá de forma fundamental en los próximos dos o tres años.
- Frustración con el frontend: Tu tema actual ha llegado a su límite, las puntuaciones de rendimiento son bajas y marketing no puede hacer cambios sin abrir un ticket de engineering.
- Presupuesto: El rango de presupuesto está entre 50.000 y 120.000 euros.
- Plazo: Quieres salir en vivo en 8 a 14 semanas, no en 18 meses.
Headless first significa: desacoplar el frontend, mantener el backend, añadir una capa de API en medio. Este es el movimiento que más solemos recomendar porque ofrece resultados rápidamente sin asumir el riesgo operativo de un cambio de backend. Lo que se hace visible tras la adopción de lo composable a lo largo de los dos años siguientes no es solo la arquitectura, sino la velocidad a la que trabaja después el equipo de marketing.
Escenario C: Experience Layer First
Estás en el escenario experience layer cuando el cuello de botella no es la arquitectura, sino el time to market de contenidos y campañas:
- La deuda técnica no es el problema: Tu configuración actual es técnicamente lo bastante sólida.
- Cuello de botella de marketing: Las landing pages, las páginas de campaña y los cambios de banner bloquean innecesariamente a engineering.
- Preparación agéntica: Quieres prepararte para los agentes de compra con IA y los datos estructurados para el commerce de ChatGPT sin reconstruir antes todo el stack.
- Presupuesto: Menos de 50.000 euros de presupuesto de transformación.
Aquí el concepto composable resulta valioso sin imponer la arquitectura MACH completa. Una Frontend Management Platform (FMP) se sitúa como capa de experiencia sobre el stack existente y da a los equipos de marketing la autonomía que necesitan sin tocar el backend. El nombre de la categoría no es casual: se creó precisamente para esta necesidad.
El cambio "APIs en lugar de temas" y lo que significa para lo composable
Un aspecto que suele perderse en el debate sobre la reacción contraria: los requisitos del storefront han cambiado de forma estructural. Los agentes de compra con IA (OpenAI Operator, Google Shopping AI, Perplexity Commerce) ya no navegan ni interactúan mediante interfaces visuales, sino mediante APIs y datos estructurados. Los temas resultan cada vez menos adecuados para ese fin.
Esto significa que incluso los equipos que hoy empiezan en el Escenario C están construyendo, con el enfoque adecuado de capa de experiencia, la base para el agentic commerce. Un frontend que entrega markup Schema.org correcto, expone datos de producto estructurados y está preparado para APIs no es un stack MACH completo, pero sí está listo para agentes.
La elección arquitectónica que haces hoy da forma a tu visibilidad en el commerce asistido por IA de mañana.
Por qué el mid market DACH necesita su propio benchmark
El mid market DACH no es Silicon Valley. Los equipos son más pequeños, los presupuestos se planifican con más cautela y los ciclos de decisión son más largos. Un readiness check posterior al K5 tiene que tener eso en cuenta.
La regla general: el full composable compensa para el mid market DACH a partir de dos marcas, dos mercados o un cambio de backend planificado en un plazo de 24 meses. Por debajo de esos umbrales, headless first o experience layer es la opción económicamente más sensata, sin cerrar el camino hacia lo composable.
La diferencia importante respecto a 2023: el enfoque de experience layer es hoy significativamente más maduro. Como demuestran los patrones de engineering actuales y la corrección de las FMP, ya no se trata de una cosa o la otra, sino del punto de entrada correcto en el continuo de lo composable.
Qué puedes hacer ahora
Tres pasos concretos para el readiness check en las próximas dos semanas:
- Evalúa la vida útil del backend: ¿Cuánto tiempo seguirá en funcionamiento el backend actual? Por debajo de dos años, es probable que el full composable no compense.
- Mide el cuello de botella del frontend: ¿Cuántos tickets de engineering al mes se crean únicamente por cambios de marketing? Más de 10 al mes es una señal clara a favor de headless first o experience layer.
- Comprueba la preparación para la IA: ¿El frontend actual entrega datos de producto estructurados? ¿Está implementado Schema.org? Si no es así, el paso hacia la experience layer tiene un valor doble.