Desarrollo a medida vs plataforma ecommerce: cuándo tiene sentido cada opción

Una de las decisiones más recurrentes que enfrentan las empresas cuando planifican su presencia digital es si optar por una plataforma estándar (PrestaShop, Shopify, WooCommerce, Magento) o por un desarrollo a medida construido desde cero con frameworks como Laravel, Django, Next.js o similares. Ambas opciones tienen ventajas e inconvenientes reales, y la respuesta correcta depende de factores muy específicos de cada proyecto. En este artículo analizamos ambos enfoques con la perspectiva de más de una década desarrollando soluciones digitales.

¿Qué entendemos por cada opción?

Plataforma estándar

Un software de ecommerce ya construido que incluye las funcionalidades base (catálogo, carrito, checkout, gestión de pedidos, backoffice) y se extiende mediante módulos, plugins y personalizaciones sobre su estructura. Ejemplos: PrestaShop, Shopify, WooCommerce, Magento, Shopware.

Desarrollo a medida

Una aplicación web construida específicamente para los requisitos del proyecto, utilizando frameworks de propósito general. Todo se desarrolla desde cero: modelo de datos, lógica de negocio, interfaces de usuario, backoffice de gestión, APIs, etc. Ejemplos: tienda construida con Laravel + Vue.js, con Next.js + API custom, o con Python + Django.

Cómo ha cambiado el panorama en 2026

Esta comparativa se planteó cuando la frontera entre «lo que cubre una plataforma» y «lo que hay que programar» estaba bastante más a la izquierda. En los dos últimos años esa frontera se ha movido de forma apreciable, y conviene tenerlo presente antes de justificar un desarrollo desde cero por falta de funcionalidad.

• PrestaShop 9.1 ha completado la migración a Symfony 6.4 LTS, soporta PHP de la 8.1 a la 8.5 y estrena el tema Hummingbird 2.0, con multi-transportistas y reglas de descuento reescritas. Lo detallamos en el repaso de novedades de PrestaShop 9.1.
• WooCommerce 10.x lleva HPOS (High-Performance Order Storage) activado por defecto, carrito y caja por bloques, y pide como base WordPress 6.9, PHP 8.3 y MySQL 8. El salto de rendimiento respecto a las versiones con tablas de posts es considerable en catálogos grandes.
• Shopify ha retirado checkout.liquid para las tiendas que no son Plus y ha empujado todo el checkout a extensibilidad por apps; el límite de variantes por producto subió de 100 a 2.048 (manteniendo las 3 opciones) y el recargo por usar pasarela externa quedó escalonado en 2 % en Basic, 1 % en Grow, 0,6 % en Advanced y 0,2 % en Plus. Si estás valorando ese salto, tenemos un análisis específico de cuándo compensa migrar a Shopify Plus.
• Adobe Commerce / Magento 2.4.9 sigue siendo la opción más pesada de mantener, y es la plataforma desde la que más proyectos salen hacia alternativas con menor coste operativo, como recogemos en las guías de migración entre plataformas.

A esto se suma una capa que hace dos años no existía en la conversación: la automatización con modelos de lenguaje. Buena parte de lo que antes se pedía «a medida» (clasificación de catálogo, generación de fichas, atención de primer nivel, enriquecimiento de datos) hoy se resuelve conectando servicios externos, como explicamos en los casos reales de agentes de IA en empresa y en la introducción al protocolo MCP para integrar herramientas con IA. Antes de asumir que algo exige desarrollo propio, merece la pena comprobar si ya existe como integración.

Ventajas de las plataformas estándar

1. Time-to-market drásticamente menor

Una tienda en PrestaShop o Shopify puede estar operativa en semanas. Un desarrollo a medida con funcionalidades equivalentes requiere meses. Todo lo que la plataforma ya incluye (gestión de catálogo, checkout, medios de pago, generación de facturas, gestión de stock) no hay que diseñarlo, desarrollarlo ni testearlo desde cero.

2. Ecosistema de extensiones

Miles de módulos y plugins cubren necesidades comunes: SEO, marketing, logística, analytics, B2B, suscripciones, etc. Muchos de estos módulos representan miles de horas de desarrollo que puedes aprovechar por un coste de adquisición muy bajo (desde gratuitos hasta 200-300 €).

