El costo oculto de toda plataforma web: hosting, mantenimiento y deuda técnica

El costo oculto de toda plataforma web: hosting, mantenimiento y deuda técnica

Cuando una empresa elige una plataforma web, la conversación casi siempre gira en torno al costo de desarrollo. ¿Cuánto cuesta el diseño? ¿Cuánto el desarrollo? ¿Cuándo será el lanzamiento? Estos son los números visibles — los que aparecen en las propuestas y se aprueban en las reuniones de presupuesto. Lo que rara vez llega a una hoja de cálculo es todo lo que viene después: la infraestructura de hosting continua, la carga de mantenimiento y la acumulación gradual de deuda técnica que puede duplicar o triplicar silenciosamente el costo total de propiedad a lo largo de un período de tres a cinco años.

Este artículo desglosa los costos reales y continuos de las tres plataformas con las que más trabajamos — WordPress, Webflow y Shopify — y explica cómo evaluarlos con honestidad antes de comprometerse con un desarrollo.

WordPress: Poderoso, pero el Costo de Propiedad Recae Sobre Ti

WordPress impulsa alrededor del 43% de todos los sitios web en internet, y con razón. La plataforma es extraordinariamente flexible, cuenta con un ecosistema de plugins maduro y otorga a los desarrolladores control total sobre cada capa del stack. Sin embargo, esa flexibilidad conlleva una responsabilidad que muchos clientes no contemplan completamente al inicio: tú eres dueño de la infraestructura y de las consecuencias.

Los Costos de Hosting No Son un Commodity

El hosting de WordPress oscila entre £3/mes en un servidor compartido hasta £500+/mes para hosting administrado empresarial. Esa diferencia no es arbitraria — refleja diferencias reales en rendimiento, postura de seguridad y calidad del soporte. Un sitio que funciona en hosting compartido económico se comportará como tal: Time to First Byte lento, sin caché del lado del servidor, memoria PHP limitada y equipos de soporte que no pueden ayudar con problemas a nivel de aplicación.

Para sitios empresariales serios, el piso realista para hosting administrado de WordPress ronda las £30–£80/mes en plataformas como WP Engine o SiteGround — ambas con las que nos asociamos en werun.dev. En ese nivel, se obtienen entornos de staging, copias de seguridad automatizadas, integración con CDN y caché a nivel de servidor. Para sitios de alto tráfico o tiendas WooCommerce, se habla de £150–£400/mes antes de haber escrito una sola línea de código.

El Mantenimiento de Plugins Es una Preocupación Constante

El ecosistema de plugins de WordPress es una de sus mayores fortalezas y una de sus responsabilidades más persistentes. Un sitio WordPress típico ejecuta entre 15 y 30 plugins. Cada uno es una dependencia. Cada dependencia tiene un ciclo de lanzamiento, un historial de seguridad y una matriz de compatibilidad con cada otro plugin y con el propio núcleo de WordPress.

Sin gestión, los plugins se deterioran. Un plugin que era seguro y compatible al momento del lanzamiento puede convertirse en un vector de vulnerabilidad en seis meses si deja de recibir actualizaciones. El equipo de seguridad de WordPress reveló más de 2.800 vulnerabilidades de plugins solo en 2023. Esto no es una razón para evitar WordPress — es una razón para tomar el mantenimiento en serio.

En werun.dev, cada plugin de WordPress que desarrollamos incluye un sistema de actualización automática basado en GitHub, para que el código personalizado se mantenga actualizado sin intervención manual. Sin embargo, los plugins de terceros aún requieren supervisión humana. Por eso ofrecemos retenciones de mantenimiento mensual que cubren:

  • Actualizaciones del núcleo, tema y plugins con pruebas de compatibilidad
  • Escaneo de seguridad y monitoreo de malware
  • Auditorías de rendimiento contra los benchmarks de Core Web Vitals
  • Optimización de base de datos y gestión de registros
  • Monitoreo de disponibilidad con respuesta a incidentes

