WooCommerce o Laravel para una tienda online: cuál elegir y cuándo

La plataforma no la decide la lista de funciones del primer día: el almacén, los precios B2B y el multiidioma los construimos en las dos. Lo decisivo es quién decide su próximo cambio y cuánto cuesta ese cambio.

Una pregunta sobre tecnología cuya respuesta no es una lista de funciones

La conversación empieza casi siempre igual: el cliente tiene unos setecientos productos, tres niveles de precio para sus distribuidores —cada uno ve en su perfil únicamente el suyo— y la contabilidad en Visma Horizon, donde el stock es la verdad y la tienda se limita a reflejarlo. La pregunta que plantea suena así: ¿WooCommerce o Laravel para una tienda online? La respuesta que espera es una lista a dos columnas, con algo en un lado y su ausencia en el otro; una lista que nosotros no tenemos y que no tiene nadie que construya de verdad sobre las dos plataformas.

El módulo de almacén con sincronización de stock en tiempo real, los niveles de precios B2B, el sistema de descuentos, el soporte multiidioma y la migración de contenido los construimos en las dos, y el precio en nuestra tarifa no depende de la plataforma: la versión Basic de la tienda online cuesta 4.500 € y la versión Pro, 9.500 €, tanto sobre WooCommerce como sobre Laravel. Son exactamente esas cinco líneas las que separan la Basic de la Pro, y no lo que hay por debajo; el panel de administración figura en la tarifa ya en la versión Basic, mientras que el funcionamiento multidivisa no está en ninguna de las dos y se acuerda aparte, otra vez sobre cualquiera de las dos plataformas.

De ahí se sigue algo práctico: la plataforma que le venden con una lista de funciones del primer día se vende por algo que usted puede conseguir de las dos maneras, y la comparación que arranca con esa lista ha terminado antes de empezar. La pregunta interesante empieza un paso más allá, y es quién decide lo que su tienda podrá hacer el año que viene y cuánto tiempo espera esa decisión en la cola de otra empresa.

El primer año las dos plataformas hacen aquello por lo que usted ha pagado, porque en ambos casos alguien acaba de construirlo; el segundo año el proceso cambia —aparece la venta al por mayor, un segundo almacén, la obligación de emitir facturas legibles por máquina o, sencillamente, otro orden de descuentos—, y desde ese momento los dos caminos cuestan cosas distintas. Sobre la extensión de otro fabricante, cada cambio posterior es como reformar un local alquilado: las reglas de su proceso viven en la ventana de ajustes de otro y se mueven al ritmo de lanzamientos de otro. Sobre código propio, ese mismo cambio es trabajo con una tarifa por hora, y lo único que hay que acordar es su prioridad frente al resto de la lista.

Qué hace bien WooCommerce

WooCommerce lo instalamos nosotros mismos en tiendas de clientes siempre que el proceso encaja, y es el sistema de comercio electrónico más utilizado en los estudios de W3Techs: el 6 de agosto de 2026 funcionaba en el 8,2 % de todos los sitios web y suponía el 48,5 % de todos los sistemas de comercio electrónico de esos estudios. Más importante que la cifra es de dónde sale —de una parte de los sistemas estudiados, no de las tiendas del mundo y desde luego no de la facturación del comercio electrónico—, y detrás de ella está WordPress con el 41,2 % de todos los sitios web.

El directorio de plugins de WordPress.org mostraba ese mismo día la versión 11.0.0 de WooCommerce, actualizada el 4 de agosto, con una estimación de «7+ million active installations» —más de siete millones de instalaciones activas—, y leerla con prudencia lo recomienda el propio fabricante: el registro de uso viene desactivado por defecto en el núcleo que se descarga de WordPress.org, de modo que nadie, tampoco Automattic, sabe cuántas tiendas venden de verdad, y esa cifra es el techo de las instalaciones, no el número de comerciantes.

La página de precios del fabricante describe WooCommerce como una plataforma de código abierto sin cuota de plataforma y con un 0 % de participación en los ingresos: usted no paga por vender y no paga porque su facturación crezca. El catálogo, la lista de pedidos y los ajustes de descuentos, además, tienen el mismo aspecto que el resto de la administración de WordPress, que su equipo probablemente ya sabe manejar sin formación previa.

El argumento más fuerte a favor de WooCommerce desaparece casi siempre de las comparativas de sus competidores, y es el parche automático: el 2 de marzo de 2026 se hizo pública una vulnerabilidad de la Store API que afectaba a las versiones de la 5.4 a la 10.5.2 y permitía crear una cuenta de administrador con una petición falsificada; el fallo lo encontró otro, no los dueños de las tiendas; la corrección se retroportó a las 52 versiones afectadas; y ese mismo día, a partir de las 14:00 UTC, empezó a repartirse sola por las tiendas que tienen activadas las actualizaciones automáticas, sin factura de por medio. Ese ajuste no es evidente por sí solo, y es justamente lo que una persona configura y vigila dentro de un contrato de mantenimiento; cómo se hackean los sitios WordPress y qué hacer cuando ya ha ocurrido lo explicamos en nuestro artículo sobre un WordPress hackeado.

La recomendación, por tanto, no ha cambiado, y está escrita también en nuestra página de servicio: para una tienda online muy pequeña con procesos estándar, WooCommerce. A cien productos con un solo precio, un solo almacén y una sola forma de pago, una plataforma a medida no le va a dar nada por lo que merezca la pena pagar la diferencia, y vender la opción cara cuando la barata hace lo mismo significa un cliente descontento más y ninguna recomendación.

