commercetools Frontend Pricing y TCO: lo que el frontend cuesta realmente en un paquete composable

La mayoría de las conversaciones sobre el coste de commercetools se detienen en la API. Los equipos calculan la licencia del backend de commerce, el volumen de peticiones y el presupuesto de integración, y luego tratan el storefront como una línea que ya resolverá el equipo técnico. El resultado es una cifra de Total Cost of Ownership (TCO) que parece completa en una diapositiva pero que deja fuera precisamente la capa con la que interactúan los clientes. commercetools es un backend de commerce headless, lo que significa que el frontend no está incluido. Alguien tiene que construirlo, alojarlo, mantenerlo y operarlo, y ese trabajo dura toda la vida del storefront, no solo el trimestre del lanzamiento. Este es un desglose factual de dónde nace el coste del frontend en un stack de commercetools, sin cifras inventadas, para que puedas dimensionar los factores en tu propio caso.

Qué incluye commercetools en el frontend y qué no

commercetools entrega APIs, no un storefront. Obtienes el backend de Composable Commerce (datos de producto, carrito, pedido y cliente vía GraphQL y REST), el Merchant Center para la administración del backend y, según tu paquete, herramientas como Frontend (el antiguo Frontastic) como capa opcional. Lo que no obtienes de serie es un storefront operativo, con tu marca, preparado para SEO y con un editor de páginas que tu equipo de marketing pueda usar sin un desarrollador.

Esa brecha es intencionada. Composable Commerce desacopla deliberadamente el backend de la capa de presentación para que puedas elegir tu propio enfoque de frontend. La contrapartida es que la capa de presentación pasa a ser responsabilidad tuya. Tanto si adoptas commercetools Frontend, un framework frontend independiente o una Frontend Management Platform, el storefront es un centro de coste propio, con su perfil de desarrollo, hosting y mantenimiento. Leer el pricing del backend de commercetools como el coste total de salir a producción es el error de presupuesto más habitual en un proyecto composable.

Construir o comprar el storefront

Una vez fijado el backend, la primera decisión real es construir o comprar el frontend. Ambas opciones son válidas y ambas tienen coste, solo que de distinta forma.

La vía de construir

Un storefront a medida, normalmente sobre un framework como Next.js, Nuxt o Remix, te da control total. Tu equipo es dueño de los componentes, de la estrategia de rendering y del cableado de integración hacia commercetools y hacia cada servicio best of breed (búsqueda, pagos, suscripciones). El coste aquí se concentra al inicio y luego continúa: un equipo frontend dedicado hasta el lanzamiento y después una capacidad estable para mantenerlo al día mientras el backend, los navegadores y el framework siguen avanzando.

La vía de comprar

Comprar significa adoptar un producto de frontend, ya sea commercetools Frontend o una plataforma frontend headless y composable, que aporta el armazón del storefront, una superficie de edición y patrones de integración ya construidos. Cedes algo de control de bajo nivel a cambio de un camino más corto al lanzamiento y de un compromiso de ingeniería permanente menor. El coste se desplaza de los salarios hacia una cuota de plataforma más el esfuerzo de configuración.

El planteamiento honesto no es "construir es caro, comprar es barato". Es que construir convierte el coste en plantilla y tiempo de calendario, mientras que comprar lo convierte en una cuota predecible y en una iteración más rápida. Cuál resulta más barato a tres años depende casi por completo de los costes ocultos que siguen.

Los costes ocultos de un frontend propio

Cuando los equipos subestiman el TCO del frontend, suele ser porque estos cuatro factores faltan en el modelo. Ninguno aparece en una licencia de backend.

Hosting y entrega

Un storefront necesita infraestructura de rendering, una CDN, rendering en el edge o en servidor para SEO y rendimiento, optimización de imágenes y caching. Son costes recurrentes que escalan con el tráfico y con el número de mercados e idiomas que atiendes. Los picos (rebajas, campañas) marcan el dimensionamiento, así que pagas un margen que usas unas pocas veces al año.

Mantenimiento y actualizaciones

Un frontend nunca está terminado. Las versiones mayores de framework, los parches de seguridad de dependencias, los cambios en los navegadores, los requisitos de accesibilidad y las actualizaciones de la API de commercetools exigen atención continua de ingeniería. Esta carga de mantenimiento es fácil de omitir en un presupuesto de lanzamiento y suele ser la mayor partida plurianual, porque nunca se detiene y compite directamente con el desarrollo de nuevas funcionalidades.

Editor y herramientas de autoría

Si marketing no puede cambiar una landing page, un hero o un bloque de campaña sin un desarrollador, cada cambio de contenido se convierte en un ticket. El coste aparece entonces dos veces: como tiempo de desarrollo dedicado a tareas de contenido y como un time to market más lento para las campañas. Una capa sólida de edición visual y content management no es un extra en términos de TCO: es lo que mantiene los cambios rutinarios fuera del backlog de ingeniería.

Tiempo de desarrollo y coste de oportunidad

