Las limitaciones de webflow: cuándo no es la herramienta adecuada para tu proyecto

Webflow se ha ganado su reputación como una de las plataformas de desarrollo visual más potentes del mercado. Para sitios de marketing, portafolios y proyectos orientados al contenido, cumple genuinamente con lo que promete: código limpio, un CMS capaz y una interfaz amigable para diseñadores que reduce la brecha entre el diseño y la producción. Sin embargo, Webflow no es una solución universal, y tratarlo como tal es la razón por la que los proyectos se desvían.

En werun.dev, construimos en Webflow todas las semanas. También les decimos a nuestros clientes cuándo no utilizarlo. Esta publicación trata sobre esa segunda parte: la evaluación honesta de dónde la arquitectura de Webflow genera fricción, dónde su modelo de precios deja de tener sentido y dónde un stack diferente servirá mejor a tu negocio en un horizonte de tres a cinco años.

Dónde la Arquitectura del CMS de Webflow Se Queda Corta

El CMS de Webflow es genuinamente bueno para lo que fue diseñado: gestionar contenido estructurado como publicaciones de blog, perfiles de equipo, casos de estudio y listados de productos dentro de un contexto de sitio único. El editor visual de colecciones es intuitivo, el sistema de vinculación dinámica es limpio y, para equipos editoriales que publican algunas veces por semana, funciona bien.

Los problemas surgen cuando los proyectos superan esos supuestos.

El Límite de 10,000 Elementos en el CMS

Webflow impone un límite estricto de 10,000 elementos por colección. Para un blog corporativo o un portafolio, ese techo es irrelevante. Para una plataforma inmobiliaria con 50,000 listados de propiedades, una bolsa de trabajo con inventario rotativo o un catálogo de e-commerce con SKUs de variantes complejas, es una restricción que puede dar por terminado el proyecto. No existe ninguna solución alternativa dentro del CMS nativo de Webflow: o se pagina de forma agresiva, se elimina contenido antiguo de manera programada, o simplemente se está en la plataforma equivocada.

Las Relaciones Entre Colecciones Son Superficiales

Webflow permite campos de referencia múltiple, pero la profundidad relacional se detiene ahí. No es posible realizar consultas entre colecciones con filtros significativos a nivel del CMS. Una publicación de blog puede referenciar múltiples autores, pero no se puede construir una página que extraiga dinámicamente todas las publicaciones de un autor específico, filtradas por categoría y ordenadas por engagement, sin JavaScript personalizado que acceda a la API de Webflow, y aun así se estaría luchando contra la plataforma en lugar de trabajar con ella.

Para modelos de contenido que requieren lógica relacional genuina —como un sitio de documentación SaaS, un sistema de gestión de aprendizaje o un directorio multi-tenant— el CMS de Webflow se convierte en un pasivo. En el momento en que el equipo editorial necesita gestionar relaciones de contenido que reflejen un esquema de base de datos real, se está ante la necesidad de un CMS headless (Contentful, Sanity, Prismic) que alimente un front-end personalizado, o una instalación de WordPress con una estructura de tipos de contenido personalizados correctamente arquitectada.

El CMS de Webflow y los Datos en Tiempo Real No Son Compatibles

El CMS de Webflow no está diseñado para datos en tiempo real o con actualizaciones frecuentes. Publicar cambios requiere un ciclo de publicación del sitio. Si el contenido se actualiza en intervalos medidos en minutos en lugar de días —precios en vivo, conteos de inventario, marcadores deportivos, datos financieros— el CMS de Webflow es la capa de almacenamiento incorrecta. Es posible obtener datos externos mediante JavaScript personalizado y APIs de terceros, pero en ese punto el CMS en sí no aporta ningún valor, y se está pagando por la infraestructura de Webflow para servir una capa estática alrededor de una capa de datos personalizada.

Cuándo considerar alternativas:

• Colecciones que superan los 5,000 elementos con trayectoria de crecimiento
• Modelos de contenido que requieren consultas relacionales de múltiples niveles
• Requisitos de actualización de datos en tiempo real o con frecuencia inferior a una hora
• Arquitecturas multi-sitio que comparten una única fuente de contenido

