Lanzaste tu tienda Shopify hace unos meses. Todo funciona bien. Las tasas de conversion estan bien, los clientes estan contentos. Luego, en algun momento entre el mes 12 y el 18, te das cuenta: Algo ya no esta bien.
Las nuevas funcionalidades de repente tardan mas. Tu theme se vuelve cada vez mas lento. Las apps no se comunican entre si. Y el codigo -- que nadie documento -- se ha vuelto impenetrable.
Eso no es casualidad. Lo llamamos el problema de los 18 meses.
En mas de cinco anos de desarrollo Shopify, hemos visto esto decenas de veces. Y sabemos cual es la causa: No se trata de Shopify. Se trata de arquitectura.
El problema de los 18 meses: Tres sintomas, una causa
Cuando hablamos con nuevos clientes que quieren optimizar su sistema, a menudo escucho las mismas quejas:
1. Theme parcheado: "Nuestro theme se ha vuelto imposible"
El theme -- esa es la superficie visible de tu tienda -- se convierte en la primera victima de una mala arquitectura en la mayoria de las tiendas. Esto es lo que sucede:
- Necesitas una nueva landing page. El desarrollador modifica el theme existente.
- Necesitas una pagina de coleccion personalizada. Otro desarrollador trabaja en ella.
- Despues de 18 meses: El theme es un conglomerado de personalizaciones, soluciones provisionales y parches.
- Una nueva funcionalidad ya no tarda una semana -- tarda tres semanas porque hay que entender todas las dependencias.
Sin estructura, tu theme se convierte en un monumento a la deuda tecnica.
2. Dependencias de apps: "No podemos reemplazar ningun sistema sin romper todo"
El segundo sintoma es mas sutil -- pero mas caro a largo plazo.
En lugar de logica personalizada, dependes de apps. Eso a veces es la decision correcta -- pero a menudo solo porque la arquitectura alternativa no fue planificada:
- Necesitas una pagina de coleccion personalizada con logica de filtros compleja? App.
- Necesitas un sistema de descuentos personalizado? App.
- Necesitas gestion de inventario con reglas especiales? App.
Despues de 18 meses: Tienes 12 apps instaladas. Juntas cuestan 800/mes. Y cada una de estas apps tiene una API con interfaces diferentes. Reemplazar una app? Eso significa que tienes que reescribir codigo en todos los lugares donde la app almacena datos.
3. Codigo sin documentar: "No sabemos que esta pasando aqui"
El tercer problema es el mas peligroso: Sin decisiones de arquitectura claras, el codigo simplemente se construye -- sin contexto, sin plan.
- Por que almacenas estos datos en Metaobjects?
- Por que este calculo se hace en el theme y no en un Product Variant?
- Por que hay 24 templates de coleccion en lugar de cinco templates inteligentes?
Nadie puede responder. El desarrollador que lo construyo se fue hace tiempo.
Que significa realmente la arquitectura Shopify
Aclaremos: La arquitectura Shopify no es simplemente "codigo limpio" o "mejores practicas".
La arquitectura Shopify es una estructura de decisiones que define:
- Donde vive tu logica (Shopify Admin, Theme, API, Custom App?)
- Como estan organizados tus datos (Metaobjects? Product Variants? Custom App?)
- Cuales sistemas se comunican entre si (APIs? Webhooks? GraphQL?)
- Cuando necesitas apps y cuando escribes codigo personalizado
La mayoria de las tiendas no han tomado ninguna de estas decisiones de forma consciente. Reaccionaron -- a nuevos requisitos, a presion de tiempo, a lo que funcionaba mas rapido en el momento.
El resultado: Un sistema imposible de mantener.
Un ejemplo de la practica: Bekateq
Bekateq es una tienda B2B con un requisito muy especifico: Los clientes necesitan descuentos por volumen individuales por articulo. Eso es imposible con el sistema de descuentos estandar de Shopify.
La solucion incorrecta: Comprar una app que pueda hacerlo. Coste: 200/mes. Automatizacion: Cero.
La solucion correcta (la que construimos con Bekateq):
- Estructura de datos: Custom Metaobjects para "Customer-Specific Pricing"
- Logica: Una pequena Custom App (80 lineas de codigo) que ajusta los precios al anadir al carrito
- Integracion: Directamente en el Cart GraphQL Query -- sin rodeos a traves de APIs externas
El resultado: 4.400+ lineas de codigo personalizado estrategico en lugar de 12 apps caras. Mantenibilidad: 100%. Coste: Una fraccion.
Eso es arquitectura.
Metaobjects, Custom Logic, datos estructurados -- explicados de forma simple
Si quieres repensar la arquitectura de tu tienda, necesitas entender tres conceptos:
Metaobjects: El contenedor de datos
Los Metaobjects son la respuesta mas nueva (y mejor) de Shopify a la pregunta: Como almacenar datos personalizados de forma estructurada?
En lugar de poner propiedades en los Products (que no escalaba), o almacenar cadenas JSON en product.metafields.namespace (que se vuelve inmantenible), ahora puedes definir plantillas:
Customer Pricing
-- Customer (relationship)
-- Product (relationship)
-- Discount Percentage (number)
-- Valid Until (date)
Y Shopify lo almacena de forma estructurada. Puedes filtrar, ordenar y construir logica sobre ello.
Cuando necesitas Metaobjects: Siempre que quieras datos personalizados que esten asociados a multiples Products o Customers. Precios, bundles, reglas de variantes, personalizacion -- todo vive en Metaobjects.
Custom Logic: Donde ocurre tu magia
Custom Logic no es codigo del theme. No es una app. Es la capa entre la base de datos de Shopify y tus clientes.
Custom Logic puede ser:
- Logica de producto: Cuando se compra el Producto A, el Producto B debe anadirse automaticamente al carrito.
- Logica de variantes: Ciertas combinaciones de opciones no estan permitidas.
- Logica de precios: El precio depende de atributos del cliente o cantidades.
- Logica de pedidos: Despues del checkout, algo especifico debe suceder.
La pregunta no es "necesitas Custom Logic" -- sino "donde vive?"
En el theme? No -- eso se vuelve demasiado lento e inmantenible. En una app? Solo si no hay una forma mejor. En una Custom App que tu controles? Si -- eso es arquitectura.
Datos estructurados: Tu sistema como API
Una buena arquitectura convierte tu tienda en una API, no en una caja negra.
Esto significa:
- Tus datos estan estructurados (Metaobjects, no cadenas JSON).
- Tu logica es clara (Custom Apps con una responsabilidad, no codigo monolitico).
- Tus interfaces estan documentadas (GraphQL queries, no codigo admin secreto).
Esto hace posible:
- Incorporar nuevos miembros del equipo (todo esta documentado).
- Construir nuevas funcionalidades (todo es modular).
- Reemplazar sistemas (todo se basa en APIs claras).
Como abordamos proyectos de arquitectura: Ejemplos reales
Todo esto suena teorico. Dejame mostrarte concretamente como funciona en la realidad.
Caso de estudio 1: J.Clay -- 3 iteraciones en 5 anos
J.Clay es un e-commerce de moda con altas exigencias de personalizacion.
No rediseñamos todo de una vez. Construimos una arquitectura para la evolucion:
Iteracion 1 (2020): Fundacion
- Metaobjects para tablas de tallas
- Custom App para logica de prediccion de tallas
- Separacion clara: El theme renderiza, la Custom App maneja la logica
Iteracion 2 (2022): Escala
- Nuevos Metaobjects para preferencias de clientes anadidos
- Custom App ampliada con motor de personalizacion
- Sin necesidad de refactorizar el theme -- todo funciona a traves de nuevas APIs
Iteracion 3 (2024): Rendimiento e inteligencia
- Queries GraphQL optimizadas (antes: 500ms para pagina de coleccion, despues: 120ms)
- Motor de recomendaciones basado en IA anadido (de nuevo: a traves de Custom App)
- El theme nunca fue un cuello de botella
El resultado: +107% de crecimiento de ingresos en 5 anos. Y el theme? El mismo de 2020, solo optimizado.
Eso es buena arquitectura.
Caso de estudio 2: Bekateq -- De 12 apps a 0
Bekateq es una tienda B2B con requisitos complejos. Tenian 12 apps instaladas -- todas intentando llenar diferentes partes de un plan de arquitectura ausente.
Construimos un plan de arquitectura:
Apps: 0 (en serio) Custom Metaobjects: 8 (Customer Pricing, Volume Pricing, Approved Vendors, etc.) Codigo personalizado: 4.400+ lineas en 4 Custom Apps Templates de coleccion: 24 (no 12.000 hacks de CSS) Costes mensuales: Bajaron de 2,5k a 400
Y el punto mas importante: El sistema es mantenible. Cada Custom App tiene una responsabilidad. Cada Metaobject tiene una razon de existir. Cada template tiene un objetivo.
Cuando una nueva persona se une al equipo, puede ser productiva en dos semanas -- no despues de dos meses.
Checklist: Necesita mi tienda una revision de arquitectura?
Si reconoces uno o mas de estos puntos, entonces si:
- Tu tienda tiene mas de 12 meses y las nuevas funcionalidades tardan mas que al principio
- Tienes mas de 8 apps instaladas
- El codigo de tu theme tiene > 5.000 lineas (sin dependencias)
- Usas cadenas JSON en metafields en lugar de Metaobjects
- Tus desarrolladores no pueden explicar "por que" algo se construyo asi
- Pagas mas de 1k/mes en apps que solo hacen una cosa
- Una nueva variante de pagina de coleccion tardo mas de una semana
- Tu tienda tiene logica personalizada que "de alguna manera funciona, pero nadie la entiende"
- Tienes multiples versiones de templates similares (p. ej., 5 paginas de coleccion diferentes)
- Cambiar una funcionalidad requiere actualizar codigo en 3+ lugares diferentes
3+ marcados? Necesitas una revision de arquitectura.
Y si, eso cuesta tiempo y dinero. Pero cuesta menos que tener un sistema que se vuelve inmantenible a largo plazo.
Que hariamos con tu tienda
Cuando hablas con nosotros sobre una revision de arquitectura, hay un proceso claro:
Fase 1: Auditoria (1-2 semanas)
Examinamos tu tienda actual:
- Revision de codigo
- Auditoria de apps
- Analisis de estructura de datos
- Testing de rendimiento
Resultado: Un informe que muestra donde estan los problemas.
Fase 2: Planificacion de arquitectura (2-4 semanas)
Construimos un nuevo plan:
- Que apps pueden irse? (y como?)
- Donde se necesita codigo personalizado?
- Que Metaobjects son necesarios?
- Como se realizara la migracion?
Resultado: Una hoja de ruta tecnica en la que ambos estamos de acuerdo.
Fase 3: Implementacion (6-12 semanas)
Construimos:
- Nuevos Metaobjects
- Custom Apps
- Theme refactorizado (si es necesario)
- Migracion de datos antiguos
Resultado: Una tienda mantenible y a prueba de futuro.
Nuestro servicio Architecture+ empieza desde 10k e incluye las tres fases.
La verdad incomoda
La buena arquitectura Shopify no es sexy. No hay diapositivas para compartir en LinkedIn. No es una nueva app, no es una nueva funcionalidad.
Es artesania. Es planificacion. Es lo opuesto a "hecho rapido a trompicones".
Pero tambien es la diferencia entre una tienda que puedes escalar facilmente en 5 anos -- y una tienda cuya complejidad se te escapa de las manos.
Hemos visto ambos tipos. Sabemos cual es mejor.
Si tu tienda se esta haciendo mayor y notas que algo no esta bien, es hora de pensar en ello. No el ano que viene. Ahora. Antes de que el problema de los 18 meses te alcance.
Sobre Claudio Gerlich
Claudio Gerlich es el fundador de smplx. y partner tecnico de Shopify desde 2020. Desde Munsterland, NRW, ha diseñado la arquitectura y optimizado mas de 50 tiendas enterprise. Su experiencia reside en planificar sistemas que no colapsan -- incluso cuando el e-commerce crece.
Si quieres hablar sobre la arquitectura de tu tienda, escribenos.