Deuda Técnica en WordPress

La deuda técnica en WordPress generalmente se acumula de tres maneras. Primero, la personalización de temas mediante child themes o ediciones directas que se sobreescriben en las actualizaciones. Segundo, la proliferación de plugins — instalar cinco plugins para resolver un problema que un plugin personalizado bien escrito podría manejar de forma limpia. Tercero, los atajos tomados durante el desarrollo original: cadenas de texto codificadas directamente que rompen la internacionalización, consultas directas a la base de datos en lugar de la WP Query API, o verificaciones de capacidad faltantes que crean riesgos de escalada de privilegios.

Un sitio construido según los estándares de codificación de WordPress — usando hooks y filters correctamente, registrando endpoints de la REST API de forma adecuada, saneando y escapando toda la salida — es significativamente más económico de mantener que uno construido de forma rápida y barata. La diferencia no se manifiesta en el lanzamiento, sino en cada hora de trabajo de desarrollo posterior. Cuando un desarrollador debe invertir dos horas en entender lo que hizo un desarrollador anterior antes de poder realizar un cambio de una línea, eso es deuda técnica pagándose con intereses.

El modelo de costos real para WordPress a lo largo de tres años en un sitio empresarial de complejidad media se ve aproximadamente así:

  • Hosting: £1.200–£4.800
  • Retención de mantenimiento: £2.400–£7.200
  • Correcciones de emergencia no planificadas (sin retención): £800–£3.000
  • Renovaciones de licencias de plugins: £300–£1.500
  • Costo total a tres años: £4.700–£16.500+

Nada de esto aparece en una cotización de desarrollo.

Webflow: Menor Carga Operativa, pero el Bloqueo de Plataforma Es Real

Webflow tiene una estructura de costos fundamentalmente diferente a WordPress. Dado que Webflow es una plataforma SaaS alojada, la capa de infraestructura queda abstraída. No se gestionan servidores, no se parchea PHP y no hay que preocuparse por si el proveedor de hosting habilitó HTTP/2. Webflow se encarga de todo eso, y lo hace bien — la plataforma funciona sobre AWS y el CDN de Fastly, y el rendimiento de fábrica es genuinamente sólido.

Esto hace que Webflow sea atractivo para sitios de marketing y propiedades con mucho contenido donde la preocupación principal es la velocidad editorial y la fidelidad de diseño, no la personalización a nivel de aplicación. La carga operativa es menor, pero no desaparece — y el modelo de costos tiene sus propias capas ocultas.

Precios de Webflow: Lo que Realmente Incluyen los Planes

Los precios de Webflow están basados en planes y escalan según la complejidad del sitio y el tráfico. Al momento de escribir este artículo, los niveles relevantes para sitios empresariales son:

  • Basic: ~£14/mes — sin CMS, limitado para cualquier sitio con contenido real
  • CMS: ~£23/mes — hasta 2.000 elementos de CMS, adecuado para blogs pequeños o sitios de marketing
  • Business: ~£36/mes — hasta 10.000 elementos de CMS, mayor cantidad de envíos de formularios
  • Enterprise: precio personalizado — SSO, SLA, seguridad avanzada

Para e-commerce, Webflow agrega una capa separada de tarifas de transacción en los planes inferiores (2% en el plan Standard, reduciéndose a 0% en Plus y Advanced). Una marca DTC en crecimiento en el plan Standard a £29/mes más el 2% de tarifas de transacción sobre £50.000/mes en ingresos está pagando efectivamente £1.000/mes en costos de plataforma — antes del hosting, antes del desarrollo.

Más allá del costo del plan, los proyectos serios en Webflow frecuentemente requieren herramientas de terceros para cubrir brechas de funcionalidad. Las membresías y el contenido restringido requieren Memberstack u Outseta. La búsqueda avanzada requiere Finsweet o Jetboost. El soporte multiidioma requiere Weglot (£99–£490/año según el recuento de palabras). Estos costos son reales y recurrentes.

