10 errores que cometen los empresarios al encargar el desarrollo de una página web

Solo cerca del 31 % de los proyectos tecnológicos cumple plazo, presupuesto y alcance fijados. La mayoría de las causas surge antes de la primera línea de código: los diez errores más comunes y cómo evitarlos.

El desarrollo de un sitio web es una de esas inversiones que puede acelerar notablemente el crecimiento de una empresa o convertirse en una experiencia cara y frustrante que termina con un resultado que no responde a las expectativas, supera el presupuesto y exige rehacerlo al cabo de unos pocos meses. Las estadísticas del sector son preocupantes: solo alrededor del 31% de los proyectos tecnológicos se completan a tiempo, dentro del presupuesto y conforme al alcance definido inicialmente, y los proyectos de desarrollo web no son una excepción en este sentido, porque el desarrollo web entra dentro de esa misma estadística: el resto de los proyectos, aproximadamente dos tercios, se clasifican como «en riesgo» (presupuesto o plazo superado, alcance reducido) o como fallidos. Sin embargo, la mayoría de estos fracasos no se deben a carencias tecnológicas ni a la incompetencia de los desarrolladores: son consecuencia de factores humanos y organizativos que aparecen antes incluso de escribir la primera línea de código, y se pueden evitar por completo si el empresario sabe qué errores se cometen con más frecuencia y cómo esquivarlos.

En este artículo repasaremos los diez errores más frecuentes que cometen los empresarios y las organizaciones al encargar el desarrollo de un sitio web y, en cada uno de ellos, explicaremos por qué se produce, cuáles son sus consecuencias y qué puede hacer usted para evitarlo.

1. Tomar la decisión basándose únicamente en el precio

Este es probablemente el error más extendido y más caro que cometen los empresarios al encargar el desarrollo de un sitio web: comparan varias ofertas y eligen la más barata, convencidos de que un sitio web es un sitio web con independencia de quién lo desarrolle y de que la diferencia entre una oferta de 500 euros y otra de 5000 euros es solo el margen de beneficio del desarrollador. En realidad, esa diferencia refleja casi siempre diferencias fundamentales en la calidad del desarrollo, la limpieza del código, el nivel de seguridad, la capacidad de escalado y el soporte posventa, y la oferta más barata acaba siendo a menudo, a largo plazo, la solución más cara, porque un código de mala calidad genera la llamada «deuda técnica»: una acumulación de problemas que exige correcciones constantes, limita la evolución del sitio y termina obligando a reconstruirlo todo desde cero.

Las ofertas de precio bajo esconden a menudo riesgos considerables: el desarrollador puede utilizar temas gratuitos o pirateados que contienen vulnerabilidades de seguridad o código malicioso oculto; el código puede estar sin optimizar y sin estructurar, lo que vuelve complicado y caro el mantenimiento y la ampliación posteriores; puede que no se realicen pruebas suficientes, lo que significa que los fallos se detectarán solo después de la puesta en marcha; y el soporte posventa puede ser mínimo o inexistente, lo que le deja sin ayuda en el momento en que más la necesita. El enfoque correcto consiste en valorar las ofertas no por su precio, sino por su valor: examinar el portfolio del desarrollador, hablar con sus clientes anteriores, comprobar la calidad técnica de los sitios que ha desarrollado y entender con claridad qué incluye exactamente el precio y qué no, porque con frecuencia la oferta «barata» no contempla elementos que en la oferta «cara» son estándar, como el diseño responsive, la optimización SEO básica, la configuración de seguridad o la formación de los editores para trabajar con el sitio.

2. Requisitos y objetivos definidos de forma imprecisa