E-Commerce: Donde Webflow Alcanza un Techo Estructural

Webflow lanzó su producto de e-commerce en 2019 y ha mejorado significativamente desde entonces. Para catálogos pequeños —un estudio de diseño que vende impresiones, una consultora que vende un único curso, una marca con menos de 50 SKUs— Webflow Ecommerce es una opción razonable. La flexibilidad de diseño es genuinamente superior al sistema de temas predeterminado de Shopify, y la integración entre la tienda y el sitio de marketing es fluida.

Sin embargo, Webflow Ecommerce no fue construido para competir con Shopify a escala, y la brecha se hace evidente rápidamente.

Gestión de Variantes e Inventario

Webflow admite variantes de productos, pero el sistema de gestión de variantes es rudimentario en comparación con el de Shopify. Se obtienen dos tipos de opciones por producto. La indumentaria compleja —talla, color, corte, largo— requiere soluciones alternativas. El seguimiento de inventario es básico. No hay soporte nativo para paquetes, productos de suscripción o preventas sin herramientas de terceros que añaden costos y sobrecarga de mantenimiento.

El sistema de variantes de Shopify, en contraste, admite hasta tres opciones con 100 variantes por producto de forma nativa, y Shopify Plus amplía esto aún más. Más importante aún, todo el ecosistema de Shopify —aplicaciones, integraciones de fulfillment, sistemas POS, canales mayoristas— está construido alrededor de esa arquitectura de variantes.

La Brecha en el Ecosistema de Aplicaciones

Shopify cuenta con más de 8,000 aplicaciones en su marketplace. Webflow Ecommerce tiene una fracción de eso. Cuando un retailer de mercado medio necesita facturación por suscripción, programas de fidelización, filtrado avanzado de productos, niveles de precios B2B, soporte multi-moneda y un portal de gestión de devoluciones, Shopify tiene una aplicación madura para cada uno de esos requisitos. Webflow requiere desarrollo personalizado para la mayoría de ellos.

Esto no es una crítica a la filosofía de plataforma de Webflow, sino simplemente el reconocimiento de que Shopify lleva una década de ventaja en la capa de infraestructura de comercio. Para proyectos donde el comercio es la función principal del negocio en lugar de una fuente de ingresos secundaria vinculada a un sitio de marketing, Shopify Plus es casi siempre la elección correcta.

Personalización del Checkout

El checkout de Webflow está alojado en su plataforma y tiene opciones de personalización limitadas. No es posible inyectar lógica personalizada en el flujo de checkout, implementar secuencias de upsell personalizadas ni integrarse profundamente con herramientas de detección de fraude y cumplimiento normativo de terceros. El framework Checkout Extensibility de Shopify Plus, en contraste, permite una personalización significativa de la experiencia de checkout a través de Checkout UI Extensions y Functions, una capacidad crítica para comerciantes de alto volumen que optimizan la conversión.

Webflow Ecommerce es la opción correcta cuando:

• El catálogo tiene menos de 100 SKUs con una estructura de variantes simple
• La tienda es secundaria respecto a un sitio de contenido o marketing
• La diferenciación de diseño a nivel de página de producto es una prioridad
• El presupuesto no contempla una implementación completa de Shopify Plus

Migrar a Shopify cuando:

• Los productos de suscripción o ingresos recurrentes están en el alcance del proyecto
• Se requiere precios B2B, venta mayorista o comercio multicanal
• El ecosistema de aplicaciones es fundamental para el modelo de negocio
• El GMV anual supera los $500k y las herramientas operativas son relevantes

Lógica de Aplicaciones Personalizadas y Autenticación

Webflow es un constructor de sitios web con capacidades de CMS y un entorno de desarrollo visual. No es un framework de aplicaciones. Esta distinción importa enormemente al definir el alcance de proyectos que involucran autenticación de usuarios, control de acceso basado en roles, lógica de formularios compleja o interacciones de usuario con estado.

La Autenticación Nativa No Es una Característica de Webflow