¿Sirve WooCommerce para los pagos y los envíos en Letonia?

Sirve. Los envíos y los pagos en Letonia no son el punto donde una tienda online ya hecha se detiene, y las advertencias en sentido contrario suelen carecer de fundamento: Omniva publica módulos listos para seis plataformas —WooCommerce, Shopify, PrestaShop, OpenCart, Magento y Mozello— y, al lado, una interfaz OMX documentada por la que pasan los datos de los envíos, las etiquetas, los eventos de seguimiento y las listas de puntos de recogida de los tres países bálticos, pero el requisito previo para eso es un contrato mercantil, no un programador. DPD Baltics mantiene por su cuenta su plugin de WooCommerce en el directorio de WordPress.org —versión 1.2.91, más de 2.000 instalaciones activas— y cubre puntos de recogida, mensajería, etiquetas, manifiestos y contra reembolso; ahí mismo se ve también su valoración pública de 2,7 sobre 5 y las reseñas de usuarios que se quejan de conflictos con otros plugins de envío.

MakeCommerce, detrás del cual está Maksekeskus AS, entrega con un solo contrato los enlaces bancarios de Swedbank, SEB, Citadele y Luminor, las tarjetas, Apple Pay y Google Pay, y al lado los envíos de Omniva, DPD, Venipak y Unisend; su plugin de WooCommerce tiene más de 3.000 instalaciones activas y su última actualización es de junio de 2026. Klix by Citadele, que mantiene el propio banco, publica plugins oficiales para seis plataformas, WooCommerce entre ellas desde la versión 3.5, de manera que afirmar que en Letonia una tienda ya hecha no puede cobrar sería sencillamente falso.

La otra cara de lo mismo es que estos proveedores no son propiedad de ningún plugin: MakeCommerce, Omniva y DPD publican interfaces, no solo módulos, y en nuestra tarifa la conexión de los pagos —MakeCommerce y Stripe— entra ya en la versión Basic por 4.500 €, sea cual sea la plataforma que haya debajo. Las integraciones con Horizon, Jumis, Latvijas Pasts, Omniva y DPD son una línea del servicio de tienda y no un recargo por Laravel, y con las API de envío de Omniva, Latvijas Pasts, DPD y Venipak trabajamos con regularidad, así que la capa letona de envíos y pagos no es un argumento ni a favor ni en contra de ninguno de los tres caminos.

Dónde está en Letonia el trabajo de verdad

Lo que complica la trastienda es que Visma Horizon, Jumis y Directo publican cada uno su propia interfaz REST —la documentación de Directo describe la autorización con la cabecera X-Directo-Key y el acceso a artículos, pedidos, clientes, facturas, stock y fórmulas de precio—, pero una interfaz publicada todavía no es una integración: alguien tiene que casar lo que la tienda llama artículo con lo que la contabilidad llama unidad de nomenclatura, y decidir cuál de los dos sistemas guarda la verdad sobre el stock en el segundo en que el comprador pulsa el botón. Dos sitios donde vive el stock son como dos relojes a bordo de un barco: mientras no se sincronizan, nadie sabe la hora, y ese trabajo es a medida sobre cualquier plataforma; con Horizon y con Jumis lo hacemos con regularidad.

Por encima hay un dato legal con fecha y con trampa dentro: la factura electrónica estructurada es obligatoria para las entidades públicas desde el 1 de enero de 2025, y en las operaciones entre empresas lo será el 1 de enero de 2028, según la Ley de Contabilidad letona y en el formato LVS EN 16931-1:2017. La trampa es la fecha: al principio estaba prevista para 2026, así que los artículos de prensa de 2024 siguen dando el plazo equivocado, y conviene comprobarlo en la página del Ministerio de Finanzas sobre la factura electrónica estructurada y no en las noticias, porque para una tienda que vende a empresas el camino de la factura legible por máquina habrá que construirlo sobre cualquier plataforma, sea cual sea el año que acabe resultando el correcto.

WooCommerce o Laravel para una tienda online: ¿cuál de los tres caminos es el suyo?

Las comparaciones que presentan esta elección como dos botones dejan fuera el camino que más vendemos, porque en realidad los caminos son tres; se distinguen por cuánta parte de su proceso vive en código que usted puede cambiar, y elegir entre ellos es decidir dónde van a estar a partir de ahora las reglas de sus precios y de sus pedidos: en una ventana de ajustes, en su propio repositorio o a medio camino entre ambas cosas.

El primer camino es una herramienta ya hecha con extensiones ya hechas —WooCommerce u OpenCart, que también ofrecemos nosotros a las tiendas existentes—. El núcleo de WooCommerce tiene dos campos de precio, el normal y el rebajado, una única cifra de stock por producto o variación y tres métodos de pago, ninguno de los cuales cobra en línea, de modo que el precio para un grupo concreto de clientes, los descuentos por cantidad, la conversión de un presupuesto en pedido, la exención de IVA y el stock repartido en varios almacenes son una compra aparte, a un fabricante aparte, con una suscripción anual aparte. Es el camino más rápido y muy a menudo el acertado, y su precio no es dinero: es que las reglas de su proceso pasan a vivir en la ventana de ajustes de otro fabricante.

