Ecommerce a medida vs Shopify vs headless en 2026: guía

Para la mayoría de las tiendas online europeas, el SaaS (Shopify, BigCommerce) es la opción por defecto correcta en 2026: se lanza en semanas, su coste total es predecible y deja pagos y cumplimiento normativo casi por completo fuera de tu mesa. El desarrollo de ecommerce a medida solo compensa cuando el propio negocio no encaja en una plantilla: precios complejos, configuradores de producto, lógica de contratos B2B, productos regulados o un fulfilment poco habitual. El headless se sitúa entre ambos y merece la pena cuando la tienda es el diferencial y tienes un equipo de front-end que la asuma.

El resto de esta guía te da la tabla comparativa, los trade-offs honestos de pasar a headless, el checklist de migración y de cumplimiento en la UE, y una lista de decisión por tramo de facturación.

Las cuatro formas de construir una tienda online

SaaS. Shopify, BigCommerce y Wix alojan todo: tienda, catálogo, checkout, pagos, actualizaciones. Pagas una suscripción más un porcentaje por transacción (Shopify cobra un extra cuando no usas Shopify Payments, algo que importa en los países donde no está disponible). La personalización pasa por temas, apps y, en Shopify, por Functions y la extensibilidad del checkout. Shopify Plus y BigCommerce Enterprise añaden funciones B2B, límites de API más altos y multitienda.

Open-source, autoalojado. WooCommerce (WordPress), Magento Open Source / Adobe Commerce y PrestaShop te dan el código fuente y la factura del hosting. WooCommerce es barato para empezar y va bien con catálogos pequeños, pero escala a base de plugins de calidad desigual. Adobe Commerce es el monolito más completo para B2B y multitienda, y también el más caro de operar: necesita desarrolladores con experiencia, infraestructura afinada y una disciplina seria de actualizaciones. PrestaShop sigue siendo popular en Francia, España e Italia para catálogos medianos.

Headless / composable. Un motor de comercio expuesto vía API —Medusa (Node, open-source), Saleor (Python/GraphQL), commercetools (SaaS, enterprise) o Shopify con su Storefront API y el framework Hydrogen— más una tienda que construyes con Next.js, Remix/Hydrogen, Nuxt o una app móvil. El contenido suele venir de un CMS aparte, la búsqueda de Algolia o Meilisearch, y es tu equipo quien conecta las piezas.

Totalmente a medida. Tu propio modelo de dominio para productos, precios, carrito, pedidos y fulfilment, normalmente construido sobre un framework como Laravel, NestJS, Django o Spring, con un PSP para los pagos. Nada viene gratis; todo es exactamente lo que el negocio necesita.

Tabla comparativa: SaaS vs open-source vs headless vs a medida

Criterio	SaaS (Shopify, BigCommerce, Wix)	Open-source autoalojado (WooCommerce, Adobe Commerce, PrestaShop)	Headless / composable (Medusa, Saleor, commercetools, Hydrogen)	Totalmente a medida
Modelo de coste total	Suscripción + % por transacción + apps; poca inversión inicial, crece con la facturación	Hosting + desarrolladores + extensiones; Adobe Commerce añade una licencia ligada al GMV	Motor (gratuito o con licencia) + construcción de la tienda + hosting + integración	Coste de construcción inicial, después mantenimiento, hosting, guardias
Techo de personalización	Límites de tema y app; restricciones de checkout aliviadas por Functions en Plus	Alto en código, pero las actualizaciones del core chocan con la personalización pesada	Alto en la tienda; motor extensible con plugins o servicios	Ilimitado
Control de rendimiento y SEO	Buenos valores por defecto, poco control sobre el renderizado, URLs parcialmente fijas (/products/, /collections/)	Control total, pero los monolitos PHP necesitan caché para rendir	Control total del renderizado, URLs, Core Web Vitals	Control total
Funciones B2B	Básicas en planes estándar; sólidas en Plus / B2B Edition	Adobe Commerce fuerte; WooCommerce vía plugins	commercetools y Saleor fuertes; Medusa en crecimiento	Lo que modeles
Integraciones (ERP, PIM, WMS)	Grandes ecosistemas de apps; la sincronización profunda con ERP suele requerir middleware	Conectores maduros para SAP, Dynamics, Odoo	API-first, tú escribes o compras los conectores	Lo escribes todo
Propiedad y lock-in	Datos exportables, la lógica y las apps no	Eres dueño del código y de los datos	Eres dueño de la tienda y de los datos; el motor puede ser SaaS	Propiedad total
Carga operativa	Casi nula	Alta: parches, escalado, alcance PCI	Media a alta: dos o más deployables	Alta
Tiempo hasta el lanzamiento	Días a semanas	Semanas a meses	Meses	Meses a un año

