Cada año recibimos llamadas de clientes que han pagado dos veces por la misma web: una por hacerlo con la tecnología equivocada y otra por rehacerlo. La decisión técnica inicial condiciona el coste de los cinco años siguientes. Aquí están los criterios que utilizamos para decidir, sin preferencia de margen.
La pregunta que hacemos primero no es técnica:
Un fabricante de maquinaria de la Plana de Vic nos llegó con un pliego muy concreto: querían una web hecha con Laravel.
Habían leído que era «más profesional«. Cuando preguntamos qué debía hacer la web, la respuesta fue: catálogo de 40 productos, formulario de contacto y un blog que actualizarían «de vez en cuando«.
Les recomendamos WordPress. El presupuesto descendió un 60% y el proyecto se entregó en seis semanas en lugar de cuatro meses.
El error habitual no es elegir mal entre tres tecnologías. Es elegir antes de haber definido quién mantiene la web, cuánto se puede invertir y cuál es la ambición funcional real a tres años vista. Estos tres factores (presupuesto, ambición técnica y mantenimiento posterior) deciden prácticamente siempre.
El resto es conversación de sobremesa.
Aplicación concreta: antes de solicitar presupuestos, escriba en una hoja quién actualizará los contenidos, cuántas integraciones con sistemas externos necesita y qué presupuesto anual de mantenimiento puede sostener. Con estas tres respuestas, la tecnología casi se selecciona sola.
WordPress: cuándo es la respuesta correcta y cuándo no lo es:
WordPress mueve en torno al 43% de los sitios web del mundo. Esta cuota genera dos efectos contrarios: un enorme ecosistema de plugins y profesionales disponibles, y una superficie de ataque considerable.
Es la tecnología correcta cuando:
El cliente quiere autonomía editorial real. Un equipo de marketing sin perfil técnico puede publicar, reorganizar y medir sin depender de la agencia. Esto, en una web corporativa con blog activo, es mejor que cualquier elegancia de arquitectura.
También cuando el presupuesto inicial es ajustado y su funcionalidad es estándar: presentación de empresa, catálogo no transaccional, contenido, captación de leads. Una web corporativa bien hecha con WordPress suele moverse entre los 4.000 y los 12.000 € según complejidad, diseño e integraciones.
No lo es cuando:
La lógica de negocio es el producto. Si la web debe calcular tarifas con reglas específicas, gestionar flujos de aprobación multinivel o sincronizarse en tiempo real con un ERP con modelos de datos propios, WordPress obliga a luchar contra su propia arquitectura. Acabas escribiendo un aplicativo a medida dentro de un gestor de contenidos, y pagando lo peor de cada mundo.
Tampoco cuando el volumen de tráfico y la concurrencia son altos y previsibles. Se puede escalar, sí, pero el coste de infraestructura y optimización crece más rápido que con una aplicación diseñada para escalar desde el principio.
Un apunte honesto: el mantenimiento de WordPress no es opcional.
Una web sin actualizar durante un año es un incidente de seguridad esperando a ocurrir. Si alguien no asume ese coste recurrente (la agencia o un interno formado), la tecnología barata sale cara.
Laravel: potencia a cambio de dependencia:
Laravel es un framework PHP, no un CMS. Esa distinción es toda la conversación.
Con Laravel se construye exactamente lo que se necesita, sin capas intermedias ni compromisos heredados.
Cuando hemos trabajado en proyectos con lógica de negocio densa (plataformas de gestión con roles, permisos y flujos operativos propios), es la decisión que nos ha permitido mantener el código limpio a cinco años vista.
Es la tecnología correcta cuando:
La web es la aplicación. Portales de cliente con área privada compleja, plataformas que agregan datos de diversas fuentes, sistemas en los que la interfaz pública es sólo la punta del iceberg.
Nuestros productos internos de gestión van por ese camino precisamente porque el núcleo del valor es la lógica, no la publicación de contenido.
También cuando existen integraciones serias: ERPs, CRMs, APIs de terceros con autenticación compleja, procesos programados. Laravel tiene herramientas nativas para ello que en un CMS son siempre un parche.
No lo es cuando:
El equipo de marketing necesita cambiar la home cada quince días. Sin un panel de administración construido expresamente (que cuesta dinero y tiempo), cada cambio de contenido pasa por un desarrollador. Esto funciona en una plataforma; es insostenible en una web corporativa.
Tampoco cuando el presupuesto es corto. Un proyecto Laravel arranca típicamente a los 15.000-20.000 € porque se construye desde cero lo que en un CMS ya está ahí.
Y existe un factor que raramente se explica: la dependencia. Un proyecto Laravel a medida sólo puede mantenerlo con comodidad quien lo ha escrito o quien le dedique tiempo a entenderlo. La documentación interna deja de ser un lujo y pasa a ser condición contractual.
Aplicación concreta: si deseáis Laravel pero también autonomía editorial, presupuestad el panel de administración como una partida propia desde el primer día. Añadirlo después siempre cuesta el doble.
Prestashop: el especialista que no sirve para todo:
Prestashop es un CMS de ecommerce. Hace algo y lo hace bien: vender productos físicos con catálogo estructurado, variantes, stocks, transportistas y fiscalidad europea.
Es la tecnología correcta cuando:
Hay un catálogo real con complejidad: cientos o miles de referencias, atributos combinables, precios por grupo de cliente, gestión de stock multialmacén. Prestashop lo trae de serie y su ecosistema de módulos cubre la casuística ibérica (Redsys, transportistas locales, facturación) mucho mejor que alternativas más internacionales.
También cuando hay equipo interno que gestionará pedidos a diario. La interfaz de trasfondo está pensada para operativa comercial, no para desarrolladores.
No lo es cuando:
El catálogo tiene 15 productos y su contenido editorial pesa más que la venta. Aquí un WooCommerce sobre WordPress suele ser más coherente: la web es fundamentalmente contenida y marca, con una tienda como función.
Tampoco cuando el modelo de negocio se aleja del comercio de producto físico: suscripciones complejas, marketplaces multivendedor con liquidaciones, venta de servicios con reserva de agenda. Se puede forzar a Prestashop hacia allí, pero cada módulo añadido es una dependencia más que actualizar.
Acerca de versiones: los saltos mayores de Prestashop históricamente han sido migraciones, no actualizaciones. Es necesario presupuestarlos como proyecto, no como mantenimiento.
Los tres factores que deciden siempre
Un ejercicio que hacemos en las primeras reuniones: puntuar del 1 al 5 estos tres ejes.
Presupuesto total a tres años, no inicial. Una tienda Prestashop de 12.000€ con 2.500€/año de mantenimiento y módulos cuesta 19.500€ a tres años. Un desarrollo a medida de 22.000 € con 1.500 €/año cuesta 26.500 €. La diferencia real es mucho menor que la de la primera factura, ya menudo la decisión se toma mirando sólo a esta.
Ambición técnica funcional. No «queremos una web moderna«, sino: cuántas integraciones, qué lógica de negocio propia, qué roles de usuario, qué volumen. Si la respuesta cabe en una hoja, un CMS lo resuelve. Si necesita un diagrama, hablamos de framework.
Quien mantiene esto. El factor más ignorado y el más determinante. Si no hay nadie asignado y no existe presupuesto recurrente, la única tecnología responsable es la que menos mantenimiento pide y más profesionales disponibles tiene en el mercado. Esto suele apuntar hacia WordPress, aunque técnicamente sea la respuesta menos elegante.
Existe una cuarta variable que no controlamos: la vida útil real del proyecto. Una web corporativa se rehace cada 4-6 años de media por razones de diseño y posicionamiento, no técnicas. Sobredimensionar la arquitectura de un proyecto que se va a reescribir igualmente es una forma cara de tener razón.
Los casos híbridos que nadie explica:
La pregunta raramente es pura. Las combinaciones que hemos implementado con mayor frecuencia:
WordPress como front, aplicación a medida detrás. El contenido y el SEO viven en WordPress, con autonomía total para marketing; la lógica de negocio vive en una aplicación separada que se comunica por API. Encaja cuando ambas necesidades son reales y ninguna puede ceder.
Prestashop con desarrollos a medida acotados. En lugar de acumular módulos de terceros, se desarrollan ambos o tres puntos críticos. Reduce dependencias y suele salir más barato a tres años que mantener ocho módulos comprados.
Migración por fases. Cuando un web legacy funciona pero ahoga, no es necesario rehacerlo todo a la vez. Se puede extraer primero la parte que más duele.
Ninguna de estas opciones es más barata inicialmente. Las tres suelen ser más baratas en el horizonte en el que realmente se juega la partida.
Donde termina la conversación técnica:
Hemos visto excelentes proyectos con WordPress y desastres con Laravel. La tecnología no salva una mala definición funcional, y ninguna arquitectura compensa que nadie tenga claro qué debe hacer en la web.
Si estáis en este punto de decisión y queréis una lectura técnica independiente de su caso (con los números a tres años, no sólo la primera factura), ofrecemos una auditoría tecnológica gratuita: revisamos los requisitos reales, su contexto de mantenimiento y os decimos qué tecnología os conviene, aunque la respuesta sea que lo que ya tenéis funciona.
Es más barato equivocarse en una conversación que en un proyecto.