El segundo camino casi no aparece en las comparativas, aunque es el que más vendemos: una herramienta ya hecha con código nuestro encima. WooCommerce es código PHP de fuente abierta, así que la tabla de precios para distribuidores, el control de crédito o la reserva de stock se pueden escribir al lado del núcleo en vez de comprarse como plugin, y para eso no hay licencias, hay horas; el precio es que ese código queda atado al ritmo de actualizaciones de WooCommerce y a la forma en que esta plataforma guarda los pedidos. Buena parte de lo que en nuestra tarifa se llama versión Pro y cuesta 9.500 € es exactamente ese trabajo, y aquí está la mayoría de nuestras propias tiendas.

El tercer camino es nuestra propia plataforma, con el catálogo, el carrito, el paso de pago y la lógica de precios escritos desde cero alrededor de su proceso; es el arranque más caro y el único en el que no hay ninguna suposición ajena sobre qué es un artículo y sobre cuándo un pedido pasa a ser un pedido. Dentro del tercer camino hay una bifurcación: Bagisto y Lunar son paquetes de comercio para Laravel con licencia MIT —el 6 de agosto de 2026 tenían en GitHub 27.943 y 3.588 estrellas respectivamente— que dan el catálogo y el carrito ya escritos a cambio de una dependencia externa más cuyo ritmo no está en sus manos. Por ahí no vamos.

¿Cuánto cuestan al año las licencias de los plugins de WooCommerce?

Para una tienda con setecientos productos y tres niveles de distribuidor, el 6 de agosto de 2026 el primer camino costaba 270 € al año por dos precios públicos, más un tercero desconocido. Dynamic Pricing, por 113 € al año, da descuentos por cantidad y por rol; B2B for WooCommerce, desarrollado por Addify, por 157 € al año, da precios por rol, precios escalonados, la conversión de un presupuesto en pedido, la exención de IVA y métodos de pago y de envío restringidos por rol; pero para el stock repartido en varios almacenes el núcleo no prevé nada, así que se suma un tercer plugin de pago, por ejemplo Addify Multi Inventory Management, cuyo precio anual el fabricante no publica.

Esos 270 € al año son algo más de cinco horas de desarrollo, porque en nuestra tarifa la hora de desarrollo cuesta 50 €, y para funciones que tienen fabricante, documentación y actualizaciones eso es barato. El precio que no conoce antes de la conversación, en cambio, no es una línea del presupuesto: el plugin de almacenes sube esa cifra, y cuánto depende de la oferta que le llegará después de decir cuántos almacenes tiene y qué volumen de pedidos mueve.

Otra tienda tiene otras líneas: la que vende suscripciones, reservas y niveles de membresía paga, a los mismos precios de ese mercado, 245 € al año por WooCommerce Subscriptions, 218 € por Bookings, 175 € por Memberships, 140 € por AutomateWoo y 70 € por Product Add-Ons; en total, 848 € al año. En cinco años, si los precios no suben, son 4.240 €: casi el precio entero de una tienda en versión Basic, que en nuestra tarifa cuesta 4.500 €, y casi la mitad de la versión Pro de 9.500 €. Esta línea no se amortiza, porque es por un sitio, por un año, y se paga cada año de nuevo.

La misma cifra del revés son casi 85 horas de desarrollo a 50 €, y son horas que se quedan en su código y en su propiedad, en lugar de renovarse en la factura del año siguiente. La factura concreta de 848 € es además la de una tienda de suscripciones, reservas y membresías, no una norma —aquí no hay norma—, y cada tienda tiene que sumar esta línea a partir de su propio proceso. La línea de licencias, además, se añade a la construcción y no la sustituye: en los dos casos alguien ha construido antes la tienda, y solo en uno de ellos vuelve a llegar en enero una factura por lo ya construido.

Qué hace la factura cuando no se paga

Si la suscripción no se renueva, la documentación de WooCommerce.com lo dice sin rodeos: «the extension or theme remains installed on your site but will no longer receive updates» —la extensión o el tema siguen instalados en su sitio, la tienda sigue funcionando, y lo único que desaparece son las actualizaciones—. La consecuencia de una licencia no renovada no es, por tanto, una caída que se nota el mismo día, sino un trozo de código sin corregir que sigue procesando pagos; una suscripción, además, cubre un sitio de producción y un sitio de desarrollo, y los subdominios cuentan aparte.

Una línea se comporta de otra manera, y se comporta igual en los dos lados: el conector de contabilidad no suele ser una licencia, sino una suscripción que sube con el número de pedidos —MyWorks Xero Sync arranca en el mercado de WooCommerce con un nivel gratuito, y a partir de ahí el precio lo fija el volumen—, así que esa línea crece justo cuando crece la tienda. Una plataforma a medida no la elimina, pero cambia quién mantiene el conector, y en nuestro caso son horas; tampoco hace falta inflar la lista: el soporte multiidioma no son automáticamente 99 € al año por WPML Multilingual CMS, porque al lado de WPML está también Polylang, pero la licencia barata de WPML, Multilingual Blog, por 39 €, no admite comercio electrónico, de modo que para una tienda la elección entre 39 € y 99 € no existe.

Por qué la diferencia aparece el segundo año

Que el precio del cambio es un gasto real y no teórico lo demuestra la propia plataforma: desde 2023, WooCommerce ha retirado dos piezas de carga, ha cancelado una función en beta y ha cambiado un valor por defecto. La REST API heredada desapareció del núcleo el 11 de junio de 2024 con la versión 9.0, después de estar declarada obsoleta desde la 2.6 en 2016; la pasarela PayPal Standard incorporada se retiró en la versión 8.9, en mayo de 2024; la beta del editor de productos se retiró en la versión 11.0, la que apareció en el directorio el 4 de agosto; y el almacenamiento de pedidos HPOS pasó a ser el valor por defecto para las instalaciones nuevas en la versión 8.2, en octubre de 2023, sin tocar las tiendas existentes mientras nadie las migre.

