¿Por qué la mayoría de las empresas pagan de más por sus sitios web después de ponerlos en marcha?
Un sitio web puede tener un precio razonable al principio y, después, vaciar periódicamente el presupuesto de una empresa. No porque internet sea caro. A menudo sucede porque, al presupuestar el proyecto, todos se centran en poner el sitio en marcha y son muchos menos quienes se preguntan cuánto costará desarrollarlo, mantenerlo y modificarlo durante los años siguientes.
Imagina dos empresas. Ambas encargaron un sitio web con funcionalidades similares. La primera pagó más por su creación. La segunda eligió una oferta más barata.
Al cabo de un año, la primera actualiza los contenidos por su cuenta, añade nuevas páginas con facilidad y realiza cambios funcionales sin tener que reconstruir la mitad del sitio. La segunda contacta con el proveedor para cada modificación, espera un presupuesto y se pregunta por qué un cambio aparentemente sencillo cuesta lo mismo que un pequeño proyecto.
Después de tres años, la diferencia puede ser aún mayor. Al cabo de cinco años, el precio inicial puede tener poca importancia a la hora de determinar qué inversión resultó más rentable.
Por eso conviene ver un sitio web como un producto que evolucionará y cambiará junto con la empresa, y no como una compra puntual.
El precio de puesta en marcha no es el coste total del sitio web
Al encargar un sitio web, lo más fácil es comparar lo que aparece en la oferta: el diseño gráfico, el número de páginas, las funcionalidades, el plazo de entrega y el precio.
El problema es que la oferta suele describir, ante todo, el coste de crear la solución. No siempre muestra el coste total de tenerla durante los años siguientes.
En la práctica, hay que tener en cuenta, entre otras cosas:
-
el alojamiento, el dominio, los certificados y la infraestructura;
-
las actualizaciones del sistema, los complementos, las bibliotecas y los componentes;
-
el soporte técnico, la supervisión y la seguridad;
-
la corrección de errores y la adaptación del sitio a los cambios tecnológicos;
-
la incorporación de funciones, integraciones y nuevas páginas;
-
el trabajo de las personas responsables de los contenidos;
-
las pruebas de los cambios antes de publicarlos;
-
la posible migración a otro sistema o proveedor.
Estos son elementos del coste total de propiedad, conocido como TCO (Total Cost of Ownership). En el caso de un sitio web, no solo importa cuánto costó al principio, sino también cuánto dinero y tiempo consumirá durante todo el periodo de uso.
No todos los sitios web generarán todos los costes mencionados. Un sencillo sitio corporativo y un portal complejo con integraciones, un área de clientes o una tienda online tienen necesidades muy distintas. Sin embargo, el mecanismo es similar: las decisiones tomadas durante el diseño influyen en los gastos posteriores.
1. El coste de mantenimiento que nadie incluyó en el presupuesto
La vida de un sitio web no termina el día de su publicación. A partir de entonces comienza su mantenimiento.
Hay que ocuparse de las actualizaciones, la seguridad, las copias de seguridad, la disponibilidad, la compatibilidad con los navegadores y el correcto funcionamiento de los formularios y las integraciones. Según las tecnologías utilizadas, las obligaciones pueden ser pocas o bastante numerosas.
Tener alojamiento no significa que alguien supervise el sitio, responda a las averías y compruebe si las actualizaciones han causado problemas.
Los costes aumentan especialmente cuando el sitio depende de muchos complementos, componentes desactualizados o soluciones que nadie quiere tocar por miedo a provocar una avería.
En ese caso, una actualización aparentemente rutinaria puede requerir análisis, pruebas, correcciones y trabajo adicional de programación.
No se trata de que el mantenimiento del sitio sea gratuito. Se trata de que su alcance y coste sean conocidos, justificados y acordes con las necesidades reales.
2. Cada cambio cuesta más de lo que debería
Al principio, todo parece sencillo. La empresa quiere cambiar el orden de las secciones, añadir un nuevo servicio, rediseñar un formulario o integrar el sitio con un CRM.
Desde el punto de vista del negocio, es un cambio menor. Pero, desde el punto de vista técnico, puede resultar que haya que modificar varios componentes interdependientes, corregir soluciones que antes se implementaron a toda prisa y comprobar que el cambio no estropee algo en otra parte.
A veces, el problema se debe a la complejidad real de la función. No todos los cambios pueden ser baratos y rápidos. Pero otras veces, el origen de los costes está en cómo se diseñó y desarrolló el sitio.
Por ejemplo:
-
los contenidos están escritos directamente en el código en lugar de gestionarse desde un panel adecuado;
-
muchas páginas utilizan plantillas distintas e incoherentes;
-
un cambio visual requiere corregir numerosos lugares;
-
las integraciones no tienen reglas de funcionamiento claramente definidas;
-
nadie comprobó cómo afectaría la nueva función al resto del sitio.
En esas condiciones, la empresa no solo paga por la nueva función. También paga por superar las limitaciones de la solución anterior.
Hablamos más sobre este mecanismo en el artículo «¿Por qué cada vez cuesta más añadir una función nueva a una aplicación antigua?».
3. Vendor lock-in: cuando no puedes cambiar de proveedor libremente
Depender de un proveedor no siempre es un problema. Una colaboración a largo plazo con un equipo que conoce el sistema y se encarga de desarrollarlo puede ser una gran ventaja.
El problema aparece cuando la empresa no tiene una alternativa real.
Imagina que, después de dos años, quieres encargar el desarrollo del sitio a otra empresa. El nuevo proveedor solicita el repositorio del código, la documentación, el acceso a la infraestructura y una descripción de las integraciones. Resulta que parte de la información no existe, que solo el proveedor anterior tiene acceso al entorno y que hay elementos importantes basados en soluciones propias que nadie más conoce.
El nuevo equipo primero tiene que reconstruir el conocimiento del sistema. Solo después puede empezar a desarrollarlo.
Es un coste que no siempre aparece en el presupuesto inicial.
El vendor lock-in puede deberse a una plataforma cerrada, datos no transferibles, soluciones personalizadas, cláusulas contractuales, falta de acceso al código o simplemente falta de documentación. Por tanto, no es un problema exclusivo de una tecnología concreta.
Antes de firmar el contrato, conviene aclarar:
-
quién posee los derechos del código y de los demás elementos del proyecto;
-
si la empresa recibirá acceso al repositorio y a los entornos;
-
si los datos se pueden exportar en un formato útil;
-
cuáles son las condiciones para transferir el proyecto a otro proveedor;
-
si la documentación y la configuración estarán disponibles al finalizar la colaboración.
Una buena colaboración no debería exigir que el cliente quede atrapado tecnológicamente.
4. Falta de documentación. El conocimiento existe, pero solo en la cabeza de alguien
La documentación rara vez es el elemento más vistoso de un proyecto. No se ve en la página de inicio ni impresiona durante una presentación ante la dirección.
Pero su ausencia puede salir muy cara.
Si un nuevo desarrollador tiene que averiguar por su cuenta cómo funciona la integración, de dónde se obtienen los datos, qué dependencias existen entre los módulos y por qué se implementó una solución concreta de esa manera, la empresa paga por redescubrir conocimientos que deberían estar disponibles.
Esto no significa que cada sitio necesite cientos de páginas de documentación. El alcance debe corresponderse con la complejidad del proyecto.
En un sitio sencillo suelen bastar la información básica sobre el entorno, la configuración, el despliegue, las actualizaciones, las integraciones y la gestión de contenidos. En las soluciones más complejas también se necesita una descripción de la arquitectura, los flujos de datos, las dependencias y los procedimientos de emergencia.
La documentación no elimina todos los costes de los cambios. Sin embargo, reduce el tiempo necesario para comprender el sistema y disminuye el riesgo de que su desarrollo dependa de la disponibilidad de una persona concreta.
5. Falta de CMS. ¿Por qué pagas a un programador por cambiar un texto?
Si el sitio se desarrolla con regularidad y el equipo de negocio actualiza con frecuencia la oferta, añade proyectos realizados o publica artículos, la falta de un sistema de gestión de contenidos adecuado puede generar gastos innecesarios.
En ese caso, cada cambio se encarga al proveedor. Hay que describir la tarea, esperar a que la realice, comprobar el resultado y aprobar el trabajo.
Una actualización puntual puede parecer barata. Sin embargo, si se repite una docena o varias decenas de veces al año, los costes empiezan a acumularse. A esto se suman el tiempo de los empleados y los retrasos en la publicación de contenidos.
Un CMS permite gestionar por cuenta propia determinados elementos del sitio, pero solo si se ha diseñado correctamente. Un panel de administración por sí solo no garantiza la facilidad de uso. Si no es intuitivo, está limitado o requiere conocimientos técnicos para cada operación, el problema persiste.
También conviene recordar que el CMS no es obligatorio para todos los sitios. En un sitio sencillo cuyos contenidos cambian una vez al año, puede estar justificada otra solución. Lo importante es adaptar la tecnología al uso real que se hace del sitio.
Por tanto, la pregunta no es «¿el sitio tiene CMS?», sino «¿puede la empresa realizar con facilidad los cambios que debería poder hacer por su cuenta?».
6. Falta de pruebas. Un ahorro que puede aparecer de nuevo en la factura
A veces se considera que las pruebas son un extra que puede reducirse para ajustarse al presupuesto.
Es un enfoque arriesgado, sobre todo cuando el sitio gestiona ventas, formularios de contacto, pagos, cuentas de usuario o integraciones con otros sistemas.
Un cambio en un elemento puede afectar inesperadamente a otro. El formulario dejará de enviar consultas, una actualización dañará la vista móvil y una nueva versión de un componente cambiará el funcionamiento de la tienda.
Sin las pruebas adecuadas, los usuarios serán los primeros en detectar algunos problemas.
En ese caso, el coste no se limita a corregir el error. También puede incluir consultas perdidas, pedidos sin finalizar, interrupciones del servicio y trabajo adicional para el equipo.
No todos los sitios necesitan un conjunto amplio de pruebas automatizadas. Su alcance debe corresponderse con el riesgo y la complejidad de la solución. Sin embargo, incluso en proyectos más sencillos conviene comprobar, después de los cambios, los recorridos clave de los usuarios, los formularios, las vistas móviles y las integraciones más importantes.
En sitios más complejos, la automatización de las pruebas de regresión puede reducir el trabajo repetitivo y facilitar la implementación segura de nuevas versiones.
7. Deuda técnica. De pequeños atajos a grandes gastos
La deuda técnica surge cuando las decisiones tomadas hoy facilitan la entrega rápida de una solución, pero aumentan el coste de su mantenimiento o desarrollo posterior.
No toda implementación simplificada es un error. A veces se elige conscientemente una solución más sencilla porque es suficiente en una etapa determinada. El problema aparece cuando la empresa no comprende las consecuencias de esas decisiones o pospone indefinidamente las correcciones necesarias.
En un sitio web, la deuda técnica puede manifestarse en código duplicado, dependencias desactualizadas, componentes incoherentes, falta de pruebas, una arquitectura difícil de ampliar o integraciones cuyo funcionamiento solo conoce una persona.
Al principio, todo funciona. Con el tiempo, cada nueva funcionalidad requiere más trabajo y aumenta el riesgo de que los cambios provoquen efectos no deseados.
En cierto momento, la empresa debe elegir: seguir invirtiendo en reparar y desarrollar la solución existente o modernizarla.
Esto no siempre significa que haya que escribir el sitio desde cero. A menudo es más sensato reconstruir gradualmente los elementos más problemáticos. La decisión debe basarse en un análisis de los costes, los riesgos y los planes de desarrollo.
Encontrarás más información sobre este tema en el artículo «Tu aplicación tiene 5 años. ¿Sigue siendo apta para desarrollarse?».
¿Cuánto cuesta realmente un sitio web durante cinco años?
En lugar de comparar únicamente los precios de las ofertas, conviene preparar un modelo sencillo de costes para todo el periodo de uso previsto.
Para cada oferta, incluye:
-
Implementación: diseño, programación, configuración, migración de datos y puesta en marcha.
-
Mantenimiento: alojamiento, licencias, actualizaciones, monitorización, seguridad y asistencia técnica.
-
Desarrollo: cambios previstos, nuevas funciones, integraciones y ampliación de contenidos.
-
Costes operativos: tiempo de los empleados, tareas manuales y espera para que se realicen los cambios.
-
Riesgos y reparaciones: posibles fallos, correcciones, pruebas y trabajos imprevistos.
-
Cambio de proveedor o plataforma: traspaso del proyecto, migración, recuperación de conocimientos y posible reconstrucción.
Puede expresarse mediante una fórmula simplificada: Coste a 5 años = implementación + mantenimiento + desarrollo + trabajo operativo + reparaciones y riesgos + posible migración.
No todos los elementos pueden preverse con precisión. Por eso, conviene preparar varios escenarios: uno mínimo, uno realista y otro que contemple un mayor desarrollo del sitio. Al comparar ofertas, hay que tener en cuenta el mismo alcance funcional, un nivel de seguridad similar y las mismas condiciones de mantenimiento.
Solo entonces se puede evaluar de forma fiable qué oferta resulta más ventajosa a largo plazo.
¿Cómo reducir los costes antes de implementar el sitio?
No existe una tecnología que garantice automáticamente unos costes bajos durante cinco años. Sin embargo, es posible tomar decisiones que reduzcan el riesgo de gastos innecesarios.
En primer lugar: planifica el desarrollo. Aunque no conozcas todas las funciones futuras, define en qué dirección puede evolucionar la empresa. Un sitio que dentro de un año vaya a convertirse en una tienda o integrarse con un CRM debe diseñarse teniendo en cuenta ese escenario.
En segundo lugar: adapta la tecnología a las necesidades. No siempre necesitas el sistema más completo. Sin embargo, la opción más sencilla tampoco será siempre la más barata de mantener. Lo que importa son los requisitos, las competencias del equipo y la disponibilidad de asistencia.
En tercer lugar: establece las condiciones de propiedad y traspaso del proyecto. El acceso al código, los datos, las cuentas, la configuración y la documentación debe quedar definido desde el principio.
En cuarto lugar: garantiza la posibilidad de trabajar de forma autónoma. Si la empresa actualiza los contenidos con regularidad, debe disponer de herramientas cómodas y seguras para gestionarlos.
En quinto lugar: ten en cuenta las pruebas y el mantenimiento. No los trates como un complemento innecesario del proyecto. Son elementos que ayudan a reducir el riesgo de problemas costosos.
En sexto lugar: comprueba el coste de los cambios. Antes de firmar el contrato, pregunta cómo se presupuestarán los trabajos de desarrollo, qué incluye el soporte técnico y cómo se realizaría el traspaso del proyecto a otro equipo.
La web más barata no siempre es la inversión más económica
No todas las ofertas caras son malas. No todos los proyectos caros son buenos. No todas las webs necesitan un CMS avanzado, pruebas automatizadas y una arquitectura compleja.
Lo fundamental es que la solución responda a las necesidades de la empresa y que esté claro cómo se mantendrá y desarrollará.
Si la web va a ser solo una tarjeta de presentación sencilla, sus requisitos serán distintos de los de un sitio que genera leads a diario, atiende a clientes, vende productos y se integra con los sistemas de la empresa.
Sin embargo, el mayor error es tomar una decisión basándose únicamente en el precio inicial, sin comprobar qué incluye y qué consecuencias tendrán las soluciones aplicadas.
Una buena página web no tiene por qué ser la más cara desde el principio. También debe ser razonable en costes cuando haya que modificarla al cabo de un año, ampliarla después de tres años y seguir desarrollándola de forma segura al cabo de cinco.
En Web24 analizamos los proyectos web no solo desde la perspectiva de su implementación, sino también de su uso y desarrollo posteriores. Porque una web debe impulsar el negocio, no hacer que cada cambio posterior se convierta en un problema presupuestario aparte.
Así que, antes de comparar dos ofertas, hazte una pregunta más: ¿cuánto costará utilizar esta web durante los próximos cinco años?
A menudo, esto es mucho más importante que la diferencia de precio de la implementación en sí.
Glosario
-
TCO (Total Cost of Ownership) - coste total de propiedad de una solución durante un periodo determinado, que incluye no solo la compra o implementación, sino también la explotación y el desarrollo.
-
Vendor lock-in - dependencia de un proveedor que dificulta o encarece el cambio de proveedor o de tecnología.
-
CMS (Content Management System) - sistema de gestión de contenidos que permite a las personas autorizadas editar determinados elementos de la web sin modificar directamente el código.
-
Deuda técnica - coste futuro derivado de decisiones técnicas que aumentan la dificultad de mantener o desarrollar un sistema.
-
Pruebas de regresión - pruebas que comprueban que los cambios no hayan estropeado funciones que antes funcionaban correctamente.
-
Coste de migración - coste de trasladar una web, sus datos, configuración y conocimientos a otro entorno o sistema.
