Nuestra salida de Shopify: evaluar alternativas de comercio electrónico desacoplado

Shopify hace muy bien lo que se propone. El proceso de pago tiene una buena tasa de conversión, el ecosistema de apps es amplio y la fiabilidad operativa es excelente. Para un comerciante que quiere vender productos sin construir infraestructura, su propuesta de valor resulta difícil de cuestionar. Conviene decirlo claramente antes de explicar por qué cerramos nuestra tienda en la plataforma: la decisión no se debió a que Shopify fuera inadecuado en términos absolutos, sino a que no encajaba con los requisitos operativos específicos que habíamos ido acumulando.

La mayoría de los relatos sobre el abandono de Shopify se centran en las comisiones por transacción, las limitaciones de los temas o el deseo de tener una tienda con una interfaz personalizada. Son razones reales, pero no las más importantes. El problema de fondo es que Shopify está optimizado para un perfil concreto de comerciante: gran volumen, catálogo estandarizado y venta directa al consumidor. Sus limitaciones generan dificultades cuando los requisitos se apartan de ese perfil.

Lo que Shopify hizo bien

El proceso de pago es la parte más sólida de la propuesta de valor de Shopify. Años de optimización en millones de tiendas han producido un flujo que convierte visitas en compras, gestiona bien los casos excepcionales e integra métodos de pago en distintos mercados sin requerir integraciones a medida. Construir desde cero un proceso comparable supone un proyecto de varios meses y una carga importante de mantenimiento continuo.

La capa operativa —gestión de pedidos, gestión logística de pedidos, devoluciones y herramientas de atención al cliente— tiene una madurez similar. La interfaz de administración impone una forma concreta de trabajar, pero refleja una experiencia operativa real sobre cómo funcionan los flujos de comercio electrónico a escala. Para los equipos que necesitan incorporar personal no técnico a la gestión de pedidos, la experiencia de uso de Shopify es considerablemente más sencilla que la de cualquier alternativa con frontend desacoplado disponible actualmente.

El ecosistema de apps, pese a su reputación de costos ocultos, resuelve problemas reales. Plataformas de reseñas, facturación de suscripciones, programas de fidelización y analítica avanzada: estas integraciones funcionan porque Shopify ha estandarizado los webhooks, los modelos de datos y la autenticación de los que dependen las apps de terceros. En una arquitectura con frontend desacoplado, cada integración debe desarrollarse a medida o adquirirse a proveedores que quizá no ofrezcan soporte nativo para la plataforma elegida.

Las limitaciones que se convirtieron en obstáculos

Las limitaciones de internacionalización, o i18n, fueron el primer punto de fricción. Aunque el soporte multilingüe de Shopify ha mejorado mucho desde sus inicios, sigue tratando los mercados no anglófonos como una prioridad secundaria. Gestionar contenido en una docena de idiomas desde su interfaz de administración resulta complicado, y la dificultad aumenta con el tamaño del catálogo. Las apps de traducción ayudan, pero añaden costos y complejidad de sincronización que una solución nativa eliminaría.

Con el tiempo, la propiedad de los datos se convirtió en el problema más fundamental. Todos los datos operativos relevantes —historial de pedidos, registros de clientes y catálogo de productos— residen en la base de datos de Shopify, accesible mediante una API que Shopify controla. Los límites de solicitudes de esa API, las políticas de conservación de datos y los formatos de exportación los determina Shopify, no el comerciante. Para los equipos que necesitan ejecutar cargas de trabajo analíticas sobre sus propios datos operativos, esto es una limitación estructural, no una opción de configuración.

La complejidad del modelo de precios fue una tercera limitación. Los productos con muchas variantes, los precios personalizados por segmento de clientes y los flujos basados en cotizaciones para clientes empresariales chocan con los límites de variantes de Shopify (100 por producto hasta que Shopify elevó el límite a 2 048 en octubre de 2025) y sus estructuras de precios, y obligan a adoptar soluciones alternativas cada vez más complejas. La complejidad resultante de las plantillas Liquid se convierte en un problema de mantenimiento que empeora a medida que crece el catálogo.