3. Comunidad y documentación

Las plataformas populares cuentan con comunidades enormes, documentación extensa, foros de soporte y un pool amplio de desarrolladores especializados. Esto reduce riesgos y costes: si el equipo original no está disponible, es relativamente fácil encontrar quien continue el trabajo.

4. Seguridad probada en producción

Las plataformas maduras han sido auditadas, atacadas y parcheadas durante años. Su código base ha sido revisado por miles de ojos. Un desarrollo a medida parte de cero en cuanto a seguridad: cada endpoint, cada validación, cada flujo de autenticación debe ser diseñado y verificado.

5. Actualizaciones y evolución

La plataforma evoluciona continuamente: nuevas funcionalidades, parches de seguridad, mejoras de rendimiento, adaptación a nuevas regulaciones (PSD2, RGPD, accesibilidad). Con un desarrollo custom, toda esta evolución recae exclusivamente sobre tu equipo y tu presupuesto.

Ventajas del desarrollo a medida

1. Libertad total de diseño y funcionalidad

No hay limitaciones impuestas por la arquitectura de una plataforma. Puedes diseñar exactamente la experiencia de usuario, los flujos de compra, la lógica de negocio y las interfaces que necesitas. Para modelos de negocio realmente únicos o innovadores, esto puede ser determinante.

2. Rendimiento optimizado

Un desarrollo a medida puede optimizarse exactamente para tu caso de uso. Sin el overhead de funcionalidades que no usas, sin plugins que cargan JavaScript innecesario, sin queries a base de datos que no necesitas. Para proyectos donde el rendimiento es crítico (alto tráfico, operaciones en tiempo real), esto es significativo.

3. Independencia de terceros

No dependes de las decisiones de producto de la plataforma, ni de que un desarrollador de módulo siga manteniendo su extensión, ni de cambios de licencia o pricing. El código es completamente tuyo y puedes evolucionar en cualquier dirección sin restricciones.

4. Integración nativa con sistemas propios

Si tu empresa tiene sistemas internos complejos (ERPs propios, plataformas de gestión custom, sistemas legacy), un desarrollo a medida puede integrarse de forma nativa y profunda, en lugar de depender de conectores genéricos que a menudo son limitados.

Los costes ocultos del desarrollo a medida

Aquí es donde muchos proyectos se estrellan. El desarrollo a medida tiene costes que no siempre son evidentes al inicio:

• Funcionalidades «básicas» que no lo son: un carrito de compra con gestión de stock, reservas temporales, descuentos por volumen, códigos promocionales, múltiples direcciones de envío… implementar todo esto correctamente son cientos de horas de desarrollo.
• Cumplimiento normativo: SCA (Strong Customer Authentication), facturación electrónica, accesibilidad WCAG, cookies, RGPD… cada regulación requiere implementación y mantenimiento.
• Testing exhaustivo: una plataforma estándar es testeada por miles de usuarios. Tu desarrollo custom lo testeas tú. Cada edge case, cada combinación de navegador, cada flujo de pago.
• Seguridad continua: auditorías, parches, monitorización, gestión de vulnerabilidades. Sin el respaldo de una comunidad, todo recae en tu equipo.
• Documentación: para que futuros desarrolladores puedan entender y mantener el código.
• Dependencia del equipo original: si el equipo que construyó el sistema se va, la curva de aprendizaje para uno nuevo es alta y costosa.

El coste total de propiedad: dónde se va realmente el dinero

El error de cálculo más habitual es comparar presupuestos de lanzamiento. El presupuesto de lanzamiento es la parte pequeña y, además, es la única que se negocia bien. Lo que decide si un proyecto es sostenible es el coste acumulado a tres años, y ahí el reparto cambia bastante según el enfoque.

Dos matices importantes sobre ese reparto. El primero: en una plataforma estándar, el coste de mantenimiento y seguridad es en buena medida compartido — pagas por aplicar parches que otro ha escrito. En un desarrollo a medida ese coste es íntegramente tuyo, y no desaparece porque no lo presupuestes: se convierte en deuda técnica y acaba apareciendo como incidencia.

El segundo: la partida de cumplimiento normativo es prácticamente la misma en términos absolutos, pero en la plataforma llega en forma de actualización y en el desarrollo propio en forma de proyecto. Es la diferencia entre programar una actualización y abrir una línea de trabajo cada vez que cambia una norma.