La línea que decide la mayoría de los proyectos es techo de personalización frente a carga operativa. Cada paso hacia la derecha compra control y cuesta una capacidad de operación que debes dotar de personal.

Cuándo se justifica el desarrollo de ecommerce a medida

El desarrollo a medida se justifica cuando la lógica central de la tienda no puede expresarse en el modelo de datos de una plataforma sin apaños constantes. Los casos recurrentes:

• Precios complejos. Tramos de volumen por grupo de clientes, precios de contrato negociados por cuenta, tarifas por moneda y país, recargos dinámicos (metales, transporte, energía). El SaaS resuelve algunos de estos casos; combinados, te empujan hacia apps que no se hablan entre sí.
• Configuradores y productos bajo pedido. Muebles, ventanas, piezas industriales, ropa personalizada. Un configurador necesita un motor de reglas, cálculo de precio al vuelo y, a menudo, una previsualización 3D; consulta nuestra guía sobre aplicaciones web 3D con WebGL y Three.js. La línea del carrito es una especificación, no un SKU.
• Comercio B2B. Cuentas de empresa con compradores y aprobadores, órdenes de compra, pago a 30 días, presupuestos que se convierten en pedidos, catálogos punchout, stock por almacén desde el ERP. Un modelo multivendedor sube aún más el listón; nuestra guía de desarrollo de marketplaces B2B cubre ese caso en profundidad.
• Productos regulados. Fármacos, dispositivos médicos, alcohol, tabaco, productos químicos, accesorios de armas. Verificación de edad o licencia, restricciones de venta por país, trazabilidad por lote y número de serie, documentación obligatoria junto al pedido.
• Fulfilment poco habitual. Suscripciones con cadencias mixtas, alquileres, reservas ligadas al inventario, envíos parciales desde varios proveedores, recogida en cientos de tiendas con stock local, o productos que salen del almacén de un partner en tu nombre.

Si ninguno de estos casos aplica, la personalización que quieres probablemente es cosmética, y un tema más unas cuantas apps te bastan. Una prueba útil: escribe los cinco flujos que hacen distinto a tu negocio e intenta modelarlos en una tienda de prueba. Si necesitas más de dos apps que deban ponerse de acuerdo sobre un mismo pedido, vas camino de a medida o headless.

Headless commerce: los trade-offs que nadie incluye en el pitch

El headless se vende a menudo como "lo mejor de los dos mundos". Puede serlo, con estos costes dichos con claridad:

Ahora operas una aplicación de tienda. Un front-end en Next.js o Hydrogen es un producto con sus propios despliegues, monitorización, error budgets y actualizaciones de dependencias. El carrito, las redirecciones del checkout, la búsqueda, la visualización de promociones y la gestión de 404 pasan a ser bugs tuyos. Shopify Hydrogen sobre el hosting Oxygen reduce la parte de hosting; no reduce el código que es tuyo.

Dos sistemas, un pedido. El precio que muestra la tienda debe coincidir con lo que cobra el motor. El stock debe estar suficientemente fresco en el checkout. El contenido del CMS no puede referenciar productos que ya no existen. Cada costura necesita un contrato, una política de caché y tests.

Las apps dejan de funcionar. La mayor parte del ecosistema de apps de Shopify se inyecta en temas Liquid. Con una tienda headless reimplementas reseñas, upsells, guías de tallas y banners de consentimiento, o eliges apps que expongan una API.