La evaluación: Medusa v2, Saleor y Commerce.js

La evaluación se organizó en torno a cuatro criterios: propiedad de los datos —control total de la base de datos, sin límites de API impuestos por el proveedor—; alcance de i18n —soporte nativo para varias monedas, varios idiomas y precios regionales—; experiencia de desarrollo —calidad de la documentación, soporte de TypeScript y flujo de desarrollo local—; y madurez operativa —despliegues en producción, fallos conocidos y tamaño de la comunidad—.

Medusa v2 obtuvo los mejores resultados en experiencia de desarrollo. La reescritura de v2 supone una mejora sustancial respecto a la arquitectura original: el sistema de módulos está bien diseñado, los tipos de TypeScript son completos y el flujo de desarrollo local es rápido. La documentación ha mejorado considerablemente y refleja un equipo que se toma en serio la experiencia de desarrollo. La limitación es la madurez operativa: v2 es relativamente reciente (Medusa 2.0 se lanzó en octubre de 2024), y los casos de despliegue en producción son menos numerosos y diversos que en plataformas más consolidadas. Los equipos que migran a Medusa son, en un sentido real, pioneros en su adopción.

Saleor es la más probada de las tres, con una base mayor de despliegues en producción y una API GraphQL bien diseñada. Su arquitectura multicanal —que separa el concepto de «canales» para distintos mercados, interfaces de tienda o segmentos de clientes— gestiona con más elegancia que las alternativas la complejidad de precios y catálogos que nos llevó a abandonar Shopify. Tiene la mayor madurez operativa de las tres plataformas evaluadas. A cambio, la curva de aprendizaje es más pronunciada y su API centrada en GraphQL requiere invertir en herramientas antes de poder trabajar con productividad.

Commerce.js ocupa una posición distinta: es una API con frontend desacoplado, en lugar de una plataforma de comercio completa, y está diseñada para combinarse con otros servicios. Es una opción adecuada para equipos con amplios recursos de ingeniería que quieren un control detallado sobre cada componente. Para quienes buscan reducir la carga operativa de Shopify sin añadir una carga de ingeniería equivalente de otra forma, probablemente no sea la opción adecuada. Al ser una API alojada, tampoco ofrece control total sobre la base de datos, nuestro primer criterio. Además, a octubre de 2026, Chec, la empresa detrás de Commerce.js, ha archivado su organización de GitHub (en octubre de 2024), por lo que conviene comprobar el estado actual del servicio antes de considerarlo.

El proceso de migración

El costo más subestimado al cambiar de plataforma es la migración de datos, no la del código. Trasladar el catálogo de productos, los registros de clientes y el historial de pedidos desde Shopify a una nueva plataforma requiere scripts de extracción a medida, transformar los datos para adaptarlos al esquema de destino y gestionar con cuidado casos excepcionales: productos con más de 100 variantes, clientes con historiales de direcciones complejos o pedidos preparados y enviados parcialmente. Estos casos representan un porcentaje pequeño de los registros, pero una gran parte del tiempo de ingeniería de la migración.

La transición operativa —el periodo en que los pedidos deben pasar por ambos sistemas mientras se valida la migración— requiere una planificación cuidadosa para evitar duplicar la preparación y el envío de pedidos o las comunicaciones con los clientes. En esta fase, la mayoría de las migraciones encuentran problemas que no se habían previsto, porque los casos excepcionales relevantes dependen del catálogo y del historial de pedidos del comerciante, no del comercio electrónico en general.

La lección de esta evaluación y de observar a otros tomar decisiones similares es que la calidad de la planificación de la migración tiene más consecuencias que la elección de plataforma. Medusa y Saleor pueden sostener operaciones de comercio electrónico en producción, como podía hacerlo Commerce.js en el momento de nuestra evaluación. Los equipos que migran con éxito a una arquitectura con frontend desacoplado son los que invierten en comprender las diferencias entre modelos de datos antes de comenzar la migración, no durante ella.