SYLIUS NEXT.JS PWA SUBIEKT GT LOGÍSTICA 3D D2C

Plantoris

Lo más difícil en esta tienda no fue el carrito, sino la caja.

Ogrody Drama lleva tres generaciones vendiendo plantas: cultivo desde 1974, centro de jardinería y estudio de paisajismo cerca de Zbrosławice desde 1996, hoy 50 personas. Plantoris es su entrada en el mercado de toda Polonia. Construimos todo el sistema desde cero: Sylius como motor, Next.js como capa de front end, Subiekt GT como fuente única de verdad sobre la mercancía y un algoritmo propio de empaquetado 3D, sin el cual esta tienda no calcularía correctamente ni un solo envío.

Plantoris — la tienda online de Ogrody Drama construida sobre Sylius y Next.js — Plantoris — tienda de plantas para toda Polonia, construida desde cero sobre Sylius y Next.js.

01 Desafío y enfoque

× Antes

La mercancía viva rompe el modelo estándar de una tienda. Una planta cambia de tamaño a lo largo de la temporada, unos artículos no se pueden apilar y otros no se pueden enviar cuando hiela. Los motores de e-commerce estándar no tienen un campo para eso en la base de datos.
El coste de envío no se deriva del peso. Un arbolito de dos metros y un saco de sustrato con la misma masa son dos envíos completamente distintos. Una tarifa plana significa o poner dinero en cada pedido o espantar al cliente.
Dos almacenes, un solo pedido. Las plantas y los accesorios salen de ubicaciones distintas, y el cliente ve un solo carrito y un solo importe.
La verdad sobre la mercancía está en el ERP. Las existencias, los precios y el IVA viven en Subiekt GT y nadie va a mantener una segunda base de datos paralela en la tienda.
La escala objetivo, no la inicial. La arquitectura tenía que soportar desde el primer día un catálogo del orden de 100.000 referencias y varias decenas de miles de fotografías.

→ Nuestro enfoque

Backend first. Empezamos por las integraciones y la lógica, no por el aspecto visual. La capa gráfica se desarrollaba en paralelo del lado de la agencia del cliente y entró en los trabajos solo cuando el motor ya calculaba.
Los datos logísticos como ciudadano de primera clase. El peso, las tres dimensiones, el indicador de «si se puede apoyar algo encima», el tipo de embalaje, la fase de crecimiento y el mes de disponibilidad son campos del producto, no una frase en la descripción.
Reglas en lugar de excepciones. La estacionalidad, la hora de corte de los envíos y la suspensión cuando hiela son configuración en el panel, no una llamada al programador en noviembre.
Sylius, y no una tienda enlatada. Con esta cantidad de reglas a medida, un framework con un modelo de dominio abierto sale más barato en un año que pelearse con las limitaciones de una plataforma cerrada.

02 Stack tecnológico

Con qué lo construimos.

Sylius (Symfony)

motor de e-commerce, modelo de producto con atributos de jardinería, zonas fiscales, monedas, panel de administración con un ACL extenso

Next.js (PWA)

capa de presentación, maquetada sobre los diseños gráficos entregados por la agencia del cliente

Subiekt GT

integración bidireccional: productos, precios, existencias e IVA hacia la tienda; pedidos, clientes y proveedores de vuelta al ERP

Cloudflare CDN + Images

distribución y conversión automática de las imágenes a WebP y AVIF

Apaczka

etiquetas de transporte y estados de los envíos cargados en el panel del cliente

Sentry

monitorización de errores en el backend y en el front end

Marketing automation

eventos de compra, carritos abandonados, segmentos de clientes, integración de reseñas

Feeds XML

Google Merchant, Ceneo, herramientas de monitorización de los precios de la competencia

03 Soluciones

Tres cosas que no hará ninguna tienda estándar.

Algoritmo de empaquetado 3D (bin packing)

El sistema no estima el coste de envío, lo calcula. Antes de finalizar el pedido simula la colocación física de la mercancía: toma las dimensiones y el peso de cada artículo, comprueba el indicador de apilabilidad (las plantas delicadas no lo tienen), elige la combinación más barata de embalajes del conjunto disponible de cajas, cajones y palés, y solo a partir de ella calcula el importe de tarifa para el cliente. Los embalajes tienen sus propias dimensiones, coste logístico y existencias en almacén.

Por qué esto importa: con un surtido que va desde un sobre de semillas hasta un arbolito de dos metros, la diferencia entre calcular y aplicar una tarifa plana es margen real en cada pedido.

Envío dividido

El carrito se divide automáticamente en subpedidos según la ubicación de la mercancía: las plantas por un lado, las macetas y los accesorios por otro, con la suma correcta de los costes de envío. El cliente ve un solo pedido, los almacenes ven sus propias listas y el ERP recibe el juego completo de datos.

Temporada, tiempo atmosférico y hora de corte

