Lo que aprendí después de 100 sitios web: el 80% fracasa por razones que no son técnicas
No llevo una cuenta exacta, pero calculo que en estos años he participado en la construcción de más de cien sitios web. Algunos propios, la mayoría para clientes. Y si hay algo que me ha quedado claro es que la tecnología rara vez es el problema.
Cuando un sitio web fracasa —y fracasar significa que no genera resultados, que se abandona a los seis meses, o que el cliente termina insatisfecho— la causa casi nunca está en el código. No es que el framework fuera incorrecto, que el hosting no diera abasto, o que el diseño no fuera lo suficientemente moderno. Casi siempre es algo más humano.
Me acuerdo del primer sitio que hice para un cliente que no era amigo ni familiar. Un negocio local, dueño entusiasta, una idea clara. O al menos eso creía. Avanzamos rápido las primeras semanas, pero cuando llegó el momento de definir el contenido, todo se detuvo. El cliente no sabía qué quería decir. Le pedía textos y me enviaba párrafos que sonaban a traducción automática de un manual corporativo. Le pedía fotos y me mandaba lo que tenía en el celular, sin orden ni propósito. El proyecto se alargó tres meses más de lo previsto, el presupuesto se duplicó, y al final el sitio se publicó con la mitad del contenido planeado. Duró un año online antes de que el cliente dejara de renovar el hosting.
Esa historia se repite con variaciones. He visto sitios web técnicamente impecables morir porque el cliente no tenía claro para qué los quería. He visto diseños premiados caer en el olvido porque nadie los actualizaba. He visto proyectos con el stack más moderno posible fracasar porque la comunicación entre el cliente y quien desarrollaba se rompió a las dos semanas.
Hay un patrón que se repite en casi todos los fracasos. El cliente contrata un sitio web como quien compra un mueble: algo que se adquiere, se instala y se olvida. Pero un sitio web no es un mueble. Es un organismo vivo que requiere contenido, actualizaciones, revisión constante. Y si el cliente no está preparado para eso, el sitio se vuelve un archivo muerto.
También está el caso del cliente que quiere demasiado. El que llega con una lista de funcionalidades sacadas de los tres competidores más grandes de su industria. Quiere ecommerce, blog, reservas, chat en vivo, integración con ERP, y todo para ayer. El proyecto se vuelve una bola de nieve de requerimientos que nadie prioriza. El desarrollador trabaja contra el reloj, el cliente se frustra porque las cosas tardan, y al final se entrega un producto inflado que no resuelve bien nada.
Y luego está el fracaso más silencioso: el sitio que se entrega, se paga, y simplemente nunca genera resultados porque nadie se preguntó qué se necesitaba para que funcionara. No hay estrategia de contenido, no hay plan de promoción, no hay métricas definidas. Es un sitio bonito que vive en el olvido digital.
Con los años aprendí que mi trabajo no es solo escribir código. Es entender si el cliente está listo, si el proyecto tiene sentido, si las condiciones para el éxito existen. Y cuando no existen, decirlo antes de empezar.
Suena obvio, pero te sorprendería saber cuántas veces no se hace.