El Perfil de Mantenimiento Es Diferente, No Inexistente

Los sitios en Webflow no necesitan actualizaciones de plugins ni parches de servidor, pero sí requieren atención continua. Una arquitectura de CMS que no fue diseñada para escalar se vuelve difícil de gestionar a medida que crece el volumen de contenido. Las interacciones con JavaScript personalizado — particularmente animaciones con GSAP o integraciones con la API de Webflow — pueden romperse cuando Webflow actualiza su Designer o cambia el comportamiento de sus embeds. Las convenciones de nomenclatura de clases que no se establecieron al momento del desarrollo crean una hoja de estilos desordenada que ralentiza cada cambio de diseño posterior.

En werun.dev, nuestros desarrollos en Webflow utilizan arquitectura de clases estilo BEM y colecciones de CMS estructuradas diseñadas para flujos de trabajo editoriales, no solo para el lanzamiento inicial. Esa inversión en estructura se traduce en menores costos de mantenimiento durante la vida útil del sitio. Un sitio en Webflow construido sin esa disciplina puede volverse genuinamente costoso de modificar — no porque la plataforma sea difícil, sino porque la implementación lo es.

Deuda Técnica en Webflow

El editor visual de Webflow facilita la construcción rápida, y esa velocidad puede enmascarar problemas estructurales. Las fuentes comunes de deuda técnica en proyectos de Webflow incluyen:

  • Uso excesivo de combo classes: Aplicar múltiples clases a un solo elemento para lograr un estilo único, en lugar de crear un componente reutilizable. Esto genera una lista de clases imposible de gestionar a escala.
  • Colecciones de CMS sin estructura: Colecciones creadas de forma reactiva a medida que surgen necesidades de contenido, en lugar de diseñarse desde el inicio para soportar el modelo editorial completo. Refactorizar la arquitectura del CMS en Webflow es costoso y disruptivo.
  • Embeds de código personalizado sin documentación: JavaScript agregado mediante bloques de embed que nadie documentó, que nadie comprende completamente y que falla silenciosamente cuando la API de terceros que invoca cambia su esquema.
  • Sin disciplina de staging: Realizar ediciones en vivo directamente en un sitio Webflow publicado porque nunca se estableció el flujo de trabajo para usar staging correctamente.

El modelo de costos a tres años para un sitio de marketing en Webflow de complejidad media:

  • Plan de plataforma: £828–£1.296
  • Herramientas de terceros (Memberstack, Weglot, etc.): £600–£2.400
  • Retención de mantenimiento: £1.800–£5.400
  • Trabajo de rediseño no planificado por deuda estructural: £1.000–£4.000
  • Costo total a tres años: £4.228–£13.096+

Shopify: Predecible Hasta que Deja de Serlo

Shopify es la más opinionada de las tres plataformas, y esa opinión forma parte de su valor. La plataforma toma un conjunto de decisiones por ti — sobre el checkout, el procesamiento de pagos, la gestión de inventario — y a cambio obtienes un sistema genuinamente optimizado para el comercio minorista a escala. Para marcas DTC directas y e-commerce B2C, el modelo de costos de Shopify es relativamente predecible.

Para escenarios B2B complejos, operaciones mayoristas de alto volumen o empresas con lógica de fulfillment no estándar, el modelo de costos se vuelve considerablemente menos predecible — y la deuda técnica se acumula de maneras específicas a la arquitectura de Shopify.

El Impuesto del Ecosistema de Apps

El ecosistema de apps de Shopify es su característica más poderosa y su principal generador de costos continuos. La funcionalidad central de la plataforma es intencionalmente reducida. La mayoría de las tiendas reales necesitan apps para gestionar suscripciones, programas de fidelización, filtrado avanzado de productos, precios de paquetes, precios mayoristas B2B, lógica de envío personalizada y sistemas de reseñas. Cada una de estas apps tiene una tarifa mensual, que generalmente oscila entre £10 y £150+/mes por app.