Sobre ese fondo, la sección Advisories del blog para desarrolladores de WooCommerce acumula 37 entradas en los doce meses hasta el 5 de agosto de 2026 —unas tres al mes—, y cada una hay que contrastarla con cada extensión instalada en la tienda, algo que una tienda con cuatro plugins absorbe sin esfuerzo y una con veinte ya no. El montón, además, no se acumula en un día: los plugins llegan de uno en uno, cada uno por separado es una decisión perfectamente sensata, y la multiplicación de las combinaciones que hay que comprobar ocurre en silencio.

Diez plugins no son diez piezas, sino diez contratos que pueden terminar cada uno por su lado, y el propietario cambia también cuando el código no tiene nada malo. El 31 de octubre de 2025, el servicio de reseñas Judge.me apagó su integración con WooCommerce junto con las de Square, Squarespace, BigCommerce, Duda y PrestaShop: a los datos se pudo acceder hasta el 19 de noviembre, después el acceso se retiró de forma irreversible, y los vídeos de las reseñas no entraban en la exportación, de modo que un activo de marketing acumulado durante años se quedó en parte al otro lado de la puerta. Los casos tranquilos son más convincentes: en 2019 Automattic compró Prospress, autora de WooCommerce Subscriptions y de AutomateWoo, y en 2020 GoDaddy compró SkyVerge, cuyas más de sesenta extensiones usaban más de 100.000 comerciantes, y las dos operaciones, por lo que se sabe públicamente, acabaron bien para los comerciantes. La cuestión no es el daño, sino que el dueño de una pieza de su tienda puede cambiar sin que usted participe.

Cuál es el tamaño real de ese riesgo

La escala lo relativiza, y las cifras aquí son nuestras: en el recuento del 6 de agosto de 2026, la API de plugins de WordPress.org devolvió 7.764 plugins con la etiqueta «woocommerce», de los cuales el 23,1 % no se actualizan desde hace dos años o más, pero en ese mismo recuento hay 10.809.800 instalaciones activas sobre plugins actualizados en los últimos seis meses y solo 208.790 sobre plugins sin tocar desde hace más de tres años. Plugins con 10.000 instalaciones o más que lleven dos años sin actualizarse hay, en ese mismo recuento, exactamente seis.

El plugin abandonado casi nunca es el popular que conoce todo el mundo: el riesgo está en ese módulo estrecho que pide precisamente su proceso —los niveles de precios B2B, el conector del almacén, el generador de etiquetas de un transportista concreto—, y cuanto más se aparta su proceso de la media, más cerca está usted de la parte del directorio donde la última actualización es del año pasado. Esa línea se puede reducir sin reconstruir nada: dentro de un contrato de mantenimiento lo hacemos nosotros —reducimos el número de plugins, configuramos las actualizaciones y mantenemos la monitorización—, y reconstruir solo es la respuesta cuando el problema ya no es el mantenimiento, sino que el proceso no está escrito en ninguna parte.

Dónde empieza a apretar la forma de los datos de WooCommerce

El segundo sitio donde el segundo año cuesta dinero es la forma de los datos, y conviene empezar por el lado en el que ese argumento ya no es cierto: en las instalaciones nuevas, desde la versión 8.2, los pedidos viven en cuatro tablas propias, y la medición de marzo de 2023 de la propia empresa muestra que el almacenamiento nuevo acelera las operaciones con pedidos en lugar de frenarlas. Lo que aprieta es el lado de los productos, y quienes mejor lo han escrito son los propios desarrolladores de WooCommerce, el 1 de abril de 2019, al explicar las mejoras de rendimiento de la versión 3.6: los artículos y las variaciones pasan por el sistema de entradas de WordPress, en el que el post meta es extraordinariamente flexible pero «not that efficient when we need to sort or filter by many meta values at once» —no demasiado eficiente cuando hay que ordenar o filtrar por muchos valores meta a la vez—. La respuesta, en ese mismo lanzamiento, fue wc_product_meta_lookup, una tabla auxiliar desnormalizada con el SKU, el precio y el estado del stock al lado del post meta y no en su lugar, así que la forma de fondo se quedó como estaba.

El trabajo equivalente en el lado de los productos, woocommerce-product-tables-feature-plugin, vive solo en GitHub desde el 16 de octubre de 2017 y no está abandonado —el último cambio es del 31 de julio de 2026—, solo que sigue sin considerarse lo bastante estable para el directorio de WordPress.org. Al lado está wp_options, cuyo campo autoload no tiene índice por defecto, cuyos datos autocargados se leen en cada carga de página, que el propio WooCommerce recomienda mantener por debajo de unas 500 filas y cuyo crecimiento lo provocan precisamente las extensiones, los plugins y los temas: el mismo montón del que hablábamos antes, visto desde el lado de la base de datos.

Qué le da Laravel a una tienda que una herramienta ya hecha no da

Laravel no es una tienda y no finge serlo: da piezas con nombre, documentadas y con licencia MIT, con las que alguien monta la tienda, así que la pregunta que aquí vale dinero no es «si el framework es bueno», sino «qué partes de su proceso pasan por fin a ser tablas suyas y trabajos suyos». En la tienda de un comerciante la respuesta suelen ser cuatro líneas —la tabla de precios de distribuidor, el límite de crédito, la reserva de stock y la sincronización con la contabilidad—, y son exactamente las que en una herramienta ya hecha usted compra a cuatro fabricantes distintos y después tiene que poner de acuerdo entre sí.