Los costes se desplazan, no desaparecen. Ahorras en límites de tema y ganas en rendimiento y control de SEO, pero pagas un equipo de front-end y el trabajo de integración que un monolito resolvía internamente. commercetools tiene precios de enterprise; Medusa y Saleor son gratuitos de usar, pero no de operar.

Donde el headless gana con claridad: varias tiendas (web, app, quioscos, marketplaces) sobre un único motor, tiendas con mucho contenido editorial, sitios donde los Core Web Vitals mueven ingresos y empresas cuya ventaja competitiva es la propia experiencia de compra.

Un ejemplo mínimo de la costura que asumes, usando la store API de Medusa desde una tienda renderizada en servidor:

// Tienda (server component de Next.js) obteniendo un producto de Medusa
const res = await fetch(`${process.env.MEDUSA_URL}/store/products/${handle}`, {
  headers: { "x-publishable-api-key": process.env.MEDUSA_PUBLISHABLE_KEY! },
  next: { revalidate: 60 }, // precio desactualizado hasta 60s — acéptalo o acórtalo
});
const { product } = await res.json();

Ese valor de revalidate es una decisión de negocio sobre cuán desactualizado puede estar un precio, y ahora es tuya.

Migrar de plataforma sin perder ingresos

Las migraciones fallan en tres frentes: URLs, señales SEO y datos.

URLs. Exporta todas las URLs indexadas desde Search Console y los logs del servidor. Mapea cada una a su nueva dirección y publica un 301 por cada cambio. Las rutas varían según la plataforma: Shopify usa /products/slug y /collections/slug, WooCommerce /product/slug, y los desarrollos a medida lo que tú decidas. Conserva la estructura antigua cuando puedas; una redirección es un coste que pagas en cada rastreo.

# Archivo de redirecciones al estilo Cloudflare / Netlify
/collections/office-chairs   /es/categoria/sillas-de-oficina/   301
/products/ergo-chair-x1      /es/p/ergo-chair-x1/               301

Señales SEO. Conserva títulos, meta descriptions, etiquetas canonical, hreflang entre versiones de idioma, datos estructurados de producto (Product, Offer, AggregateRating) y enlaces internos. Regenera el sitemap el día del lanzamiento y envíalo. Espera unas semanas de ruido en el posicionamiento; una caída que persiste más tiempo suele significar URLs abandonadas o páginas más lentas.

Datos. Productos y variantes se migran limpiamente. Clientes, historial de pedidos, tarjetas regalo, saldo en tienda y métodos de pago guardados, no. Los tokens de tarjeta viven en el PSP; si mantienes el mismo PSP (Stripe, Adyen, Mollie) normalmente puedes conservar los tokens; si no, los clientes vuelven a introducir la tarjeta. Las suscripciones son la migración más difícil y merecen su propio ensayo. Trata el traslado de datos como cualquier migración de datos en producción: ensáyala en una copia, mídela y conserva una vía de rollback.

Haz el cambio en un solo paso, tras un ensayo completo en una copia de staging con datos reales. Las migraciones página a página te dejan operando dos plataformas y reparten las señales SEO entre ambas.

Pagos y cumplimiento normativo en Europa

PSD2 y SCA. Los pagos con tarjeta en el EEE requieren autenticación reforzada de cliente, implementada mediante 3-D Secure 2. Tu PSP gestiona el desafío y las exenciones (importe bajo, riesgo bajo, beneficiarios de confianza, transacciones iniciadas por el comercio para suscripciones). Tu checkout debe sobrevivir a la redirección o al desafío en la propia página sin perder el estado del carrito, y debe gestionar el resultado asíncrono mediante webhooks en lugar de fiarse del retorno del navegador.

PCI DSS. Usa hosted fields, una redirección o un checkout alojado por el PSP para que los datos de tarjeta nunca toquen tus servidores. Eso te mantiene en el nivel más ligero de autoevaluación. Una plataforma a medida que renderiza su propio formulario de tarjeta con el JavaScript del PSP sigue siendo válida; una que envía números de tarjeta a su backend, no.