Una tienda Shopify de complejidad media que ejecuta entre 8 y 12 apps está pagando £80–£600/mes en tarifas de apps antes del costo del propio plan de Shopify. El plan Business es £65/mes. Shopify Plus comienza en £2.000/mes. Sumando las tarifas de transacción (0,5–2% según el plan y la pasarela de pago), el costo mensual de plataforma para una marca en crecimiento puede alcanzar £3.000–£5.000 antes de cualquier trabajo de desarrollo.

La proliferación de apps también genera deuda técnica. Cada app inyecta su propio JavaScript, CSS y fragmentos de Liquid en el tema. Con el tiempo, esto crea:

  • Aumento del peso de página: Múltiples apps cargando sus propios paquetes de recursos, frecuentemente de forma redundante
  • Conflictos en el checkout: Apps que modifican el comportamiento del checkout entrando en conflicto entre sí o con el propio sistema de extensibilidad de checkout de Shopify
  • Bloqueo de tema: Un tema tan modificado por las inyecciones de apps que actualizar o cambiar de tema requiere una auditoría y reconstrucción completa

Costos de Tema y Desarrollo Personalizado en Shopify

Los temas de Shopify van desde gratuitos hasta £300+ para opciones premium en el Theme Store. El desarrollo de temas personalizados para Shopify — construir desde cero o modificar extensamente un tema adquirido — típicamente cuesta entre £5.000 y £25.000 según la complejidad. Ese es un costo único, pero crea un compromiso de mantenimiento a largo plazo.

El lenguaje de plantillas Liquid de Shopify no es difícil, pero es propietario. Los desarrolladores que conocen bien Liquid cobran una prima, y el grupo de desarrolladores de Shopify genuinamente capacitados es más pequeño que el equivalente de WordPress. Cuando un tema personalizado necesita modificación — para soportar un nuevo tipo de producto, mejorar los puntajes de Core Web Vitals o adaptarse a los requisitos de una nueva app — la tarifa por hora refleja esa escasez.

Deuda Técnica Específica de Shopify

La forma más insidiosa de deuda técnica en Shopify es la dependencia del checkout. Shopify controla la experiencia de checkout, y las opciones de personalización — incluso en Plus — están limitadas por lo que permite Checkout Extensibility. Las empresas que han construido procesos operativos en torno a comportamientos específicos del checkout pueden encontrarse incapaces de actualizar versiones de Shopify o adoptar nuevas funcionalidades sin reconstruir esos procesos.

El sistema de metafields, introducido para reemplazar las apps de metafields anteriores, es poderoso pero requiere una implementación disciplinada. Los metafields definidos de forma inconsistente en productos, colecciones y páginas crean un modelo de datos difícil de consultar, difícil de mostrar condicionalmente y costoso de migrar si la tienda alguna vez adopta una arquitectura headless.

El modelo de costos a tres años para una tienda Shopify de complejidad media:

  • Plan de plataforma: £2.340–£72.000 (Basic a Plus)
  • Tarifas de apps: £2.880–£21.600
  • Desarrollo y actualizaciones de tema: £3.000–£15.000
  • Trabajo de desarrollo personalizado: £2.000–£10.000
  • Costo total a tres años: £10.220–£118.600+

El rango de Plus es amplio porque el precio de Shopify Plus se negocia y escala con el GMV. Los comerciantes de alto volumen pagan significativamente más.

Cómo Evaluar el Costo Total de Propiedad Antes de Desarrollar

La decisión de plataforma nunca debe tomarse basándose únicamente en el costo de desarrollo. Un desarrollo en WordPress de £15.000 con una retención de mantenimiento de £400/mes tiene un TCO a tres años menor que un desarrollo en Webflow de £8.000 que acumula £20.000 en deuda estructural y requiere una reconstrucción completa en el segundo año. Los números que importan son los que se extienden a lo largo del ciclo de vida completo del sitio.