Antes conviene decir con honestidad lo que este camino no da, porque ninguna de esas cuatro líneas la da tampoco Laravel: los starter kits oficiales del framework dan autenticación y nada más —no hay catálogo, ni carrito, ni paso de pago, ni almacén—, y el único paquete de comercio que viene incluido es Cashier, que atiende la facturación de suscripciones del lado de Stripe o de Paddle y da por supuesto que los productos con sus precios ya están descritos en el panel del proveedor de pagos. Lo que Laravel da es una forma en la que esas cuatro líneas salen baratas de escribir y todavía más baratas de cambiar después.

Colas, transacciones y una base de datos con su propia forma

La primera pieza son las colas: una sola API sobre varios motores —Redis, base de datos, Amazon SQS, Beanstalkd— que permite sacar de la petición el procesamiento del pedido, la sincronización con el ERP y el correo, de modo que el comprador deja de esperar a que responda el sistema de contabilidad. La documentación nombra además lo que decide una implantación real: cadenas y lotes de trabajos, trabajos únicos que la cola no ejecuta dos veces, reintentos y un almacenamiento de trabajos fallidos desde el que volver a lanzarlos. Un pedido ejecutado dos veces es una factura que alguien tendrá que anular después y un cliente que lo nota antes que usted.

Horizon muestra el rendimiento de las colas, los tiempos de ejecución y los errores, permite describir en código la configuración de los workers y avisa cuando una cola espera demasiado, pero exige Redis y por ahora no funciona con Redis Cluster, así que es una partida propia en la factura de alojamiento y no un añadido gratuito. Las transacciones, por su parte, son lo que significa en la práctica la frase «el pedido y el movimiento de stock ocurren los dos o no ocurre ninguno»: DB::transaction deshace los cambios por su cuenta si algo falla y permite reintentarlos cuando la base de datos entra en un interbloqueo.

La documentación de Laravel llama a las migraciones control de versiones para la base de datos, y en la práctica eso significa que las tablas, los índices y las claves foráneas se proyectan alrededor de su lógica de precios y de stock, y no alrededor de lo que otro decidió una vez sobre el concepto de artículo. La búsqueda y la facturación de suscripciones, además, siguen siendo una opción y no una línea mensual obligatoria: Scout indexa en la propia base de datos con los índices de texto completo de MySQL o de PostgreSQL, sin servicio externo, y del lado de Stripe se ocupa Cashier, si es que la tienda tiene suscripciones.

La tabla de precios, el límite de crédito y la reserva, en código

Cómo se ve esto en concreto lo muestra mejor que nada la primera de las cuatro líneas: la tabla de precios de distribuidor sobre código propio es una migración con cuatro columnas —grupo de clientes, artículo, umbral de cantidad y precio— y un índice único sobre las tres primeras, de manera que el precio para un comprador concreto se encuentra con una sola consulta y un JOIN, y no rebuscando entre valores meta, y un nivel de precios nuevo es una fila nueva en una tabla y no un ajuste nuevo en la ventana de otro fabricante. Cuando al cabo de un año aparece un cuarto nivel con otro criterio de redondeo, cambian un sitio y una prueba, y los dos están en su repositorio.

El límite de crédito y la reserva de stock son la misma idea un paso más allá, porque también ahí todo se sostiene sobre una tabla y una transacción: la suma de las facturas pendientes es una columna del cliente, y la comprobación ocurre dentro de la misma transacción en la que nace el pedido, así que dos pedidos enviados a la vez no pueden colarse los dos por debajo del límite, y si hay interbloqueo la transacción se reintenta sola. La reserva, a su vez, es una fila con fecha de caducidad que nace junto con el pedido y desaparece con un trabajo programado en segundo plano si el pedido no se paga, de modo que el stock deja de ser una cifra que dos compradores pueden vaciar al mismo tiempo.

La sincronización con la contabilidad es un trabajo de cola marcado como único, así que un reintento no emite nunca la factura dos veces, y cuando Horizon enseña por la mañana que de madrugada hubo un corte en el lado de la contabilidad, el almacenamiento de trabajos fallidos permite volver a lanzarlos en orden en lugar de reescribirlos a mano. Cada una de estas cuatro líneas está disponible también en una herramienta ya hecha, solo que como una ventana de ajustes de un fabricante cuyas reglas usted no ve, que hay que volver a comprobar después de cada actualización y que no se muda con usted a otra plataforma.

Dos trabajos que ya funcionan

Cómo se ve esto en un proyecto y no en la documentación se aprecia en nuestros propios trabajos con Laravel. En la plataforma de pedidos de comida de LIDO el precio no lo decide el producto, sino la dirección: la geolocalización determina la zona de entrega, la distancia y el importe, cada uno de los trece restaurantes tiene su propia carta, y junto a la tienda funciona un sistema aparte de automatización de procesos al que llegan todos los pedidos y desde el que se reparten por restaurantes y por cocineros, con integraciones en más de diez sistemas más, entre ellos Wolt, QWQER y RKeeper. La tienda de Riga Lashes sobre Laravel tiene precios por variante, cuentas de cliente, lista de deseos y el listado de precios de los servicios del estudio, y detrás de todo eso están el almacén de mercancía, las integraciones con las empresas de mensajería y los pagos, con el proceso automatizado hasta la fase de empaquetado. En ambos casos la parte decisiva habría habido que escribirla también sobre una herramienta ya hecha, solo que dentro de la forma de precios y de pedidos de otro fabricante, y esa es justamente la diferencia que permanece: sobre código propio este trabajo es un único repositorio sin una suscripción aparte por cada capacidad, y no hay que volver a comprobarlo después de cada actualización de la plataforma. Laravel lo escribimos desde 2013, y sobre él funcionan la mayoría de nuestros sistemas a medida, de nuestros portales del sector público y de nuestras plataformas B2B.