El factor más infravalorado es en qué invierten la semana los desarrolladores frontend senior. El tiempo dedicado a rehacer una cabecera, conectar un nuevo proveedor de pago al checkout o depurar una regresión de rendering es tiempo que no se dedica al trabajo de experiencia que os diferencia. En un stack composable la promesa es best of breed en todas partes, pero cada servicio best of breed sigue teniendo que integrarse y renderizarse, y esa superficie de integración vive en el frontend.

Cómo una Frontend Management Platform cambia las cuentas del TCO

Una Frontend Management Platform (FMP) se sitúa entre el backend de commercetools y el storefront y asume exactamente los factores anteriores. No sustituye a commercetools: lo renderiza. La cuestión no es que una FMP sea gratis, tiene su propia cuota, sino que consolida varias líneas de coste separadas en una y quita a tu equipo la carga permanente de mantenimiento.

En concreto, una FMP cambia las cuentas en cuatro puntos. Hosting, rendering y entrega pasan a formar parte de la plataforma en lugar de ser infraestructura que dimensionas y operas tú. Las actualizaciones de framework y dependencias ocurren a nivel de plataforma, así que tu equipo no gasta sprints en mantenimiento que no genera valor nuevo para el cliente. La edición se traslada a una superficie visual, así que los cambios de contenido y campaña salen del backlog de ingeniería. Y la integración con servicios best of breed pasa por una capa de datos unificada, así que conectar búsqueda, pagos o suscripciones es configuración en lugar de un desarrollo a medida cada vez. Este es el modelo que hay detrás del Frontend as a Service: la capa frontend se convierte en un servicio operado con un coste predecible, en lugar de un proyecto que tu equipo financia y mantiene indefinidamente.

El resultado no es automáticamente más barato en el primer año. Un equipo bien dotado que construya un storefront acotado puede lanzar de forma competitiva por cualquiera de las dos vías. La diferencia se acumula en los años dos y tres, donde la vía propia sigue pagando mantenimiento, margen de hosting y tiempo de desarrollo en contenido, mientras que la vía FMP los mantiene como cuota fija y libera a esos mismos ingenieros para el trabajo que genera ingresos.

Frontend propio frente a frontend gestionado por una FMP: los factores del TCO

• Factor de TCO | Frontend propio | Frontend gestionado por FMP
• Desarrollo inicial | Equipo frontend dedicado hasta el lanzamiento | Configuración sobre un armazón existente
• Hosting y entrega | Dimensionado, pagado y operado internamente | Incluido en la cuota de plataforma
• Actualizaciones de framework y seguridad | Responsabilidad continua del equipo | Gestionadas a nivel de plataforma
• Herramientas de edición | Desarrolladas o licenciadas aparte | Superficie de edición visual incluida
• Integración best of breed | Desarrollo a medida por servicio | Configuración vía una capa de datos unificada
• Forma del coste | Plantilla más infraestructura | Cuota recurrente predecible
• Velocidad de cambio de contenido | Ticket a desarrollo | Autonomía de marketing

FAQ

¿La licencia de commercetools incluye un storefront? No. commercetools es un backend de commerce headless. Aporta APIs, el Merchant Center y herramientas de frontend opcionales, pero un storefront operativo y con tu marca es una decisión aparte de construir o comprar, con su propio perfil de coste.

¿Cuál es el mayor coste oculto en un frontend de commercetools? Normalmente el mantenimiento continuo: actualizaciones de framework, parches de seguridad y cambios de API que nunca se detienen y que compiten con el desarrollo de nuevas funcionalidades. Justo detrás vienen el margen de hosting para los picos de tráfico y el tiempo de desarrollo dedicado a cambios de contenido.

¿Construir un frontend a medida siempre es más caro que comprarlo? No en el primer año. Un equipo enfocado puede lanzar de forma competitiva. La brecha se abre a lo largo de varios años, donde la vía propia sigue pagando mantenimiento, hosting y tiempo de desarrollo en cambios rutinarios.

¿Cómo reduce el TCO una Frontend Management Platform? Consolida hosting, rendering, actualizaciones, herramientas de edición e integración en una única capa operada con una cuota predecible, y quita a tu equipo la carga permanente de mantenimiento, de modo que los ingenieros dedican el tiempo al trabajo que os diferencia.

¿Tenemos que dejar commercetools para usar una FMP? No. Una FMP renderiza el backend de commercetools a través de sus APIs. El backend sigue funcionando como tu fuente de verdad de commerce; la FMP se ocupa de la capa de presentación y entrega que va encima.

Más contenido de la Laioutr Platform

• Composable Headless Frontend: cómo se conecta la capa frontend a un backend de commercetools sin un desarrollo a medida.
• Frontend as a Service: el modelo de frontend operado que convierte construir y mantener en una cuota predecible.
• Agentic Frontend Management Platform: cómo los agentes de IA asumen los cambios rutinarios de frontend que de otro modo costarían tiempo de desarrollo.
• Composable Digital Experience Platform: dónde encajan la edición visual y el content management en un stack composable.

Siguiente paso

¿Quieres dimensionar la capa frontend de tu TCO de commercetools con factores reales en lugar de una línea provisional? Habla con el equipo de Laioutr y repasaremos dónde está realmente el coste de tu storefront y qué cambiaría un frontend operado.