El segundo error más frecuente es poner en marcha el proyecto sin unos requisitos, objetivos y resultados esperados claramente definidos: el empresario se pone en contacto con el desarrollador y dice algo parecido a «necesito un sitio web moderno y profesional», sin ser capaz de concretar qué funciones necesita el sitio, cuál es el público objetivo, qué acciones deberían realizar los visitantes en él y cómo se medirá su éxito. Esa imprecisión crea una situación en la que el desarrollador se ve obligado a hacer sus propias suposiciones sobre lo que quiere el cliente, y esas suposiciones resultan ser erróneas a menudo, lo que provoca decepción en ambas partes y obliga a rehacer el trabajo ya realizado, con el consiguiente gasto adicional de tiempo y dinero. Esa imprecisión es el principal motor de la «expansión del alcance» (scope creep), un fenómeno que afecta a más de la mitad de todos los proyectos del sector y que consiste en que, durante el proyecto, se añaden continuamente nuevas funciones y requisitos que no estaban incluidos en el plan inicial, lo que incrementa los costes entre un 10% y un 25% y a menudo alarga también considerablemente los plazos de desarrollo.

La solución es invertir tiempo y esfuerzo en la fase de investigación previa (discovery phase) antes de iniciar cualquier desarrollo: en esta etapa se definen objetivos de negocio concretos (por ejemplo, aumentar el número de solicitudes en un 30%, reducir la tasa de rebote por debajo del 40%, conseguir una duración media de sesión superior a 3 minutos), se elaboran las personas de usuario, se trazan los recorridos de usuario, se determinan la estructura del sitio y los requisitos de funcionalidad, y se redacta una especificación técnica detallada que sirve como documento de referencia a lo largo de todo el proyecto. La existencia de ese documento protege a ambas partes: el empresario sabe qué recibirá por su dinero y el desarrollador sabe qué se espera de él, y cualquier cambio que exceda el alcance fijado en el documento se formaliza como trabajo adicional, con su propio presupuesto y sus propios plazos.

3. Sobrevalorar el diseño e infravalorar la técnica

El tercer error, especialmente extendido entre los empresarios, es centrarse en exceso en el diseño visual e ignorar o infravalorar por completo la parte técnica: el empresario elige al desarrollador basándose únicamente en lo bonitos que resultan los sitios web de su portfolio, sin hacer preguntas sobre la calidad del código, la velocidad del sitio, las prácticas de seguridad, la capacidad de escalado o la optimización SEO. El diseño visual y el desarrollo técnico son dos disciplinas distintas, y un sitio web bonito que tarda diez segundos en cargar, es vulnerable a los ataques y no aparece en los buscadores vale mucho menos que un sitio visualmente más sencillo que es rápido, seguro y está bien optimizado.

Los estudios muestran de forma constante que el 53% de los usuarios de dispositivos móviles abandona un sitio si tarda más de tres segundos en cargar, y que un retraso de un segundo en el tiempo de carga de la página puede reducir sensiblemente las conversiones, ya que, según el estudio de Akamai y SOASTA, un retraso de solo 100 milisegundos reduce las tasas de conversión hasta en un 7 %: estas cifras significan que el rendimiento del sitio influye directamente en sus ingresos, y ningún diseño bonito lo compensará si se han cometido errores en la ejecución técnica. El enfoque correcto es valorar al desarrollador no solo por el aspecto visual de sus trabajos, sino también por cómo es capaz de explicar su planteamiento técnico: qué arquitectura utiliza, cómo garantiza la velocidad del sitio, cómo aborda las cuestiones de seguridad y cómo planifica el escalado del sitio si el negocio crece y los requisitos cambian.

4. Dejar el SEO «para después»

Los empresarios perciben muy a menudo la optimización para motores de búsqueda como algo que se puede añadir al sitio web una vez creado, igual que se pinta una pared después de construir la casa; en realidad, sin embargo, el SEO técnico es una parte fundamental de la arquitectura del sitio, e incorporarlo después del lanzamiento resulta considerablemente más caro, más complejo y menos eficaz que incluirlo en el proceso de desarrollo desde el primer momento. La estructura de las URL, la jerarquía de páginas, la arquitectura de enlaces internos, la estructura de los encabezados, el marcado de datos estructurados (schema markup), la optimización de las imágenes, las métricas de Core Web Vitals y la experiencia en dispositivos móviles: todos estos elementos son mucho más fáciles y baratos de implementar correctamente durante el desarrollo que de rehacer en un sitio ya terminado.