Un tercer factor que rara vez se presupuesta es el riesgo de continuidad. Si el equipo que construyó el sistema desaparece, en una plataforma estándar el relevo se encuentra en semanas; en un desarrollo propio sin documentación, el relevo implica meses de ingeniería inversa. Cuando entramos a valorar un activo digital en una due diligence técnica, este es justamente el punto que más ajusta la valoración.

Cumplimiento normativo en 2026: lo que hay que sostener sí o sí

Este es el apartado que más ha crecido desde que se escribió la versión original de este artículo, y el que más desequilibra la balanza hacia las plataformas cuando el equipo es pequeño. Tres frentes concretos:

Accesibilidad (European Accessibility Act)

El European Accessibility Act es exigible desde el 28 de junio de 2025 para el comercio electrónico dirigido a consumidores, con el estándar EN 301 549 —y por tanto las WCAG 2.2 en nivel AA— como referencia técnica. Las plataformas maduras han ido adaptando sus temas y componentes de serie; en un desarrollo a medida, cada formulario, cada modal y cada paso del checkout hay que auditarlo y corregirlo por separado. Lo tratamos en detalle en la guía de accesibilidad web y EAA.

Facturación: VeriFactu

El Reglamento VeriFactu (RD 1007/2023, en desarrollo de la Ley 11/2021 antifraude) obliga a que los sistemas de facturación generen registros encadenados mediante hash, registro de eventos, código QR en factura y exportación estandarizada. El calendario se amplió a finales de 2025: 1 de enero de 2027 para contribuyentes del Impuesto sobre Sociedades y 1 de julio de 2027 para autónomos y profesionales. Si facturas desde tu propia aplicación, ese desarrollo es tuyo; si facturas desde la plataforma o desde el ERP conectado, llega como actualización del proveedor.

Pagos: de PSD2 a PSD3/PSR

La autenticación reforzada (SCA) de PSD2 ya está integrada en cualquier pasarela seria. El siguiente escalón, el paquete PSD3 + PSR, alcanzó acuerdo político provisional en noviembre de 2025 y textos de compromiso final en abril de 2026, con entrada en vigor prevista a partir de 2027 y un plazo de transposición de 21 meses; la verificación de nombre e identificador del beneficiario (VoP) dispone de un plazo mayor. Traducido a decisiones de arquitectura: quien dependa de una pasarela integrada no tendrá que hacer nada; quien haya construido su propio flujo de pago tendrá que volver a abrirlo.

A esto se añade la capa de seguridad de la información cuando se vende a empresas o a administración pública: los pliegos piden cada vez con más frecuencia certificaciones, y ahí conviene conocer el terreno tanto de la certificación ISO 27001 como del Esquema Nacional de Seguridad. Una plataforma estándar no te certifica, pero reduce drásticamente la superficie de controles técnicos que tienes que evidenciar tú.

El enfoque híbrido: lo mejor de ambos mundos

En la práctica, muchos de los mejores proyectos combinan ambos enfoques:

• Plataforma + personalizaciones profundas: usar PrestaShop o WooCommerce como base y desarrollar módulos custom para la lógica de negocio específica. Aprovechas el 80 % de funcionalidad estándar y desarrollas a medida solo el 20 % diferencial.
• Headless commerce: usar el backend de una plataforma (WooCommerce, Shopify, Magento) expuesto vía API, con un frontend completamente custom. Combinas la robustez del backend comercial con la libertad total en la experiencia de usuario.
• Composable commerce: combinar servicios especializados (Stripe para pagos, Algolia para búsqueda, un CMS headless para contenido, un OMS para gestión de pedidos) orquestados por una capa custom. Cada servicio es best-of-breed en su dominio.

Árbol de decisión práctico

Para ayudar a tomar la decisión, proponemos estas preguntas clave:

