Cada any rebem trucades de clients que han pagat dues vegades pel mateix web: una per fer-lo amb la tecnologia equivocada i una altra per refer-lo. La decisió tècnica inicial condiciona el cost dels cinc anys següents. Aquí hi ha els criteris que fem servir per decidir, sense preferència de marge.
La pregunta que fem primer no és tècnica
Un fabricant de maquinària de la Plana de Vic ens va arribar amb un plec molt concret: volien un web fet amb Laravel.
Havien llegit que era «més professional». Quan vam preguntar què havia de fer la web, la resposta va ser: catàleg de 40 productes, formulari de contacte i un blog que actualitzarien «de tant en tant«.
Els vam recomanar WordPress. El pressupost va baixar un 60% i el projecte es va lliurar en sis setmanes en lloc de quatre mesos.
L’error habitual no és escollir malament entre tres tecnologies. És escollir abans d’haver definit qui manté el web, quant es pot invertir i quina és l’ambició funcional real a tres anys vista. Aquests tres factors (pressupost, ambició tècnica i manteniment posterior) decideixen pràcticament sempre.
La resta és conversa de sobretaula.
Aplicació concreta: abans de demanar pressupostos, escriviu en un full qui actualitzarà els continguts, quantes integracions amb sistemes externs necessiteu i quin pressupost anual de manteniment podeu sostenir. Amb aquestes tres respostes, la tecnologia gairebé se selecciona sola.
WordPress: quan és la resposta correcta i quan no ho és
WordPress mou al voltant del 43% dels llocs web del món. Aquesta quota genera dos efectes contraris: un ecosistema enorme de plugins i professionals disponibles, i una superfície d’atac considerable.
És la tecnologia correcta quan:
El client vol autonomia editorial real. Un equip de màrqueting sense perfil tècnic pot publicar, reorganitzar i mesurar sense dependre de l’agència. Això, en un web corporatiu amb blog actiu, val més que qualsevol elegància d’arquitectura.
També quan el pressupost inicial és ajustat i la funcionalitat és estàndard: presentació d’empresa, catàleg no transaccional, contingut, captació de leads. Un web corporatiu ben fet amb WordPress se sol moure entre els 4.000 i els 12.000 € segons complexitat, disseny i integracions.
No ho és quan:
La lògica de negoci és el producte. Si el web ha de calcular tarifes amb regles específiques, gestionar fluxos d’aprovació multinivell o sincronitzar-se en temps real amb un ERP amb models de dades propis, WordPress obliga a lluitar contra la seva pròpia arquitectura. Acabes escrivint un aplicatiu a mida dins d’un gestor de continguts, i pagant el pitjor de cada món.
Tampoc quan el volum de trànsit i la concurrència són alts i previsibles. Es pot escalar, sí, però el cost d’infraestructura i optimització creix més ràpid que amb una aplicació dissenyada per escalar des del principi.
Un apunt honest: el manteniment de WordPress no és opcional.
Una web sense actualitzar durant un any és un incident de seguretat esperant a passar. Si algú no assumeix aquest cost recurrent (l’agència o un intern format), la tecnologia barata surt cara.
Laravel: potència a canvi de dependència
Laravel és un framework PHP, no un CMS. Aquesta distinció és tota la conversa.
Amb Laravel es construeix exactament el que es necessita, sense capes intermèdies ni compromisos heretats.
Quan hem treballat en projectes amb lògica de negoci densa (plataformes de gestió amb rols, permisos i fluxos operatius propis) és la decisió que ens ha permès mantenir el codi net a cinc anys vista.
És la tecnologia correcta quan:
El web és l’aplicació. Portals de client amb àrea privada complexa, plataformes que agreguen dades de diverses fonts, sistemes on la interfície pública és només la punta de l’iceberg.
Els nostres productes interns de gestió van per aquest camí precisament perquè el nucli del valor és la lògica, no la publicació de contingut.
També quan hi ha integracions serioses: ERPs, CRMs, APIs de tercers amb autenticació complexa, processos programats. Laravel té eines natives per a això que en un CMS són sempre un pedaç.
No ho és quan:
L’equip de màrqueting necessita canviar la home cada quinze dies. Sense un panell d’administració construït expressament (que costa diners i temps), cada canvi de contingut passa per un desenvolupador. Això funciona en una plataforma; és insostenible en una web corporativa.
Tampoc quan el pressupost és curt. Un projecte Laravel arrenca típicament als 15.000-20.000 € perquè s’hi construeix des de zero el que en un CMS ja hi és.
I hi ha un factor que rarament s’explica: la dependència. Un projecte Laravel a mida només el pot mantenir amb comoditat qui l’ha escrit o qui hi dediqui temps a entendre’l. La documentació interna deixa de ser un luxe i passa a ser una condició contractual.
Aplicació concreta: si voleu Laravel però també autonomia editorial, pressuposteu el panell d’administració com una partida pròpia des del primer dia. Afegir-lo després sempre costa el doble.
Prestashop: l’especialista que no serveix per a tot
Prestashop és un CMS d’ecommerce. Fa una cosa i la fa bé: vendre productes físics amb catàleg estructurat, variants, estocs, transportistes i fiscalitat europea.
És la tecnologia correcta quan:
Hi ha un catàleg real amb complexitat: centenars o milers de referències, atributs combinables, preus per grup de client, gestió d’estoc multimagatzem. Prestashop ho porta de sèrie i el seu ecosistema de mòduls cobreix la casuística ibèrica (Redsys, transportistes locals, facturació) molt millor que alternatives més internacionals.
També quan hi ha equip intern que gestionarà comandes diàriament. La interfície de rerefons està pensada per a operativa comercial, no per a desenvolupadors.
No ho és quan:
El catàleg té 15 productes i el contingut editorial pesa més que la venda. Aquí un WooCommerce sobre WordPress sol ser més coherent: el web és fonamentalment contingut i marca, amb una botiga com a funció.
Tampoc quan el model de negoci s’allunya del comerç de producte físic: subscripcions complexes, marketplaces multivendedor amb liquidacions, venda de serveis amb reserva d’agenda. Es pot forçar Prestashop cap allà, però cada mòdul afegit és una dependència més que actualitzar.
Sobre versions: els salts majors de Prestashop històricament han estat migracions, no actualitzacions. Cal pressupostar-los com a projecte, no com a manteniment.
Els tres factors que decideixen sempre
Un exercici que fem a les primeres reunions: puntuar de l’1 al 5 aquests tres eixos.
Pressupost total a tres anys, no inicial. Una botiga Prestashop de 12.000 € amb 2.500 €/any de manteniment i mòduls costa 19.500 € a tres anys. Un desenvolupament a mida de 22.000 € amb 1.500 €/any en costa 26.500 €. La diferència real és molt menor que la de la primera factura, i sovint la decisió es pren mirant només aquesta.
Ambició tècnica funcional. No «volem una web moderna«, sinó: quantes integracions, quina lògica de negoci pròpia, quins rols d’usuari, quin volum. Si la resposta cap en un full, un CMS ho resol. Si necessiteu un diagrama, parlem de framework.
Qui manté això. El factor més ignorat i el més determinant. Si no hi ha ningú assignat i no hi ha pressupost recurrent, l’única tecnologia responsable és la que menys manteniment demana i més professionals disponibles té al mercat. Això sol apuntar cap a WordPress, encara que tècnicament sigui la resposta menys elegant.
Hi ha una quarta variable que no controlem: la vida útil real del projecte. Un web corporatiu es refà cada 4-6 anys de mitjana per raons de disseny i posicionament, no tècniques. Sobredimensionar l’arquitectura d’un projecte que es reescriurà igualment és una forma cara de tenir raó.
Els casos híbrids que ningú explica
La pregunta rarament és pura. Les combinacions que hem implementat més sovint:
WordPress com a front, aplicació a mida al darrere. El contingut i el SEO viuen a WordPress, amb autonomia total per a màrqueting; la lògica de negoci viu en una aplicació separada que s’hi comunica per API. Encaixa quan les dues necessitats són reals i cap no pot cedir.
Prestashop amb desenvolupaments a mida acotats. En comptes d’acumular mòduls de tercers, es desenvolupen els dos o tres punts crítics. Redueix dependències i sol sortir més barat a tres anys que mantenir vuit mòduls comprats.
Migració per fases. Quan un web legacy funciona però ofega, no cal refer-ho tot alhora. Es pot extreure primer la part que més dol.
Cap d’aquestes opcions és més barata inicialment. Totes tres solen ser més barates a l’horitzó on realment es juga la partida.
On acaba la conversa tècnica
Hem vist projectes excel·lents amb WordPress i desastres amb Laravel. La tecnologia no salva una definició funcional dolenta, i cap arquitectura compensa que ningú tingui clar què ha de fer a la web.
Si esteu en aquest punt de decisió i voleu una lectura tècnica independent del vostre cas (amb els números a tres anys, no només la primera factura), oferim una auditoria tecnològica gratuïta: revisem els requisits reals, el vostre context de manteniment i us diem quina tecnologia us convé, encara que la resposta sigui que el que ja teniu funciona.
És més barat equivocar-se en una conversa que en un projecte.