Google utiliza la indexación con prioridad móvil (mobile-first indexing), lo que significa que la versión móvil de su sitio es aquella por la que Google evalúa y clasifica su contenido: si la experiencia móvil es mala, su posicionamiento se resentirá por muy buena que sea la versión de escritorio. Según los datos de Statista, el comercio móvil alcanzó en 2024 aproximadamente 2,07 billones de dólares, y los datos de Google muestran que, entre 2015 y 2017, las búsquedas móviles con intención de compra y la expresión «cerca de mí» (near me) crecieron más de cinco veces: la optimización móvil no es simplemente una «buena opción adicional», sino una necesidad de negocio, especialmente para las empresas locales que quieren atraer clientes de su región. El enfoque correcto consiste en indicar los requisitos de SEO ya en la solicitud de propuesta (RFP) como parte obligatoria del desarrollo, y no como un servicio aparte que se pague por separado. En concreto, esto significa que el desarrollador debe planificar desde el principio una estructura de URL amigable para el SEO, garantizar una jerarquía correcta de los encabezados (H1, H2, H3), implementar los datos estructurados (schema markup), optimizar las imágenes con textos alt y formatos modernos, configurar el mapa del sitio XML y el archivo robots.txt, y asegurar que la velocidad del sitio cumple los estándares de Core Web Vitals; en un sitio ya terminado, esos mismos cambios pueden exigir una reconstrucción sustancial de la arquitectura.

5. Ignorar la producción de contenidos o dejarla para el último momento

El quinto error es una de las causas más frecuentes de retraso en los proyectos de desarrollo web: los empresarios creen que el contenido es algo que se puede «redactar» en el último momento y concentran toda su atención en el diseño y la funcionalidad, mientras los textos, las imágenes y los demás elementos de contenido quedan sin elaborar hasta el final del proyecto. El problema es que el diseño se construye en torno al contenido y no al revés: si el contenido no está listo, el diseñador se ve obligado a trabajar con texto de relleno (lorem ipsum), lo que hace que el diseño no se corresponda con el volumen ni con la estructura del contenido real y que, cuando por fin se inserta el texto definitivo, el aspecto visual pueda cambiar drásticamente, y no para bien.

El retraso en la preparación de los contenidos es una de las causas de demora de proyectos que más se mencionan en el sector, y es lógico, porque crear contenido de calidad lleva tiempo: los textos hay que escribirlos, ajustarlos al tono y al mensaje de la empresa y optimizarlos para el SEO, y las imágenes hay que elegirlas o crearlas de modo que encajen con la identidad de marca y con los requisitos del diseño. El enfoque correcto es tratar la producción de contenidos como una fase crítica del proyecto, con sus propios plazos y responsables, que empieza en paralelo a los trabajos de diseño o incluso antes, y no como una tarea adicional que se realiza «cuando haya tiempo». Si la empresa no dispone de recursos internos para crear el contenido, hay que incluirlo en el presupuesto del proyecto como una partida independiente y contratar a un redactor profesional o a un especialista en contenidos.

6. Un mantenimiento posventa no planificado

El sexto error está directamente relacionado con el tema del mantenimiento, que ya hemos tratado en el artículo sobre la recuperación de sitios web hackeados: muchos empresarios consideran que un sitio web es un producto único que, una vez creado, simplemente «funciona», y no piensan en lo que ocurrirá tras el lanzamiento, cuando hagan falta actualizaciones de seguridad, cambios de contenido, correcciones de errores, optimización del rendimiento y compatibilidad con las nuevas versiones de los navegadores y con los nuevos dispositivos. Este planteamiento es peligroso, porque un sitio web sin mantenimiento es un sitio web desprotegido: según los datos de Sucuri, más de la mitad de los sitios con CMS hackeados funcionaban en el momento de la infección con una versión desfasada del software, y la muy citada estimación de Sophos, que tiene más de diez años, habla de unos 30 000 sitios nuevos al día en los que se detecta código malicioso.