A dónde va el dinero que no está en licencias es una pregunta concreta, y la respuesta es igual de concreta: las casi 85 horas que cuesta en cinco años la línea de licencias de 848 € al año son, sobre código propio, exactamente esa tabla de precios, ese límite de crédito, esa reserva y esa sincronización, escritas alrededor de su proceso. Se quedan en su repositorio incluso si algún día dejamos de ser su proveedor: en un desarrollo por encargo el código es suyo desde el primer día, y eso está escrito también en la página de nuestro servicio de Laravel.

Filament: el panel de administración que nadie escribe desde cero

La parte del panel de administración de la objeción de que en un sistema propio hay que escribirlo todo desde cero la quita Filament, un framework de interfaz de código abierto para aplicaciones Laravel. Los recursos generan pantallas CRUD para los modelos de Eloquent, el constructor de tablas da filtrado, ordenación y paginación, los componentes de formulario vienen con validación integrada, y los permisos de acceso Filament los lee directamente de las políticas de modelo de Laravel, así que las comprobaciones de rol no hay que escribirlas dos veces. Los gestores de relaciones, los widgets del panel y las notificaciones vienen en el mismo paquete; el soporte multiinquilino también, eso sí, con la advertencia del propio Filament de que se trata de un conjunto de herramientas y no de una garantía, y de que de la separación de los datos entre inquilinos responde quien implanta; toda esa capa tiene licencia MIT, igual que el propio Laravel, así que ahí no hay ninguna cuota de licencia.

Lo importante, sin embargo, no es lo que dibuja el framework, sino a dónde va el dinero que libera: las pantallas de edición de artículos, las tablas de pedidos, los filtros y las comprobaciones de permisos son la parte del desarrollo que el comprador no ve nunca y por la que el cliente paga igualmente la tarifa completa, y cuando esa parte la da el framework, el presupuesto se va a la lógica de precios, de pedidos y de almacén por la que se eligió el desarrollo a medida. El ejemplo está donde usted está leyendo esto: este sitio web funciona sobre Laravel 13 y Filament 5, y todo el trabajo editorial en doce idiomas ocurre en un panel que configuramos, no que escribimos desde cero.

Dónde acaba el framework y empieza la tienda

Filament no es una tienda, y merece la pena trazar esa frontera con claridad: el framework da el panel de administración —pantallas, tablas, formularios y comprobaciones de permisos—, pero no sabe nada de lo que hay en esas tablas ni de las reglas por las que ha llegado allí. El catálogo de artículos con variaciones y atributos, el carrito, el paso de pago, las reglas de precio con niveles de cliente y descuentos por cantidad, el ciclo de vida del pedido desde su creación hasta la devolución y la reserva de stock en el almacén: nada de eso viene en el paquete de Laravel y Filament. Filament es como un taller montado, con estanterías, bancos de trabajo y luz; qué se fabrica dentro no viene incluido.

Hasta qué punto hay que tomarlo al pie de la letra lo enseña la propia documentación, en la que los modelos Order y Payment aparecen únicamente como ejemplos que el desarrollador escribe él mismo, porque en el framework esas clases sencillamente no existen. No es un defecto del framework, sino un reparto del trabajo: Filament promete una interfaz de administración y nada más, igual que Laravel promete un framework y no una aplicación terminada. En la práctica eso significa que Filament acorta el trabajo de administración y no acorta nada en la parte por la que se eligió el desarrollo a medida.

Por eso, en nuestra tarifa la versión Basic de la tienda por 4.500 € va sin módulo de almacén, sin soporte multiidioma, sin niveles de precios B2B, sin sistema de descuentos y sin migración de contenido, y la versión Pro por 9.500 € va con todo ello. La diferencia no es un recargo por tecnología más moderna, sino el precio de lo que alguien tiene que escribir, y justamente por eso es igual en las dos plataformas. Un sistema Laravel de alcance fijo desde 8.000 € es ya otra línea de la tarifa y otro producto: no es una tienda, sino un sistema en el que todo el proceso nace desde cero.

Lo que no prometemos: dónde lo construido a medida sale más caro

Una tienda propia está libre de las licencias anuales de los plugins, no del mantenimiento, y son dos cosas completamente distintas. Laravel da a cada versión 18 meses de correcciones de errores y dos años de correcciones de seguridad, publica una versión mayor al año y no tiene un nivel de soporte extendido, así que las fechas son concretas: Laravel 13 salió el 17 de marzo de 2026 con correcciones de seguridad hasta el 17 de marzo de 2028, la ventana de seguridad de Laravel 11 se cerró el 12 de marzo de 2026, y las correcciones de errores de Laravel 12 terminan el 13 de agosto de 2026. Una vez al año o cada dos, por tanto, hay que llevar el sistema a una versión mayor nueva, y la documentación de Laravel dice que se esfuerzan por que eso se pueda hacer en un día o menos: un esfuerzo, no una promesa sobre cuánto durará en su sistema.