IVA y la ventanilla única (OSS). Desde el paquete de IVA del comercio electrónico de la UE, las ventas B2C transfronterizas por encima del umbral común de la UE tributan al tipo del país del comprador y se declaran a través de la OSS en una única declaración. Tu plataforma debe aplicar el tipo correcto por destino y categoría de producto, guardar evidencias de la ubicación del cliente y emitir informes por país. Shopify y BigCommerce lo traen incorporado; los desarrollos open-source y a medida suelen integrar un servicio fiscal o mantener tablas de tipos con un responsable definido. Para B2B, valida los NIF-IVA a través de VIES y aplica la inversión del sujeto pasivo.

RGPD. Consentimiento para marketing y cookies no esenciales, base legal para el procesamiento de pedidos, plazos de conservación para pedidos frente a datos de marketing, acuerdos de encargo de tratamiento con cada encargado (PSP, email, analítica, hosting) y la capacidad de exportar o borrar a un cliente. El SaaS te da herramientas; las obligaciones siguen siendo tuyas como responsable del tratamiento. Nuestra guía de RGPD para empresas europeas cubre la parte de ingeniería, y la guía de desarrollo de sistemas de pago profundiza en la integración con el PSP.

Accesibilidad. La European Accessibility Act se aplica a los servicios de ecommerce desde 2025. Las tiendas a medida y headless deben cumplirla en su propio código; los temas SaaS te llevan parte del camino y no más.

Checklist de decisión por tramo de facturación y complejidad

Usa la facturación online anual como primer filtro y la complejidad como segundo.

Por debajo de aproximadamente 1 M€ de facturación online

• Shopify o BigCommerce. WooCommerce si el sitio ya se apoya mucho en WordPress y el catálogo es pequeño.
• No construyas. Cada euro debería ir a producto, tráfico y conversión.
• Excepción: un producto regulado o un configurador que ninguna app soporte; en ese caso, un pequeño módulo a medida detrás de una tienda SaaS, no una plataforma completa.

1 M€–10 M€

• Quédate en SaaS (valora Shopify Plus o BigCommerce Enterprise) salvo que apliquen dos o más de los casos de "se justifica el desarrollo a medida".
• El headless tiene sentido si cuentas con un equipo de front-end interno y la experiencia de la tienda es la ventaja competitiva.
• Adobe Commerce o un motor headless si los precios por contrato B2B y el stock gestionado desde el ERP son centrales.

10 M€–50 M€

• Cualquier opción es asumible; la cuestión es dónde quieres ser dueño del riesgo.
• Headless sobre Shopify Plus, commercetools o Saleor cuando necesitas varias tiendas o mercados.
• A medida cuando la lógica de precios, fulfilment o cumplimiento es el negocio, y ya operas software en producción.

Por encima de 50 M€ o modelos de marketplace

• Composable o a medida es la norma; las plataformas SaaS chocan con límites de API, restricciones de checkout y techos de comisiones por transacción.
• Presupuesta un equipo de plataforma, no un proyecto. Lee nuestro artículo sobre cuánto cuesta el software a medida en Europa antes de comprometerte.

En cualquier tramo, hazte estas preguntas:

1. ¿Qué cinco flujos hacen distinto a nuestro negocio, y puede una tienda de prueba modelarlos?
2. ¿Quién arregla el checkout a las 3 de la madrugada en el Black Friday?
3. ¿Cuál es el coste de salida de cada opción dentro de tres años?
4. ¿Vendemos a empresas con contratos o a consumidores con tarjeta?
5. ¿Cuántas tiendas, países y monedas operaremos dentro de dos años?
6. ¿Es el ERP el dueño del stock y los precios, o lo es la tienda?

Recomendación

Parte del SaaS y demuestra la necesidad de cualquier otra cosa. Pasa a headless solo cuando la propia tienda es donde compites y puedes dotar de personal su operación. Elige totalmente a medida cuando el checklist anterior devuelva al menos dos razones estructurales —precios complejos, configuradores, lógica de contratos B2B, productos regulados o fulfilment poco habitual— y la facturación justifique un equipo de ingeniería permanente. En Arvucore solemos recomendar un motor headless antes que construir desde cero, incluso en el caso a medida: modela tus precios y tu fulfilment como servicios propios y deja que Medusa, Saleor o commercetools se encarguen del carrito, los pedidos y la fontanería que de otro modo reescribirías.