La cuestión del mantenimiento debe abordarse ya en la fase de planificación del proyecto, y no una vez lanzado el sitio, porque afecta tanto a la elección de la tecnología (algunas plataformas son más fáciles de mantener que otras) como a la planificación del presupuesto (los costes de mantenimiento deben incluirse en el presupuesto total del ciclo de vida del sitio) y también a la elección del desarrollador (hay que averiguar si el desarrollador ofrece asimismo servicios de mantenimiento y cuáles son sus condiciones). En el caso ideal, en el propio contrato se incluye un acuerdo de soporte posventa (SLA — Service Level Agreement) que define qué trabajos de mantenimiento se realizarán, con qué frecuencia, cuál es el tiempo de respuesta en caso de problemas y cuál es el coste de este servicio.

7. Cesión del control del dominio y del alojamiento al desarrollador

El séptimo error es uno de los que pueden acarrear las consecuencias más graves a largo plazo y, aun así, se comete con sorprendente frecuencia: el empresario permite que el desarrollador registre el nombre de dominio y contrate el servicio de alojamiento a nombre del desarrollador, y no a nombre de la empresa, y pierde así el control sobre unos activos digitales de importancia crítica. Si la colaboración con el desarrollador termina por algún motivo —con independencia de que ocurra de forma amistosa o a raíz de un conflicto—, el empresario puede encontrarse en una situación en la que no pueda acceder a su dominio ni trasladar su sitio web a otro servidor, o incluso perder su nombre de dominio si el desarrollador no renueva el registro.

El nombre de dominio y la cuenta de alojamiento son activos digitales de su negocio y deben estar en su propiedad y bajo su control, igual que el domicilio social de su empresa o su marca registrada: usted no permitiría que su contable registrase el domicilio social de su empresa a nombre propio y, del mismo modo, no debería permitir que el desarrollador controle su identidad digital. El enfoque correcto consiste en registrar usted mismo el nombre de dominio con un registrador de confianza, contratar el servicio de alojamiento a nombre de su propia empresa o alquilarlo a un socio que entregue la configuración y los datos cuando se le solicite y dar al desarrollador únicamente el acceso técnico necesario para el desarrollo y la puesta en marcha del sitio web, pero no el control administrativo sobre estos recursos. Lo mismo se aplica a Google Search Console, Google Analytics y a otras cuentas de analítica y marketing: deben crearse a nombre de la empresa, y al desarrollador se le concede acceso con permisos limitados.

8. Ignorar las pruebas y el aseguramiento de la calidad

El octavo error tiene que ver con que muchos empresarios no prestan suficiente atención al proceso de pruebas y aceptan el sitio web sin una revisión minuciosa, confiando en la afirmación del desarrollador de que «todo funciona»; en realidad, unas pruebas de calidad son un proceso complejo y que exige mucho tiempo, y abarcan bastante más que navegar un poco por el sitio y pulsar algunos botones. Un aseguramiento de la calidad insuficiente es una de las razones más frecuentes de que los sitios web presenten, tras su lanzamiento, errores que afectan a la experiencia de usuario, a las conversiones e incluso a la seguridad, y corregirlos en un sitio ya terminado siempre resulta más caro y más complicado que si los problemas se hubieran detectado y resuelto durante el desarrollo.