El envío de mercancía viva no es una función continua. Implementamos un día y una hora de corte de envío configurables, la visibilidad estacional de categorías y productos, reglas logísticas definidas por mes y la suspensión de los envíos con temperaturas cercanas a cero, activada desde el panel por un operador. A esto se suman búferes de venta por producto y un estado aparte, «inicio del empaquetado», visible únicamente para la zona de empaquetado.

Esquema de la arquitectura de Plantoris: Subiekt GT, Sylius, Next.js, Apaczka, Cloudflare y Sentry — Subiekt GT sigue siendo la fuente única de verdad sobre la mercancía e intercambia datos con Sylius en ambas direcciones. Sylius contiene la lógica que no tiene ninguna tienda estándar, y de ella se deriva la etiqueta de transporte.

Cómo el algoritmo de empaquetado 3D calcula el coste de envío en lugar de estimarlo — Un saco de sustrato y un arbolito de dos metros pesan lo mismo. Una tarifa plana por peso los valoraría de forma idéntica; el algoritmo elige los embalajes y solo a partir de ellos calcula el importe.

Catálogo de Plantoris con filtros de producto y parámetros botánicos — Catálogo con filtros de producto completos. Los atributos de jardinería son campos del producto, así que se pueden filtrar igual que el precio.

04 Alcance de la implementación

El resto del alcance de la implementación.

Catálogo: producto en varias categorías a la vez, variantes con precio y EAN propios, cross selling, atributos de jardinería (resistencia a las heladas, exposición, suelo), mega menú visual con mosaicos
Venta anticipada: venta anticipada con fecha de entrega propia, pago por adelantado, bloqueo de la combinación de mercancía disponible con no disponible
Pasaportes fitosanitarios digitales: el código QR del producto lleva a la ficha virtual de la planta con instrucciones de cuidado y la añade al panel «Mój Ogród» (Mi Jardín) sin tener que buscarla en la tienda
Plant Doctor: jardinero virtual, agente de IA que responde a preguntas sobre la elección y el cuidado
Programa de fidelización: integración con el sistema de puntos que ya tenía el cliente: inicio de sesión único, saldo e historial de puntos, umbrales, barra de progreso, recompensas, cartera de cupones, ofertas por nivel
Promociones: promociones temporales porcentuales y por importe, cupones de un solo uso y de usos múltiples, pestaña de ofertas, planta de la semana y del mes, soporte completo de la Directiva Ómnibus con el historial del precio más bajo de los últimos 30 días
Panel y CMS: roles y permisos (administrador, zona de empaquetado, atención al cliente), banners, blog de consejos, materiales descargables, páginas informativas y formulario de contacto
Servicio de proyectos de jardín: encargo del proyecto de jardín en línea, cuestionario y presupuesto, documentación con una lista de plantas que lleva de vuelta al carrito

05 Cómo llevamos este proyecto

Seis meses en modelo backend first, con resultados concretos al final de cada etapa.

ETAPA 1

Fundamentos

Talleres técnicos, mapeo de los datos del ERP, entornos Dev y Stage, CDN.

ETAPA 2

Integración con el ERP

Sincronización de productos, precios y existencias, atributos de jardinería en la base de datos, feeds XML.

ETAPA 3

Logística

Envío dividido, algoritmo de empaquetado, marketing automation, estados de los envíos.

ETAPA 4

Lógica de UX e IA

Recorridos de usuario, consultas sobre los mockups con la agencia del cliente, implementación del jardinero virtual.

ETAPA 5

Frontend

Design review de los diseños entregados, maquetación de las vistas en Next.js, configuración del CMS.

ETAPA 6

Estabilización

Pruebas de carga, pruebas de aceptación, formación del equipo, migración a producción.

06 Resultados

Lo que cambió.

Una empresa de alcance local vende en toda Polonia, con el mismo surtido y el mismo conocimiento.

El coste de envío ha dejado de ser una conjetura. Cada pedido tiene los embalajes calculados, y no una tarifa plana calculada por peso.

El ERP sigue siendo la única fuente de verdad sobre la mercancía. El equipo trabaja en Subiekt igual que hasta ahora y la tienda se pone al día sola.

De la temporada se ocupa el panel, no el programador. La hora de corte, la visibilidad de las categorías y la suspensión de los envíos cuando hiela están en manos del equipo del cliente.

El estudio de paisajismo ha ganado un canal de venta, porque el proyecto de jardín termina con una lista de plantas que se pueden comprar en esa misma tienda.

Arquitectura preparada para un catálogo del orden de 100.000 referencias, así que ampliar el surtido no significa reescribir el sistema.

Sin porcentajes. La tienda funciona desde hace poco y, en lugar de cifras vistosas sin respaldo, mostramos qué ha cambiado realmente este sistema.

07 Casos similares

¿Tiene un problema parecido?

Si su carrito tiene que entender a la vez el volumen, la temporada y dos almacenes, una tienda estándar no lo soportará. Le mostraremos cómo calcularlo correctamente.