La rueda de versiones de PHP, además, gira igual para los dos lados: cada versión tiene dos años de soporte activo y dos años más solo de correcciones de seguridad, de modo que en una ventana de cinco años caben al menos una y, según en qué punto del ciclo empiece, hasta dos migraciones forzosas de PHP, sea lo que sea lo que haya debajo. Ni una tienda WooCommerce ni una Laravel se libran de esa línea, y en los dos casos la planifica la misma persona que planifica el resto del mantenimiento: la única diferencia es que sobre código propio el salto se da cuando a usted le viene bien, y no cuando una extensión deja de soportar la versión antigua.

Tres líneas en las que gana la herramienta ya hecha

Más caras que el mantenimiento son otras tres líneas, y la primera es el ecosistema: aquí la herramienta ya hecha gana sin discusión. Una automatización de marketing más en una tienda WooCommerce es una ficha del mercado —AutomateWoo, por ejemplo, cuesta 140 € al año— y, según nuestra experiencia, un día de trabajo, mientras que en un sistema propio es una especificación, unas horas y una prueba, y a 50 € la hora es la primera función sobre la que usted se preguntará si de verdad hace falta; un campo de artículo o un filtro nuevo en la administración no están en esa lista, porque eso lo da el framework. La falta de ecosistema no es un coste puntual, sino un umbral permanentemente más alto para todo lo que después apetezca probar, y en una tienda que experimenta mucho puede pesar más que la factura de licencias: precisamente por eso la factura de licencias no la presentamos como el argumento principal.

La segunda es la dependencia de un solo equipo, y a eso responde la estructura, no una afirmación: en un desarrollo por encargo el código es suyo desde el primer día, lo escribimos en una estructura Laravel estándar y sin exotismos, la lógica crítica tiene pruebas, y va acompañado de un README documentado y de CI para que el sistema lo pueda tomar otro. Encontrar desarrolladores de Laravel en Letonia es fácil, y por eso nuestra propia respuesta a la pregunta de por qué Laravel termina con la frase de que usted no queda dependiendo de un solo equipo, tampoco de nosotros: eso no anula el riesgo, pero lo convierte en un riesgo transferible.

La tercera es PCI DSS, y va en contra nuestra. La revisión del SAQ A, publicada en enero de 2025 y en vigor desde el 31 de marzo de 2025, eliminó los requisitos 6.4.3 y 11.6.1 —el inventario de scripts, su justificación y la vigilancia de sus cambios— y el requisito 12.3.1 sobre el análisis de riesgo dirigido, pero solo para los comerciantes cuya página de pago la entrega íntegra y directamente un proveedor conforme con PCI DSS y que han confirmado ellos mismos que su sitio no está expuesto a ataques basados en scripts, y señala al mismo tiempo que eso no elimina los requisitos de PCI DSS en sí. Ese alivio describe una tienda WooCommerce pequeña con página de pago del banco mucho mejor que un paso de pago representado en código nuestro, y a su lado hay otro hecho igual de incómodo: la vulnerabilidad de marzo la encontró y la corrigió otro, mientras que en un sistema escrito por nosotros lo hace nuestro equipo, así que ahí el mantenimiento es una línea del contrato y no una suposición.

Nuestras dependencias no son de otra especie

Filament es exactamente la misma dependencia de terceros que los plugins de los que acabamos de hablar, y la diferencia entre unos y otro es de grado y de posición, no de principio. Es una única dependencia con licencia MIT en la capa de desarrollo, su código está en nuestro repositorio y se puede bifurcar, y no se interpone en la ruta de pago del comprador: dibuja el panel de administración, no acepta pagos.

Si el proyecto se parase mañana, la tienda seguiría aceptando pedidos y envejecería la parte que ven sus empleados, no la que toma el dinero del comprador. Filament publica además una tabla de soporte de versiones con fechas concretas: la tercera versión salió en agosto de 2023 y recibe correcciones de seguridad hasta el 1 de enero de 2028, una ventana más larga que la que el propio Laravel da a sus versiones.

Filament, con todo, no es un paquete de primera parte de Laravel, porque Laravel no lo menciona en su lista de paquetes, y detrás del proyecto no hay una empresa con balance, sino un equipo alrededor de un único mantenedor: a su nombre hay en el repositorio unos 17.000 cambios, frente a unos 2.400 del siguiente colaborador, y la financiación viene de patrocinadores en GitHub y de consultoría de pago. El ritmo de lanzamientos tampoco es suave: la cuarta versión salió en agosto de 2025 y la quinta ya en enero de 2026, dos días después de Livewire 4, que es otra dependencia de terceros por debajo. Y la frase «si hace falta, lo bifurcamos» es barata de escribir y cara de ejecutar.

No ofrecemos una tienda sin dependencias de terceros, porque no la tenemos ni nosotros ni nadie; ofrecemos un número menor de ellas, una licencia que permite quedarse el código y mantenerlo uno mismo, y una frontera clara entre lo que al fallar detiene el flujo de caja y lo que estropea la jornada de un empleado. Si a usted esa diferencia no le parece lo bastante grande, es una objeción perfectamente razonable, y entonces le construimos la herramienta ya hecha, porque es la misma versión Basic o Pro por el mismo precio. Ninguna de las dos respuestas nos convierte en el proveedor equivocado.

Cómo tomamos esta decisión en la práctica