Las pruebas deberían abarcar varias dimensiones: las pruebas funcionales comprueban si todas las funciones del sitio operan correctamente —formularios, buscador, navegación, registro de usuarios, procesos de carrito y de pago, filtrado y ordenación de contenidos—; las pruebas de compatibilidad comprueban si el sitio funciona correctamente en distintos navegadores (Chrome, Firefox, Safari, Edge), sistemas operativos y dispositivos (ordenadores, tabletas y teléfonos móviles con distintos tamaños de pantalla); las pruebas de rendimiento evalúan la velocidad de carga del sitio, los tiempos de respuesta y su comportamiento en condiciones de carga; las pruebas de seguridad identifican vulnerabilidades potenciales, como las inyecciones SQL, las posibilidades de ataques XSS y un control de acceso incorrecto; y las pruebas de accesibilidad comprueban si el sitio puede ser utilizado por personas con distintas limitaciones funcionales, conforme a los estándares WCAG.

El enfoque correcto consiste en prever ya en el contrato una fase de pruebas con criterios de aceptación claramente definidos: esto significa que queda documentado qué se va a probar exactamente, qué resultados se consideran aceptables y cuál es el procedimiento en caso de que durante las pruebas se detecten problemas. También es recomendable que el empresario realice las pruebas de aceptación por sí mismo o con la ayuda de un especialista independiente, en lugar de fiarse por completo de la autoevaluación del desarrollador, porque un desarrollador que prueba su propio trabajo es como un estudiante que corrige su propio examen.

9. Tomar decisiones en comité sin un único responsable

El noveno error es de naturaleza organizativa y resulta especialmente característico de las empresas y organizaciones de mayor tamaño, en las que en el proyecto de desarrollo del sitio web intervienen varios decisores —el departamento de marketing, el equipo comercial, la dirección, el departamento de TI y, a veces, incluso los abogados— y cada uno de ellos participa en el proceso de aprobación del diseño y del contenido con el mismo derecho de voto. Este enfoque de «diseño por comité» conduce casi siempre a un resultado lleno de concesiones que no satisface a nadie, porque cada decisor intenta imponer en el sitio sus propias prioridades y preferencias, y el resultado final acaba siendo recargado, incoherente y desalineado con los objetivos de negocio.

Los estudios y la experiencia del sector muestran de forma consistente que los proyectos en los que hay un único decisor claramente designado, con potestad para aprobar el diseño, el contenido y la funcionalidad, se terminan antes, se ajustan al presupuesto con más frecuencia y logran mejores resultados que aquellos en los que las decisiones las toma un grupo. Esto no significa que la opinión de las demás partes implicadas no sea importante: significa que debe existir un proceso claro en el que todas las partes puedan expresar su opinión y aportar comentarios, pero en el que la decisión final la tome una sola persona, facultada para ello y responsable del resultado del proyecto. La matriz RACI (Responsible, Accountable, Consulted, Informed) es una herramienta eficaz para estructurar ese proceso: define con claridad quién es responsable de ejecutar el trabajo, quién es el decisor final, a quién hay que consultar y a quién hay que informar de las decisiones.

10. Ignorar la propiedad intelectual y las cuestiones contractuales

El décimo error tiene que ver con la vertiente jurídica, que muchos empresarios —sobre todo los propietarios de empresas pequeñas— tienden a ignorar o a considerar burocracia innecesaria: inician la colaboración con el desarrollador sin un contrato formal, sin derechos de propiedad intelectual claramente definidos y sin un acuerdo de confidencialidad (NDA), lo que puede generar problemas graves tanto durante el proyecto como una vez terminado. Sin derechos de propiedad intelectual claramente definidos, el empresario puede acabar en una situación en la que en realidad no es dueño del código fuente que ha pagado, y el desarrollador puede utilizar ese mismo código con otros clientes o incluso negarse a entregarlo si la colaboración termina antes de tiempo.

El contrato debería establecer con claridad que toda la propiedad intelectual creada durante el desarrollo —código fuente, archivos de diseño, gráficos, estructuras de datos y documentación— pertenece al cliente una vez recibido el pago íntegro, y que el desarrollador no tiene derecho a utilizarla con otros fines sin el consentimiento del cliente. Asimismo, el contrato debe incluir la definición del alcance del proyecto, los plazos, el calendario de pagos (preferiblemente vinculado al cumplimiento de hitos y no al tiempo), el periodo de garantía, las cláusulas de confidencialidad y el procedimiento de resolución de conflictos. Una estructura de pagos vinculada a hitos concretos y aprobados (milestone-based payments), y no simplemente a un periodo de tiempo, motiva al desarrollador a cumplir los plazos y garantiza que el empresario pague solo por el trabajo realmente ejecutado y no por un consumo de horas indeterminado; en proyectos grandes y no estándar también resulta adecuado el modelo de tiempo y materiales con un tope semanal, siempre que el alcance y el tope estén fijados por escrito.