1. ¿Tu modelo de negocio es estándar (vender productos online)? → Plataforma estándar. El 90 % de las tiendas online tienen necesidades que las plataformas existentes cubren perfectamente.
2. ¿Tienes requisitos funcionales que ninguna plataforma cubre ni con extensiones? → Evalúa el enfoque híbrido (plataforma + módulos custom) antes de ir a full custom.
3. ¿Tu negocio tiene un modelo realmente único que requiere flujos completamente diferentes? → El desarrollo a medida o composable puede estar justificado. Ejemplos: configuradores de producto 3D interactivos, modelos de pricing dinámico en tiempo real, plataformas de subastas.
4. ¿Tienes presupuesto y equipo para mantener un desarrollo custom a largo plazo? → Si la respuesta es no, una plataforma estándar es más segura aunque requiera compromisos en personalización.

Cinco errores frecuentes al tomar esta decisión

1. Confundir «no me gusta cómo lo hace la plataforma» con «la plataforma no lo hace». Muchos desarrollos a medida nacen de una limitación de tema o de un módulo mal elegido, no de una limitación real del núcleo. Antes de descartar una plataforma conviene revisar si el problema está en la capa de extensiones; nuestra guía sobre cómo seleccionar el módulo adecuado evita bastantes de estos callejones.
2. Presupuestar el lanzamiento y no la operación. Un proyecto a medida sin partida anual de mantenimiento no es más barato: es el mismo coste diferido y con intereses.
3. Elegir por el stack que domina el proveedor. Si el equipo que tienes delante solo trabaja con un framework, la recomendación vendrá sesgada. Pregunta siempre por proyectos donde recomendaron no desarrollar a medida.
4. Subestimar el backoffice. El escaparate se replica rápido; lo que cuesta meses es reconstruir la gestión de pedidos, devoluciones, stock, abonos, informes y permisos que la plataforma trae de serie. Es la partida que más se desvía.
5. Ignorar la seguridad hasta que hay incidente. En un desarrollo propio no hay comunidad publicando parches: la vigilancia es tuya. Merece la pena leer qué implica eso en la práctica en nuestro artículo sobre seguridad en el ecommerce.

Cómo abordamos esta decisión en una auditoría

Cuando nos llega esta pregunta, no respondemos con una preferencia de stack. Seguimos un recorrido bastante mecánico que, en la mayoría de los casos, resuelve la duda en una o dos semanas:

1. Inventario de requisitos reales, separando los que están en producción de los aspiracionales. Es habitual que un tercio de la lista inicial no llegue nunca a usarse.
2. Prueba de encaje de cada requisito contra dos o tres plataformas candidatas: nativo, vía extensión, vía desarrollo sobre la plataforma, o imposible. Solo la última categoría justifica salir del estándar.
3. Revisión del código existente si ya hay un sistema en marcha. Una auditoría de código suele revelar que el problema no era la plataforma sino cómo se extendió.
4. Análisis de superficie de riesgo, incluyendo dependencias sin mantenimiento y exposición a vulnerabilidades conocidas; cuando el proyecto maneja datos sensibles, lo complementamos con auditoría de seguridad y pentesting.
5. Modelo de coste a tres años con los cuatro bloques del gráfico anterior, y comparación de escenarios.

Si el frontend es el punto crítico del proyecto, el enfoque headless merece una evaluación aparte: la elección de framework condiciona el coste de los siguientes tres años tanto como la elección de plataforma, y lo analizamos en la comparativa de frameworks frontend.

Nuestra experiencia en Keliam

Después de más de una década desarrollando proyectos de ecommerce y software custom, nuestra experiencia muestra un patrón claro: la mayoría de empresas obtienen mejor resultado con una plataforma estándar bien configurada y con personalizaciones targeted, que con un desarrollo completamente a medida.

Los casos donde el desarrollo a medida se justifica son aquellos donde el negocio tiene una ventaja competitiva tecnológica clara que no puede reproducirse con plataformas estándar, y cuenta con los recursos para mantenerla a largo plazo.

Conclusión

La decisión entre plataforma y desarrollo a medida no es binaria. Evalúa tus necesidades reales (no las aspiracionales), tu presupuesto total (no solo el de lanzamiento), y tu capacidad de mantenimiento a largo plazo. Y recuerda: la mejor tecnología es la que resuelve tu problema de negocio de forma sostenible, no la más compleja.

¿Necesitas ayuda para decidir? En Keliam realizamos auditorías de necesidades y proponemos la arquitectura más adecuada para cada caso. Contáctanos y lo analizamos juntos.