Junto con la plataforma usted compra la respuesta a una sola pregunta —quién puede cambiar las reglas de sus precios y de sus pedidos, y con qué calendario—, y sobre código propio esa respuesta es «usted, en el próximo sprint», mientras que sobre la extensión de otro fabricante es «cuando el fabricante lo incluya en su lanzamiento, si lo incluye». Por eso, en la reunión de análisis no preguntamos por la facturación, sino por cuántos niveles de precio tiene usted en realidad y por si un cliente ve alguna vez un precio distinto del que ve otro: ahí está la frontera entre los dos campos de precio que WooCommerce da de serie y una tabla de precios que alguien tiene que mantener.

Después preguntamos si el stock vive en más de un sitio, porque el almacén más la estantería de la tienda ya son dos sitios, y dos sitios significan que alguien tiene que decidir cuál de los dos cuenta como la verdad. Las dos preguntas siguientes suelen decidirlo todo: si un pedido pasa a ser pedido de inmediato o necesita antes una aprobación —del departamento de compras del cliente, de su responsable de ventas o del límite de crédito—, y si el proceso seguiría sirviendo con el catálogo del doble de tamaño.

Si la respuesta sobre la aprobación es «sí», usted está en el punto donde el mercado de plugins ya hechos es más débil: la vigilancia de los límites de crédito y el bloqueo de los pedidos que los superan no están ni en el núcleo ni en los paquetes B2B más extendidos, y solo lo prometen unas pocas fichas especializadas, como QuarkCode B2B Commerce Suite. Cuánta parte del proceso está dispuesto a rehacer para adaptarse a la herramienta es la pregunta que queda, y unos requisitos poco claros son el error más caro de todo el encargo, sobre el que hemos escrito por separado.

Si las respuestas caben en una herramienta ya hecha, quédese con la herramienta ya hecha, porque saldrá más barato, y se la construimos nosotros. Si no caben una o dos, lo más probable es que esté usted en el camino intermedio, y en la tarifa eso corresponde a esa misma versión Pro por 9.500 € sobre WooCommerce: el mismo precio que sobre Laravel, porque lo que se paga es el trabajo y no la plataforma. Si no caben tres o más, y sobre todo si entre ellas están el paso de aprobación o el límite de crédito, la conversación ya no va de la plataforma, sino de cuánta parte del proceso vive en código que podemos cambiar sin pedir permiso a otro fabricante.

Tres arranques y lo que cuesta cada uno

En la práctica vendemos tres arranques, y cada uno tiene un precio que se puede calcular. El primero es empezar por el catálogo, los pagos y los envíos, salir a producción, y añadir los precios B2B, la lógica de descuentos y las integraciones de almacén cuando ya se vean los primeros pedidos reales: en nuestras respuestas lo llamamos la elección normalmente acertada. El segundo es trasladar una tienda existente, y eso es un proyecto y no un interruptor: la estructura de URL la conservamos, pero los modelos de datos no coinciden uno a uno, y cada plugin que haya guardado sus propios campos hay que evaluarlo por separado. En la versión Pro y en el alquiler la migración va incluida; en la Basic no está, y la presupuestamos aparte según el alcance, porque el precio lo deciden la cantidad de datos y el número de campos.

El tercero es el alquiler: una tienda Laravel junto con nuestro alojamiento desde 130 € al mes más 600 € de pago único por la configuración, y en la tarifa su composición es la misma que la de la versión Pro —módulo de almacén, soporte multiidioma, niveles de precios B2B, sistema de descuentos y migración de contenido—, solo que con alojamiento, actualizaciones y mantenimiento añadidos; está disponible únicamente con Laravel, porque una tienda WooCommerce con nosotros no se puede alquilar. La elección de plataforma decide por sí sola unas pocas cosas concretas que el trabajo no iguala: esta línea de alquiler, los parches automáticos y gratuitos del núcleo, el umbral del ecosistema y quién tiene que dar su conformidad antes de que su próximo cambio llegue a producción. Todo lo demás es trabajo.

El alquiler arranca en 130 € al mes, que en cinco años son desde 7.800 €, más 600 € de configuración: desde 8.400 €, y ahí dentro entran el alojamiento, las actualizaciones y el mantenimiento. La versión Pro cuesta 9.500 € una sola vez, y el alojamiento va aparte: nuestro alquiler de infraestructura arranca en 45 € al mes, es decir, desde 2.700 € en cinco años, en total desde 12.200 €, y las actualizaciones de la aplicación todavía no están ahí dentro. Las dos cifras son suelos y no totales, y son comparables porque en la tarifa la composición de funciones de ambas es exactamente la misma. En el alquiler usted paga por el uso junto con el alojamiento; en la construcción paga el sistema de una vez, y, comparando los dos suelos, en una ventana de cinco años el alquiler empieza más abajo. Dónde termina cada uno lo decide el alcance, y por eso las dos las presupuestamos por proyecto en vez de leerlas de la tarifa.

A partir de ahí el trabajo avanza en sprints de dos semanas con una demo después de cada uno; los pagos, las empresas de transporte y la contabilidad los conectamos y comprobamos antes de la puesta en marcha; los productos, los clientes y el historial de pedidos los trasladamos conservando la estructura de URL. Para trabajos mayores no estándar trabajamos por tiempo y materiales con un tope semanal, porque un precio cerrado ahí suele significar o un recargo por el riesgo o una discusión sobre el alcance, y la hora en la tarifa cuesta 50 €. Todo el recorrido lleva de 8 a 32 semanas. Reciba una valoración del proyecto y una recomendación tecnológica: respóndanos a esas mismas preguntas y le diremos cuál de los tres caminos le sale más barato en su caso.