Las Preguntas que Revelan los Costos Ocultos

Antes de comprometerse con una plataforma, estas preguntas deben responderse explícitamente:

Sobre hosting e infraestructura:

  • ¿Quién es responsable de los parches de seguridad a nivel de servidor?
  • ¿Cuál es el plan de recuperación ante desastres y cuánto cuesta activarlo?
  • ¿El costo de hosting es fijo o escala con el tráfico de maneras que podrían generar facturas inesperadas?
  • ¿Qué sucede con el sitio si el proveedor de la plataforma cambia sus precios o discontinúa un nivel de plan?

Sobre mantenimiento:

  • ¿Cuántas dependencias de terceros requiere este desarrollo y cuál es su costo anual combinado de licencias?
  • ¿Cuál es el proceso para probar las actualizaciones antes de que entren en producción?
  • ¿Quién monitorea la disponibilidad y cuál es el SLA de respuesta a incidentes?
  • ¿Existe documentación para cada integración personalizada, o el conocimiento está bloqueado en la mente del desarrollador original?

Sobre deuda técnica:

  • ¿El código base está escrito según los estándares publicados de la plataforma, o siguiendo el camino más rápido hacia el lanzamiento?
  • ¿Existen pruebas automatizadas para los flujos de usuario críticos?
  • ¿La arquitectura del CMS está diseñada para el flujo de trabajo real del equipo editorial, o para la conveniencia del desarrollador?
  • ¿Cuánto costaría migrar este sitio a una plataforma diferente en tres años si las necesidades del negocio cambian?

La Retención de Mantenimiento como Seguro

Uno de los patrones más consistentes que observamos en werun.dev es el de clientes que rechazaron una retención de mantenimiento al momento del lanzamiento y luego gastaron entre dos y cuatro veces el costo de la retención en correcciones de emergencia dentro de los primeros dieciocho meses. Una retención no es una venta adicional — es el mecanismo mediante el cual se previene la acumulación de deuda técnica desde el principio.

Para WordPress, una retención cubre el ciclo de actualizaciones, el monitoreo de seguridad y el mantenimiento de rendimiento que la plataforma requiere para mantenerse saludable. Para Webflow, cubre revisiones de arquitectura del CMS, auditorías de código personalizado y las mejoras iterativas que mantienen al sitio alineado con el negocio a medida que crece. Para Shopify, cubre las pruebas de compatibilidad de apps, el mantenimiento del tema y el trabajo de optimización continua que evita que las tasas de conversión se deterioren a medida que la tienda escala.

El costo de la retención es predecible. El costo de no tenerla no lo es.

La Adecuación a la Plataforma Reduce el Costo a Largo Plazo

La forma más efectiva de reducir el costo total de propiedad es elegir la plataforma correcta para el caso de uso real. Un sitio de marketing con mucho contenido que necesita flujos de trabajo editoriales ágiles y alta fidelidad de diseño está bien servido por Webflow — y acumulará menos deuda allí que en una instalación de WordPress que requiere gestión constante de plugins para funcionalidades que Webflow maneja de forma nativa. Un desarrollo complejo de WooCommerce con lógica de precios personalizada, integración con ERP y funcionalidad mayorista pertenece a WordPress, donde la arquitectura de plugins y la REST API otorgan a los desarrolladores el control que necesitan sin luchar contra la plataforma.

La adecuación a la plataforma no se trata de cuál plataforma es objetivamente la mejor. Se trata de qué restricciones de la plataforma se alinean con los requisitos del proyecto — porque toda plataforma tiene restricciones, y el costo de luchar contra esas restricciones siempre es mayor que el costo de trabajar dentro de ellas.

En werun.dev, cada proyecto comienza con una recomendación de plataforma basada en el modelo editorial del cliente, los requisitos de integración, la trayectoria de crecimiento y la capacidad técnica interna. El costo de desarrollo es un factor en esa recomendación. El costo total de propiedad a tres años es otro — y siempre es el más importante.