Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
3 preguntas sobre frontend que deberías hacer en el stand #37
Dentro de 19 días, commercetools ocupa el stand #37 en K5 Berlín, del 23 al 24 de junio. La lista de partners es considerable: basecom, MGM Technology Partners y neteleven estarán presentes. Por la tarde sigue una sesión Pizza Rooftop con fulfilmenttools y KPS. Una presencia bien organizada, y una oportunidad concreta para cualquier CTO o responsable de arquitectura que llegue preparado.
Preparado significa: no acudir al stand con preguntas abstractas sobre la roadmap, sino con tres preguntas que determinan operativamente si tu estrategia de frontend seguirá sosteniéndose dentro de 36 meses. Este artículo ofrece exactamente eso. Ninguna crítica a commercetools, ningún hype, solo las preguntas que te harías igualmente al reevaluar el proyecto un año después del lanzamiento.
Pregunta 1: ¿cuánto cuestan realmente commercetools Frontend, el desarrollo a medida y una FMP a 36 meses?
El punto de decisión más habitual en proyectos con commercetools: el backend ya está evaluado y aprobado. Ahora llega la elección del frontend. Hay tres opciones sobre la mesa.
Opción A: commercetools Frontend (antes Frontastic). La ventaja es la integración directa con commercetools y la cercanía al vendor para el soporte. La pregunta abierta: ¿cómo se comporta el TCO cuando lanzas una segunda marca en 24 meses, abres un nuevo locale o conectas otra herramienta de marketing? commercetools Frontend está estrechamente integrado con el ecosistema de commercetools, y eso es a la vez una fortaleza y un factor de dependencia. ¿Cuánto cuesta cambiar un módulo de frontend en este escenario?
Opción B: frontend a medida con Next.js o Nuxt. Máximo control, pero un TCO realista a 36 meses incluye la implementación inicial, normalmente entre 200.000 y 1 millón de euros, un equipo de frontend permanente con guardias y mantenimiento, normalmente más de 300.000 euros al año, además del mantenimiento de conectores por cada actualización de la API de commercetools. Los equipos con capacidad interna calculan de forma distinta a quienes lo financian externamente.
Opción C: una Frontend Management Platform (FMP) como capa externa. Una FMP como la plataforma de Laioutr se sitúa sobre la API GraphQL de commercetools y desacopla el frontend del vendor de backend. Sin lock-in con Frontastic, sin un equipo de frontend a medida permanente. La contrapregunta para el stand: ¿cómo distingue la propia commercetools entre lo que aporta una FMP y lo que ofrece commercetools Frontend?
La pregunta concreta para el stand #37: ¿cuál es la evolución de precios fijable por contrato para commercetools Frontend a lo largo de 36 meses al escalar a dos marcas, dos locales y 10 nuevas integraciones?
La respuesta te dice si la opción A sigue siendo una partida presupuestaria previsible o si el TCO se dispara a partir de cierto umbral de escala. Encontrarás una comparación estructurada de las tres opciones en nuestro artículo sobre alternativas de frontend para commercetools.
Pregunta 2: ¿hasta qué punto es agent-aware el patrón actual de storefront?
Esta es la pregunta que rara vez se plantea en los stands en 2026, y precisamente por eso es la más relevante para una conversación con verdadera profundidad en K5.
El Agentic Commerce ya no es una tendencia de mercado que cobrará relevancia dentro de 18 meses. Los compradores impulsados por IA generan hoy tráfico medible en los storefronts. Cuando un agente autónomo ejecuta un flujo de investigación de producto o un proceso de compra, plantea al storefront exigencias estructuralmente distintas a las de un comprador humano: contratos de API estables, estructuras de datos legibles por máquinas, marcados de Schema.org con cobertura completa de Product y Offer, endpoints GraphQL consumibles de forma determinista.
La pregunta para el stand tiene dos partes.
Primera: ¿qué estabilidad tienen los contratos GraphQL de commercetools entre versiones de la API? Un agente que consume datos de producto y de precios necesita un endpoint que no cambie estructuralmente con cada release. ¿Cuál es la política de versionado actual de commercetools para la Storefront API?
Segunda: ¿qué entrega commercetools Frontend como salida legible por máquinas? ¿El renderizado del storefront está optimizado para datos estructurados, JSON-LD, campos de Schema.org con cobertura completa, o eso es tarea del cliente en la implementación del frontend?
Cuando combinas un backend composable como commercetools con un frontend preparado para agentes, el resultado es un patrón de arquitectura pensado para la próxima generación de compradores. Cuando el renderizado del storefront no incluye la capa agent-aware, eso se convierte en un proyecto de desarrollo a medida. La pregunta en el stand: ¿quién es responsable en commercetools de la capa de storefront preparada para agentes, el vendor, el partner o el cliente?
Este tema es central en el Pillar 4 de nuestra estrategia de contenidos. Encontrarás más sobre el estado del composable commerce y los patrones de arquitectura agent-aware en nuestro artículo State of Composable Commerce 2026.
Pregunta 3: ¿qué le pasa al frontend cuando se sustituye un módulo de backend?
Este es el examen de realidad de la promesa composable. commercetools se posiciona sobre la capacidad de intercambiar capacidades de backend individuales: OMS, PIM, motor de precios, lógica de promociones. La teoría es correcta. La cuestión es si eso también se cumple en el frontend.
Un escenario concreto: tienes commercetools en el backend y quieres sustituir el motor de promociones por un proveedor externo, por ejemplo porque la lógica nativa de descuentos de commercetools llega a su límite con reglas de precios B2B complejas. ¿Qué le pasa al frontend en ese momento?
Con un frontend a medida enganchado directamente a la API: el equipo de frontend tiene que conectar el nuevo motor de promociones, actualizar los componentes existentes, probar y desplegar. Los plazos dependen de la profundidad de la integración.
Con commercetools Frontend: ¿cómo se comporta el tooling de frontend cuando un componente de backend se sustituye por un proveedor ajeno a commercetools? ¿El frontend está calibrado exactamente para esa combinación de backend o abstrae los límites entre módulos?
Con una FMP que utiliza una Unified Data Layer: la capa de orquestación normaliza los datos de producto, inventario y precios de varias fuentes en un esquema de frontend unificado. Cambiar un módulo de backend significa, en principio: nueva configuración de conector en la capa de datos, sin reescribir el frontend. Esa es la promesa de desacoplamiento del composable commerce, cumplida en la capa de frontend.
La pregunta para el stand #37: ¿existe un caso documentado en el que un cliente de commercetools haya sustituido un módulo de backend sin reescribir el frontend, y cuál fue el esfuerzo concreto en la capa de frontend?
La respuesta muestra si la arquitectura composable en commercetools también se vive del lado del frontend o si la promesa composable acaba en el backend.
Qué consiguen estas tres preguntas en el stand
No te devuelven una presentación comercial. Te devuelven la información que necesitas para tomar una decisión de arquitectura bien fundamentada.
El TCO a 36 meses no es abstracto: tiene tres motores, la implementación inicial, el mantenimiento continuo y los costes de escalado. Los tres varían de forma significativa según el modelo de frontend.
La arquitectura agent-aware no es un nice-to-have en 2026. Quien planee un rediseño de storefront en los próximos 12 meses y no incorpore la capa preparada para agentes, lo construirá dos veces.
La estabilidad ante el cambio de módulos de backend es el examen de realidad de la promesa composable. Si hay que reconstruir el frontend con cada cambio de backend, el composable commerce en el backend es media respuesta.
Las tres preguntas están conectadas: describen la capa de frontend como una decisión de arquitectura independiente que debería tomarse y evaluarse por separado del vendor de backend.
Si después de K5 quieres una evaluación estructurada del frontend para tu setup de commercetools, es decir, cómo se comportan las tres opciones (Frontastic, desarrollo a medida, FMP) frente a tus escenarios concretos de escalado, el punto de partida es nuestra página Headless Frontend for commercetools y en ella documentamos cómo Laioutr, como Frontend Management Platform, se conecta a commercetools GraphQL y qué significa eso en concreto para el TCO, el time-to-market y la independencia del backend.
basecom, MGM y neteleven conocen la realidad de la implementación por su trabajo en proyectos. Las preguntas anteriores funcionan igual de bien en las conversaciones con los partners que en el propio stand de commercetools.
K5, del 23 al 24 de junio, stand #37. Faltan 19 días.
Recursos relacionados de Laioutr
Descubre cómo se aplica aquí la capa de frontend de Laioutr: