Lo que cuesta realmente mantener un sitio web
Cualquiera que aloje sitios web para otras personas termina haciéndose la misma pregunta: ¿cuánto nos cuesta realmente un sitio? Parece un problema de contabilidad. En realidad es un problema de arquitectura, y casi todo el mundo lo responde mal en el primer intento.
El error habitual es dividir la factura de alojamiento entre la cantidad de sitios. Ese número es fácil de obtener y no dice casi nada, porque mezcla dos costos que se comportan de forma completamente distinta —y porque deja fuera varias partidas que con frecuencia son mayores que el alojamiento.
Dos cubetas, nunca una
Todo costo en un negocio de alojamiento cae en una de dos categorías, y mantenerlas separadas es toda la disciplina.
El costo fijo es lo que pagas antes de que llegue el primer cliente. Tus servidores de aplicación, tu base de datos, tu monitoreo, tus herramientas de gestión de servidores, tu proveedor de correo transaccional. Si mañana tuvieras cero clientes, seguirías pagándolo. No se mueve cuando agregas un sitio.
El costo marginal es lo que agrega un sitio adicional. Una porción de un servidor compartido, la comisión del procesador de pagos sobre la suscripción de ese cliente, el ancho de banda que consumen sus visitantes.
El costo por sitio no es un número. Es:
costo por sitio = costo fijo / cantidad de sitios + costo marginal por sitio
El primer término se desploma a medida que creces. El segundo no. Lo que significa que el costo por sitio no es una propiedad de tu arquitectura, sino de tu escala. Al principio, el primer término domina de tal manera que el segundo es ruido. Una plataforma con $1,500 mensuales de costo fijo y ocho clientes paga casi $190 por sitio, sin importar lo eficiente que sea el alojamiento.
Por eso «costo por sitio» citado sin una cantidad de sitios no significa nada, y por eso optimizar el segundo término suele ser prematuro mientras el primero siga siendo grande.
Las partidas que se olvidan
El costo marginal es donde viven las sorpresas. Una lista razonablemente completa:
- La porción de alojamiento — el servidor donde corre el sitio, dividido entre cuántos sitios lo comparten
- El procesamiento de pagos — habitualmente ~2.9% más una comisión fija por transacción
- Ancho de banda y solicitudes de CDN — a menudo gratis con poco volumen, rara vez gratis para siempre
- Correo transaccional — restablecimiento de contraseñas, notificaciones, recibos
- Generación de contenido — si la IA escribe el contenido inicial, esos tokens son un costo real por única vez
- Registro de dominio — normalmente se traslada al cliente, pero conviene revisar si absorbes el primer año
- Respaldos — el almacenamiento de snapshots suele facturarse como porcentaje de la instancia
- Aprovisionamientos fallidos — los sitios creados y abandonados también consumieron recursos
El que más sorprende es el procesamiento de pagos. En una suscripción de precio bajo con frecuencia supera al alojamiento. A $20 mensuales, los $0.30 fijos ya representan el 1.5% del ingreso, y la comisión porcentual lleva el total a cerca del 4.4%. Si tu porción de alojamiento es de uno o dos dólares —como debería serlo en cualquier servidor razonablemente ocupado—, entonces tu procesador de pagos te cuesta más que tu infraestructura.
Vale la pena detenerse en esa inversión, porque indica dónde corresponde poner el esfuerzo de optimización. Reducir a la mitad el costo de alojamiento quizá te ahorre unos centavos por sitio. Mover a un cliente a un plan de mayor precio cambia la aritmética por completo.
Dos arquitecturas, dos curvas de costo
Aquí la contabilidad deja de ser genérica, porque la forma en que alojas determina la forma de ambos términos.
El modelo estático
Generas el sitio una vez como HTML, CSS, imágenes y JavaScript planos. Lo subes a almacenamiento de objetos. Lo sirves a través de una CDN. No hay servidor de aplicación, ni base de datos, ni un proceso de PHP o Node ejecutándose en cada solicitud.
La economía es excepcional. El costo marginal se aproxima únicamente al almacenamiento y al ancho de banda: fracciones de centavo por sitio al mes. No hay servidor que dimensionar, ni grupo de procesos que agotar, ni base de datos por sitio. Diez mil sitios cuestan aproximadamente diez mil veces casi nada. Escala de forma casi lineal y sus modos de falla son benignos: tumbar un nodo de CDN es mucho más difícil que tumbar un servidor de aplicación.
Lo que se cede es todo aquello que requiere ejecutar código cuando llega un visitante.
Un sitio estático no puede procesar un formulario por sí solo. No puede tomar una reserva, emitir una factura, consultar disponibilidad, mantener una sesión, buscar dentro de su propio contenido ni mostrar algo distinto según el visitante. Cada una de esas capacidades necesita un backend en alguna parte —así que en la práctica las plataformas estáticas o bien acoplan servicios de terceros para cada función, o bien operan una aplicación aparte con la que los sitios estáticos conversan. Esa aplicación es un costo fijo, y reintroduce en silencio buena parte de lo que el modelo estático pretendía evitar.
La otra restricción es la edición. Si un comerciante cambia su horario de atención, algo tiene que regenerar y volver a desplegar las páginas afectadas. Ese proceso es infraestructura en sí mismo, y su costo y complejidad crecen según qué tan granulares e inmediatas quieras que se sientan las ediciones.
El modelo con aplicación
Cada sitio corre como una aplicación real: un servidor web, un intérprete del lenguaje, una base de datos o capa de contenido, ejecutándose en cada solicitud.
El costo marginal es genuinamente mayor. Los sitios consumen memoria y CPU, no solo disco. La densidad está limitada por la concurrencia y no por el almacenamiento: lo que te restringe es cuántas solicitudes puedes atender simultáneamente, que es función de la memoria por proceso, la caché de código y la CPU. Un sitio que ocupa cien megabytes de disco puede necesitar bastante más RAM bajo carga, y los servidores se dimensionan para el pico, no para el promedio.
La compensación es que todo lo que un pequeño negocio realmente quiere ya es posible. Los formularios se envían. Las reservas se guardan en una base de datos. Las facturas se generan. El contenido se edita en el lugar y queda publicado de inmediato, porque no hay nada que reconstruir. La búsqueda funciona. Las sesiones existen. Agregar una capacidad es código de aplicación, no una dependencia externa más con su integración por mantener.
Existe además un camino intermedio que conviene conocer: una plataforma basada en aplicación puede cachear de forma tan agresiva que la mayoría de las solicitudes nunca ejecuten código. Con caché de página completa —en la aplicación o en el borde— el visitante típico recibe una respuesta almacenada, y el intérprete solo interviene en las solicitudes que realmente lo necesitan. Eso recupera buena parte de la eficiencia del modelo estático sin renunciar a la capacidad. No es gratis: la invalidación de caché es un problema de ingeniería real, y una caché mal configurada puede consumir mucho más almacenamiento que los propios sitios. Pero reduce la brecha de forma sustancial.
Por qué el código de backend es una decisión de negocio, no técnica
Es tentador tratar esto como una disyuntiva puramente técnica. No lo es. La presencia o ausencia de un backend determina qué puedes vender, y a quién.
Para el comerciante, un backend es la diferencia entre un folleto y una herramienta. Un restaurante que puede tomar reservas, una clínica que puede gestionar turnos, una empresa de oficios que puede emitir un presupuesto: eso es lo que convierte al sitio web en parte de cómo funciona el negocio, en lugar de una obligación que se mantiene. Los negocios abandonan los folletos. Rara vez abandonan algo de lo que depende su semana.
Para la plataforma, la capacidad es lo que sostiene el precio. Un folleto estático compite por precio contra todos los demás folletos, y esa es una carrera con final conocido. Una plataforma que administra las reservas, las facturas o los registros de clientes del comerciante ofrece algo con costos de cambio, y puede cobrar en consecuencia. Ese precio mayor es lo que después paga la infraestructura que lo hizo posible —y ese es justamente el punto que hace funcionar todo el modelo.
Esta es la versión honesta de la disyuntiva, y conviene enunciarla sin fingir que una arquitectura simplemente gana:
El alojamiento estático optimiza la línea de costo. El alojamiento con aplicación optimiza la línea de ingreso.
A $10 mensuales, el costo marginal importa enormemente y lo estático es probablemente la única estructura viable. A $30 o $80, el costo marginal es un error de redondeo frente a los costos fijos y de desarrollo, y la restricción pasa a ser qué puedes ofrecer, no qué puedes permitirte operar. La arquitectura debería seguir al precio, y no al revés.
Cómo hacer el cálculo
Un método aplicado, con números ilustrativos:
1. Suma tu costo fijo mensual. Cada servidor que no sea alojamiento de clientes, más cada suscripción: herramientas de gestión, monitoreo, correo, seguimiento de errores. Supongamos que da $1,000 al mes.
2. Calcula tu porción de alojamiento. Toma el costo mensual de un servidor de clientes y divídelo entre cuántos sitios aloja con holgura —medido bajo carga real, no estimado. Un servidor de $40 con 20 sitios son $2.00 por sitio. Sé honesto aquí: un servidor que técnicamente admite 50 sitios pero se degrada con 20, admite 20.
3. Agrega el resto de los costos marginales. Procesamiento de pagos sobre tu precio real, CDN más allá del nivel gratuito, volumen de correo por sitio.
4. Combina.
costo por sitio (con N sitios) = $1,000 / N + marginal
5. Encuentra tu punto de equilibrio. La cantidad de sitios en que el ingreso cubre todo:
N = costo fijo total / (precio − costo marginal por sitio)
Con $1,000 de costo fijo, un precio de $30 y $2 de marginal, son 36 sitios. Agrega $250 mensuales de costo fijo nuevo —una herramienta más, un servidor más— y el equilibrio se mueve a 45. Cada costo fijo que agregas tiene un precio denominado en clientes, y esa es una forma mucho más útil de evaluar una suscripción que su cifra mensual.
6. Después incluye el desarrollo por separado. Lo que gastas construyendo el producto no es un costo de atender a un cliente, y meterlo dentro del costo por sitio hará que un producto sano parezca no rentable. Llévalo como su propia línea. Cambia cuándo te autofinancias; no cambia lo que cuesta un sitio.
La conclusión a la que casi todos llegan tarde
Haz este ejercicio con honestidad y normalmente arroja el mismo hallazgo: la infraestructura no es donde se va el dinero.
Para la mayoría de las plataformas en la mayoría de las etapas, el desarrollo y la nómina superan al alojamiento por un orden de magnitud, y el costo fijo dividido entre una base pequeña de clientes supera al costo marginal por otro orden más. Un fin de semana dedicado a abaratar un 30% el alojamiento quizá ahorre unos dólares al mes. Ese mismo fin de semana dedicado a lo que suma diez clientes cambia el negocio.
No es un argumento a favor de la infraestructura derrochadora. Vale la pena tener alojamiento eficiente, vale la pena diseñar temprano una economía unitaria que funcione a escala, y una plataforma que no puede atender a sus clientes de forma confiable no tiene economía alguna. Pero sí es un argumento para saber qué número estás optimizando realmente —y para calcular el costo por sitio como corresponde, de modo que puedas descubrir cuál es.