Webflow no tiene autenticación nativa de usuarios. Punto. Todo en este ámbito —inicios de sesión de miembros, contenido restringido, portales de clientes, paneles de usuario— requiere un servicio de terceros. Memberstack y Outseta son las dos opciones más maduras en el ecosistema de Webflow, y ambas son herramientas capaces para los casos de uso adecuados. En werun.dev utilizamos ambas y hemos construido sitios de membresía en producción con cada una.

Sin embargo, las capas de autenticación de terceros introducen restricciones. Los datos de los usuarios residen en la infraestructura de Memberstack o Outseta, no en la propia. El precio escala con el número de miembros de maneras que pueden volverse significativas a gran volumen. Los flujos de autenticación personalizados —integraciones OAuth, SSO con proveedores de identidad empresarial, autenticación multifactor con UX personalizada— requieren un trabajo considerable de JavaScript personalizado y a veces encuentran límites que ninguna cantidad de código ingenioso puede resolver dentro del entorno de hosting de Webflow.

Para proyectos donde la autenticación es una característica central del producto en lugar de un requisito adicional, un framework de aplicaciones adecuado —Next.js con NextAuth, un backend en Django o Laravel, o una arquitectura headless con un servicio de autenticación dedicado— es la base correcta. En werun.dev, cuando las limitaciones de Webflow en esta área bloquean un proyecto, construimos el front-end en Next.js o Astro, preservando los beneficios de gestión de contenido del CMS de Webflow a través de la API mientras se sirve la capa de aplicación a través de un framework adecuado.

La Lógica del Lado del Servidor Está Fuera de la Mesa

Los sitios de Webflow se renderizan de forma estática y se alojan en el CDN de Webflow. No existe un entorno de ejecución del lado del servidor. Si el proyecto requiere:

• Renderizado del lado del servidor para contenido dinámico sensible al SEO
• Procesamiento de webhooks y lógica orientada a eventos
• Trabajos en segundo plano o tareas programadas
• Proxy seguro de APIs para ocultar credenciales del cliente
• Estrategias de caché personalizadas a nivel de ruta

...entonces Webflow no puede ser la capa de ejecución. Es posible trabajar alrededor de algunos de estos casos con flujos de trabajo de Zapier, Make o n8n que manejen la lógica de middleware, pero estas son soluciones alternativas, no arquitectura. Para proyectos donde la lógica del lado del servidor es fundamental para la experiencia del usuario, la respuesta honesta es que Webflow debería considerarse como una capa de CMS o de contenido como máximo, con un servidor de aplicaciones adecuado gestionando el runtime.

Lógica de Formularios Más Allá de lo Básico

El manejo nativo de formularios de Webflow es mínimo. Se obtienen envíos de formularios al panel de Webflow, una notificación básica por correo electrónico y un webhook para enviar datos a otro lugar. Los formularios de múltiples pasos, la lógica de campos condicionales, las cargas de archivos con procesamiento, los formularios integrados con pagos y los envíos de formularios que desencadenan flujos de trabajo complejos posteriores requieren JavaScript personalizado y servicios de terceros.

Esto es manejable con el enfoque de desarrollo correcto —en werun.dev construimos experiencias de formularios complejas en Webflow regularmente usando JS personalizado y servicios como Typeform, Fillout o implementaciones completamente personalizadas—. Sin embargo, el costo en esfuerzo es real, y para proyectos donde la lógica de formularios es central para el producto (solicitudes, flujos de incorporación, sistemas de cotización complejos), una solución diseñada específicamente para ese propósito será más rápida de construir y más fácil de mantener.

Señales de que tu proyecto necesita más que la capa de aplicación de Webflow:

• Los roles de usuario con diferentes niveles de acceso al contenido son un requisito central
• El producto genera datos específicos del usuario que necesitan persistir y ser consultados
• La integración con SSO o un proveedor de identidad empresarial está en el alcance
• El "sitio" es en realidad una aplicación web con una página de marketing como puerta de entrada
• Se requieren operaciones seguras del lado del servidor por razones de cumplimiento normativo o seguridad

El Precio de Webflow y la Pregunta del Costo Total de Propiedad

El modelo de precios de Webflow merece un análisis honesto, ya que frecuentemente se subestima en las conversaciones de definición de alcance de proyectos. La plataforma ha avanzado de manera agresiva hacia un modelo de precios basado en workspace y asientos, y el costo total de propiedad para un equipo en crecimiento con un sitio complejo puede sorprender a clientes que inicialmente eligieron Webflow por su aparente simplicidad.

Costos de Hosting a Escala

Los planes de sitio de Webflow van desde gratuito hasta Enterprise, con el plan Business a $39/mes cubriendo la mayoría de los sitios de marketing en producción. Eso es razonable. Pero al agregar el hosting del CMS para un sitio con mucho contenido, las tarifas de transacción de Webflow Ecommerce en los planes de nivel inferior y los asientos de workspace necesarios para un equipo de diseñadores y desarrolladores, el costo mensual escala más rápido de lo que muchos clientes esperan.

A modo de comparación, un sitio de WordPress alojado en un proveedor administrado como Kinsta o WP Engine cuesta entre $35 y $100/mes en hosting, sin cargos por asiento para el equipo de desarrollo y sin tarifas de transacción a nivel de plataforma en WooCommerce. Para una pequeña empresa, la diferencia es marginal. Para un equipo de marketing de 20 personas que gestiona un sitio de alto tráfico con múltiples colaboradores, los números cambian.

El Modelo de Precios por Asiento

El precio del workspace de Webflow cobra por asiento para editores y colaboradores por encima del nivel gratuito. Para agencias que gestionan sitios de clientes, este es un costo que se traslada. Para equipos internos donde múltiples partes interesadas necesitan acceso al CMS —gerentes de marketing regionales, revisores legales, colaboradores de contenido— el número de asientos se acumula. WordPress, en contraste, no tiene precios por asiento a nivel de plataforma; se paga por el hosting y cualquier plugin premium, pero agregar un editor de contenido no tiene costo alguno a nivel de plataforma.

El Bloqueo de Proveedor Es Real

Los sitios de Webflow no son portables de la misma manera que un sitio de WordPress. El diseño, la arquitectura del CMS y el hosting están todos vinculados a la plataforma de Webflow. Migrar implica reconstruir, no exportar. Esto no es exclusivo de Webflow —Squarespace y Wix tienen la misma característica— pero vale la pena mencionarlo explícitamente cuando un cliente está evaluando un compromiso de plataforma a cinco años. WordPress, con toda su complejidad, funciona sobre infraestructura estándar y puede migrarse entre hosts, frameworks y arquitecturas sin reconstruir desde cero.

En werun.dev, somos transparentes sobre esta compensación con cada cliente de Webflow. Para el perfil de proyecto adecuado —un sitio de marketing para una empresa B2B en etapa de crecimiento que necesita calidad de diseño, flexibilidad editorial y una huella de mantenimiento manejable— el bloqueo de Webflow es una compensación aceptable por las ganancias de productividad. Para un negocio que anticipa una evolución significativa de la plataforma, expansión multi-sitio o eventual migración a un stack personalizado, el costo del bloqueo merece un peso serio en la decisión de plataforma.

Lista de verificación del costo total de propiedad para Webflow:

• Nivel del plan de sitio de Webflow y tráfico proyectado
• Asientos de workspace para todos los colaboradores activos
• Herramientas de terceros necesarias para cubrir las brechas de Webflow (autenticación, formularios, búsqueda, comercio)
• Costo en tiempo de desarrollo para el mantenimiento de código personalizado
• Costo de migración si la decisión de plataforma necesita revisarse en 3 a 5 años

Si la respuesta honesta a esa lista de verificación produce un número que compite con una construcción correctamente mantenida en WordPress o Next.js personalizado, la decisión de plataforma debería reabrirse. Webflow se gana su lugar en los proyectos correctos. En los incorrectos, genera deuda técnica que se acumula silenciosamente hasta que una reconstrucción se vuelve inevitable.

Si estás evaluando Webflow para un proyecto y deseas una evaluación honesta sobre si se adapta a tus necesidades —o si un stack diferente te serviría mejor— ponte en contacto con el equipo de werun.dev. Trabajamos con Webflow, WordPress, Shopify y frameworks de front-end personalizados, y nuestra primera obligación es recomendar la herramienta correcta, no la que preferimos por conveniencia.