La decisión sobre qué plataforma de e-commerce elegir acaba casi siempre en el mismo sitio: en la mesa del departamento de IT o de un proveedor técnico externo. La pregunta «sobre qué montamos la tienda» suena técnica, así que se delega de forma natural en los técnicos. Es uno de los errores de categorización más caros que vemos en el mid-market.
«Qué plataforma» es una pregunta derivada. Se desprende del tipo de negocio que estás construyendo para los próximos cinco años: B2B o D2C, un mercado o expansión, un catálogo de dos mil o de sesenta mil SKU, un equipo de marketing o uno técnico. IT responde a esa pregunta de forma distinta a como lo haría el negocio, y lo hace de manera sistemática, no por casualidad. A continuación mostramos por qué ocurre, tres casos anonimizados en los que IT decidió en lugar del negocio y un marco sencillo que coloca esta decisión en el orden correcto.
Por qué esta decisión acaba en IT
Elegir una plataforma parece un problema de ingeniería. Hay que comparar stacks, API, rendimiento y modelos de hosting. Una dirección que no se siente segura en esos temas cede de buen grado la decisión a quienes sí lo están. El problema es que así cede también los pesos, y son los pesos, y no la lista de criterios en sí, los que determinan el resultado.
La inversión más cara en e-commerce es una tienda que hay que reescribir al año porque la arquitectura elegida no soportó el crecimiento del negocio. Una plataforma se elige para los 5–7 años de vida del producto, no para el próximo lanzamiento. Y el horizonte en el que mejor se evalúa esta decisión —modelo de ingresos, roadmap, encaje con el equipo— es por definición de negocio, no técnico.
Qué optimiza IT (y por qué no es lo mismo que el negocio)
Un buen departamento de IT no elige mal por mala fe. Elige lo que un departamento de IT valora, y valora cosas reales y sensatas desde su perspectiva:
Control y flexibilidad. Acceso total al código, sin limitaciones de SaaS, la posibilidad de construir cualquier cosa. El open source en su propio servidor gana a un ecosistema cerrado.
Sin vendor lock-in ni cuotas de licencia. Una licencia de 2.200 USD al mes más un porcentaje de la facturación le parece un despilfarro a un ingeniero, si «lo mismo» se puede montar sobre un motor gratuito.
Un stack conocido. Un equipo que lleva años trabajando en WordPress o en Symfony tiende de forma natural hacia lo que ya sabe mantener.
Elegancia técnica. Headless, arquitectura limpia, un front moderno: cosas que lucen bien en una code review.
Cada uno de estos valores está justificado. Ninguno es idéntico a lo que decide los ingresos: el time to market, el coste de propiedad en un horizonte de tres años y quién opera realmente la tienda cada día.
En nuestra comparativa de plataformas evaluamos cada motor en seis dimensiones: panel de administración, configuración, posibilidades de desarrollo, rendimiento, SEO y seguridad. IT otorga instintivamente el mayor peso a las «posibilidades de desarrollo», porque es su mundo. El negocio debería ponderar sobre todo el «panel de administración», porque de él depende que marketing lance una campaña por su cuenta o que abra un ticket a un programador por cada cambio. Ese único peso desplazado basta para que el resultado sea distinto.
Tres casos en los que IT decidió en lugar del negocio
Las historias siguientes son arquetipos compuestos y anonimizados, no clientes concretos, y las cifras de facturación son ilustrativas. Cada una de ellas es, sin embargo, un patrón que se repite con regularidad en el mid-market.
Caso 1: sobreingeniería para un D2C sencillo
Un fabricante de cosmética natural, alrededor de 12 millones de PLN de facturación anual, venta D2C, un catálogo sencillo de hasta dos mil SKU, planes de expansión a los mercados DACH. IT recomienda un desarrollo a medida sobre Symfony/Sylius: «control total, cero lock-in, construiremos exactamente lo que queramos».
La realidad del negocio era otra. Es una marca de marketing, no de tecnología: sin equipo interno de PHP, pero con la ambición de entrar rápido en Alemania y Austria. Sylius puede hacerlo todo, pero la personalización lleva tiempo: una implantación sobre ese motor suele durar 16–22 semanas, mientras que Shopify Plus entrega una tienda productiva en 8–14. El panel de Sylius está diseñado para programadores; el de Shopify, para marketers. El efecto: cada campaña y cada cambio en la web requería un programador, y el multi-currency y el multi-language, que en Shopify Plus vienen listos, hubo que construirlos. La marca perdió las temporadas en las que ya debería haber estado vendiendo en DACH.
IT optimizó el control. El negocio necesitaba time to market y autonomía para marketing.
Caso 2: el techo del SaaS bajo el peso del B2B
Un distribuidor de piezas industriales, alrededor de 40 millones de PLN de facturación, más de sesenta mil SKU, listas de precios individuales por cliente, crédito comercial, catálogo alimentado desde el ERP. Esta vez IT eligió al contrario: Shopify Plus, «porque es SaaS, no tenemos que mantener infraestructura y arrancaremos rápido».
Shopify Plus es excelente para D2C, pero el B2B no es su punto fuerte. Las listas de precios individuales, los límites de crédito y la lógica contractual exigen allí apps y desarrollo a medida, cosas que Sylius tiene de forma nativa. A ello se suma que un catálogo por encima de cincuenta mil SKU roza los límites de comodidad del SaaS. Cada regla B2B se convirtió en otra app de pago, y la factura fue sumando: 2.200 USD al mes de licencia, más un stack de aplicaciones (en el mid-market, típicamente 200–800 USD) y comisiones por transacción. El coste real de mantener una tienda con una facturación del orden de 20 millones de PLN puede alcanzar los 15.000–25.000 PLN al mes, y un modelo que iba a ser «más barato, porque no hay servidores» resultó más caro y frágil en su núcleo.
IT optimizó la simplicidad operativa para sí misma. El negocio era B2B de raíz y necesitaba una plataforma que trate las listas de precios y el crédito comercial como el estándar, y no como una excepción.
Caso 3: el stack conocido en lugar del roadmap
Un fabricante de muebles, alrededor de 15 millones de PLN de facturación anual, un catálogo creciente con configuración de producto (medidas, tejidos, variantes), planes de entrar en marketplaces. IT propone WooCommerce sobre WordPress: «conocemos WordPress, lo tenemos en otros proyectos, para todo hay un plugin».
Al principio funcionaba. El problema apareció con el crecimiento. WooCommerce es la entrada más barata, pero la flexibilidad se paga con el mantenimiento: el rendimiento y la seguridad son sus dimensiones más débiles, y cada nueva necesidad significa otro plugin y otra superficie de fallo. Con el catálogo y el tráfico creciendo, la tienda se ralentizaba y la lista de plugins que vigilar se hinchaba. Al cabo de algo más de un año, el negocio había llegado justo a lo más caro: reescribir la plataforma, porque el motor elegido encajaba con la zona de confort del equipo de IT y no con el roadmap de los próximos años.
IT optimizó el conocimiento de la herramienta. El negocio necesitaba una plataforma ajustada a dónde estará en tres años, no a lo que el equipo ya sabe.
Una plataforma no es una elección tecnológica con consecuencias de negocio. Es una elección de negocio con consecuencias tecnológicas. El orden no es cosmético: determina el resultado.
Cómo debería tomarse esta decisión
El principio es sencillo: primero los criterios y sus pesos, después los nombres de las plataformas. El negocio y IT en la misma mesa, pero con un reparto claro de roles. Antes de que alguien pronuncie la palabra «Shopify» o «Sylius», responde a siete preguntas:
Modelo de negocio. ¿B2B, D2C o híbrido? Esto decide las listas de precios, el crédito comercial y el checkout, y lo más habitual es que por sí solo reduzca la lista a dos plataformas.
Roadmap a 3–5 años. ¿Expansión geográfica? ¿Nuevos canales y marketplaces? ¿Hasta cuántos SKU crecerá el catálogo? La plataforma se elige para el estado objetivo, no para el inicial.
TCO, no el precio de la implantación. Licencia más aplicaciones más mantenimiento más el coste (y la disponibilidad) de desarrolladores en un horizonte de tres años. El motor gratuito a veces es el más caro.
Time to market. Cuánto tiempo tiene realmente el negocio para arrancar y empezar a iterar.
Quién opera la tienda cada día. ¿Marketing o el equipo técnico? Eso decide si el panel debe ser para marketers o puede ser para programadores.
Disponibilidad de competencias. ¿Podremos mantener este stack? Los desarrolladores de Symfony son escasos en Polonia: una plataforma excelente sin gente para operarla es un riesgo, no una ventaja.
Resistencia al cambio. Cuánto nos ata las manos la elección si el negocio gira de rumbo.
El papel de IT en este proceso es imprescindible, pero es el papel de experto, no de decisor. IT evalúa las plataformas de la lista corta en términos de viabilidad, integraciones, rendimiento y seguridad, y levanta banderas rojas. El negocio fija los pesos de los criterios y señala al ganador. Cuando IT recibe el derecho a fijar los pesos, la decisión se desplaza imperceptiblemente hacia lo que IT valora, y vuelve a la empresa en forma de las tres historias anteriores.
Encaje de la plataforma con el perfil del negocio
No existe «la mejor plataforma»: existe la plataforma que mejor encaja con un perfil concreto. Así es el mapeo que usamos con más frecuencia (la comparativa completa y en seis dimensiones de nueve motores está en nuestros rankings de plataformas):
Perfil de negocioLo que solemos recomendarPor quéD2C, catálogo sencillo, expansión en la UE, equipo de marketingShopify PlusEntrada en el mercado en 8–14 semanas, multi-currency y multi-language listos, panel para marketersB2B, listas de precios individuales, crédito comercial, ERP, 10–100k SKUSyliusLógica B2B y desarrollo a medida de forma nativa, control total del código, modo headlessMid-market en PL/UE, presupuesto moderadoPrestaShopPopular en Polonia, bueno para el mid-market, coste menor que el SaaS enterpriseTienda pequeña/mediana, presupuesto inicial mínimoWooCommerceLa entrada más barata, pero hay que contar con el coste de mantenimiento y de los plugins
Dos de nuestros proyectos muestran cómo funciona esto cuando el encaje es correcto: Shopify Plus para la marca D2C Topeshop, donde la migración desde PrestaShop elevó la conversión un 58%, y Sylius para B2B, como el configurador de productos de KMK Klinkier. En ambos casos la plataforma la decidió el perfil del negocio, no la preferencia de stack.
Conclusiones
Elegir una plataforma de e-commerce es una decisión de negocio con consecuencias técnicas, y no al revés. IT es imprescindible en ella como voz de la viabilidad y del riesgo, pero cuando recibe el derecho a fijar los pesos optimiza sistemáticamente el control, el stack conocido y la elegancia en lugar del time to market, el TCO y el encaje con el equipo. Define los criterios antes que los nombres de las plataformas, sienta al negocio y a IT en la misma mesa con un reparto claro de roles y evitarás el escenario más caro: reescribir la tienda a los dieciocho meses.
Si la decisión sobre la plataforma está aún por delante, un buen primer paso es una auditoría y consultoría de plataforma independiente: termina con un documento con una recomendación para la dirección, basada en el perfil de vuestro negocio y no en la preferencia de una de las partes. Con gusto lo recorremos junto a vosotros; escribidnos a través de nuestra página de contacto.