El acuerdo de confidencialidad (NDA) es especialmente importante cuando durante el desarrollo se revela al desarrollador información empresarial sensible: datos de clientes, procesos de negocio, política de precios u otra información confidencial que, si llega a manos de la competencia, puede perjudicar a su negocio. A muchos empresarios les parece que el NDA es un instrumento de las grandes corporaciones, pero en realidad es igual de importante para cualquier empresa que comparta información sensible con socios externos. Además, un contrato bien estructurado, con hitos claros y criterios de aceptación, funciona también como herramienta de gestión del proyecto: asegura que ambas partes coincidan en qué se está haciendo, cuándo estará terminado y cuál es el resultado esperado en cada fase, y reduce notablemente el riesgo de malentendidos y conflictos a lo largo del proyecto.

Otros errores que conviene mencionar

Aunque hemos descrito los diez errores principales, existen otras carencias frecuentes que merecen mención aparte, porque pueden influir de forma sustancial en el éxito de un proyecto de desarrollo web. Una de ellas es confiar en exceso en el criterio del desarrollador en todas las cuestiones, incluida la estrategia de negocio: el desarrollador es experto en tecnología, pero rara vez conoce las particularidades de su negocio, su público objetivo y la dinámica del mercado tan bien como usted, y, si le delega por completo todas las decisiones, corre el riesgo de obtener un sitio técnicamente bueno pero ineficaz desde el punto de vista comercial.

El segundo error habitual es ignorar la accesibilidad (accessibility): muchos empresarios ni siquiera son conscientes de que su sitio web debe ser accesible para las personas con limitaciones funcionales y de que en numerosas jurisdicciones se trata de una exigencia legal, no simplemente de una buena práctica. Garantizar la accesibilidad ya durante el desarrollo es bastante más sencillo y barato que añadirla a un sitio terminado, y amplía su público potencial, ya que alrededor del 16 % de la población mundial —1300 millones de personas— vive con limitaciones funcionales importantes.

El tercer error adicional es no implantar la analítica ni el seguimiento de conversiones: muchos sitios se lanzan sin configurar Google Analytics, Google Search Console u otras herramientas de analítica, lo que significa que el empresario no puede evaluar la eficacia del sitio, detectar problemas ni tomar decisiones basadas en datos sobre la optimización posterior. La implantación de la analítica debe incluirse en el alcance del proyecto de desarrollo como requisito obligatorio, no como algo que «se hará más adelante». Sin datos analíticos usted actúa, en la práctica, a ciegas: no sabe cuántos visitantes atrae su sitio, de dónde vienen, qué páginas visitan, en qué punto lo «abandonan» ni si su sitio cumple realmente su función comercial.

El cuarto error adicional que merece mención es no garantizar el cumplimiento legal del sitio: muchos sitios nuevos se lanzan sin política de privacidad, sin aviso de cookies, sin condiciones de uso ni otros documentos jurídicos obligatorios conforme al GDPR y a otra normativa aplicable, y esa negligencia puede acarrear consecuencias legales graves, incluidas multas de hasta 20 millones de euros o del 4 % del volumen de negocio anual total de la empresa en todo el mundo, según cuál de las dos cantidades sea mayor. El cumplimiento legal no es solo un requisito formal: es también una señal de confianza para sus visitantes, que demuestra que usted se toma en serio la protección y la privacidad de sus datos, y los consumidores actuales prestan cada vez más atención a cómo tratan las empresas sus datos personales.