Quan NO necessites software a mida: 6 escenaris en què un partner honest t'estalvia diners
TL;DR: Hi ha 6 escenaris típics en què contractar software a mida és la pitjor decisió: procés encara canviant, SaaS vertical que cobreix el 90%, volum que no justifica la inversió, sistema actual que només necessita ajustos, problema organitzatiu disfressat de problema tècnic, i modernització sense un problema concret al darrere. Abans de gastar 40.000 € en un desenvolupament a mida, l'ordre raonable és: polir l'Excel actual, provar low-code, valorar un SaaS específic, i només després construir des de zero. Dir 'no' a un projecte que no ens necessita és el que fa que ens truquin quan sí.
La conversa es repeteix diverses vegades l’any, i sempre és incòmoda. Un responsable d’operacions, amb pressupost aprovat, amb tres propostes sobre la taula, amb un proveïdor gairebé escollit. Arriba a nosaltres per a una segona opinió tècnica. I la nostra resposta, després de dues reunions de discovery, és que en el seu cas particular contractar software a mida seria llençar 40.000 € a les escombraries. Que el que té és suficient amb ajustos. Que el problema real no és de tecnologia.
És un post estrany d’escriure perquè va contra la butxaca de VisibleSoft. Venem software a mida. Vivim d’això. Però la decisió correcta per al client és la decisió correcta, i a la llarga dir “no” a projectes que no ens necessiten és el que fa que els mateixos clients ens tornin a trucar dos anys després quan sí ho necessiten. Si després de llegir aquest post decideixes que el teu cas encaixa en algun dels 6 escenaris, haurà valgut la pena escriure’l encara que perdis la conversa amb nosaltres.
Els 6 escenaris on NO convé software a mida
1. El procés encara canvia cada pocs mesos
Si la manera de fer les coses no està estabilitzada, sistematitzar-la en una aplicació a mida significa pagar dues vegades: la primera per construir i la segona per refer quan el procés torni a canviar. Passa molt en empreses que estan creixent: el comercial canvia el flux de cotització cada trimestre perquè estan aprenent què funciona, operacions reorganitza el magatzem dues vegades l’any, màrqueting modifica l’embut cada llançament. Construir software a mida sobre sorres movedisses és comprar-se deute tècnic des del dia u.
El senyal clar: els últims 6 mesos has canviat més de 3 vegades la manera de fer aquest procés. Canvis substancials, no ajustos menors. Mentre aquesta freqüència continuï així, itera en Excel, en Notion o en un low-code barat. La sistematització dura arriba després.
2. Hi ha un SaaS específic per al teu sector que cobreix el 90% del cas
Això passa amb més freqüència de la que el client sospita. Per a gairebé qualsevol sector hi ha un SaaS vertical: clíniques dentals, tallers mecànics, gestories, acadèmies, instal·lacions d’aire condicionat, despatxos d’advocats. Parlem de productes pensats per al teu nínxol, provats en centenars o milers d’empreses com la teva, amb un cost mensual entre 50 i 500 € per usuari.
Construir des de zero alguna cosa que el 90% s’assembla al que ja existeix al mercat és vanitat. La pregunta correcta no és “podria fer-m’ho a mida?”, sinó “què fa exactament aquest SaaS, què li falta per al meu cas, i quant costa cobrir aquesta diferència?”. De vegades la resposta és mòdul a mida sobre el SaaS, o integració amb un sistema secundari, o personalització del SaaS. Gairebé mai és llençar-ho tot i refer.
La decisió la cobrim a fons a Software a mida vs SaaS: quan triar cada un, amb la matriu que apliquem en discovery.
3. El volum no justifica la inversió
El càlcul de ROI honest és brutal en molts casos petits. Un software a mida raonable costa entre 20.000 i 60.000 € per a una pime. Perquè aquesta inversió es justifiqui, el problema que resol ha d’alliberar com a mínim 1.000-3.000 € al mes en hores, errors o ingressos perduts. Si el que estalvies són 150 € al mes, el sistema trigarà 15 anys a amortitzar-se, i els sistemes no duren 15 anys sense reinversió.
Casos típics on el volum mata el ROI: equips de 3-5 persones amb processos puntuals, negocis estacionals on el sistema només s’utilitzaria 4 mesos l’any, empreses que es plantegen una venda o tancament en 2-3 anys. En aquests escenaris, el raonable és assumir que l’Excel actual amb dolor ocasional costa menys que una migració ben feta.
4. El que tens funciona, només necessita ajustos
De vegades el client arriba amb “el sistema està obsolet” i, quan entrem a mirar-lo, el que hi ha és un sistema que funciona bé per al 95% de la feina, amb dos o tres punts concrets que freguen a diari. En aquests casos, refer-ho tot des de zero és desproporcionat. El que toca és intervenir aquests punts: integrar el sistema actual amb una eina nova, afegir un mòdul a sobre sense tocar el nucli, automatitzar el flux manual que sobra entre dos sistemes.
L’instint de “ja que hi som ho refem tot” costa 5-10 vegades més que arreglar el que fa mal. I rarament surt tan bé com esperàvem: el sistema nou porta els seus propis problemes, que ara cal aprendre a gestionar. Cobrim això a fons a Modernitzar un ERP legacy: quan convé migrar i quan no, on l’estratègia 4 (estendre en comptes de migrar) sol ser la resposta correcta per a més casos dels que s’admet.
5. El problema real és organitzatiu, no de software
Aquest és el més delicat i també el més freqüent. El client explica que necessita un sistema perquè l’equip no es salti els passos del procés. O que vol una eina que obligui els comercials a registrar les trucades. O un panell de control que eviti que els responsables no omplin els informes a temps.
Cap software resol això. Si la gent no segueix un procés, no és perquè l’eina sigui dolenta. És perquè el procés no està clar, perquè ningú verifica que es segueixi, o perquè seguir-lo no aporta valor a qui l’ha de seguir. Construir una aplicació a mida per resoldre un problema organitzatiu acaba sempre igual: el sistema entra en producció, la gent l’utilitza la primera setmana, i als dos mesos s’han inventat mil maneres de saltar-se’l o de ficar-hi dades brossa per complir.
Aquí el que toca abans de software és revisar el procés amb qui l’executa, entendre per què no se segueix, i arreglar la causa. De vegades la solució és tan tonta com canviar qui verifica el compliment, o eliminar passos que no aportaven valor real. Quan després es sistematitza, el que es construeix encaixa amb com treballa la gent, no contra com treballa.
6. Vols “modernitzar” sense un problema concret al darrere
El més car emocionalment: pressupost aprovat, ganes de modernitzar, premsa especialitzada parlant de transformació digital, competidors que semblen haver fet el salt. Però en demanar-li al client que defineixi quin és el problema que el software resoldrà, no hi ha resposta clara més enllà de “ser més eficients” o “estar al dia”.
Modernització sense un dolor concret al darrere acaba sent un projecte sense mètriques d’èxit. El construeixes, l’entregues, i ningú sap dir si va funcionar. Si no pots quantificar el problema abans de començar (en hores, en euros, en errors, en comandes perdudes), no estàs en moment d’invertir en software a mida. Estàs en moment d’auditar la teva operació i trobar on fa mal de debò.
El test de les 3 preguntes
Quan un client ens demana segona opinió abans d’invertir, el test que fem servir per distingir un problema que el software resol d’un que no és aquest. Si les tres respostes són afirmatives, hi ha cas. Si alguna falla, convé aturar.
-
Pots descriure el problema sense esmentar tecnologia? “Triguem 3 dies a tancar l’inventari mensual perquè algú ha de creuar 4 fitxers diferents a mà” és un problema. “Hem de modernitzar l’ERP” no ho és. La descripció en termes de negoci és la prova que saps què fa mal.
-
T’estalviaria temps o diners mesurable si es resolgués? Quantificable, idealment en € al mes o en hores al mes. “Si es resolgués, recuperaríem 80 hores al mes de la Marisa que es podrien dedicar a comptes nous, que valen uns 2.500 € en sou i uns 6.000 € en marge de comptes nous”. Això és ROI defensable. “Seríem més eficients” no ho és.
-
La gent que pateix el problema l’identifica igual que tu? Pregunta a qui està al dia a dia. Si la teva definició del problema coincideix amb la seva, aneu en la mateixa direcció. Si discrepen, hi ha un desacord que no s’arregla amb software, i construir-lo només cristal·litzarà la versió de qui signa, ignorant qui usa.
Les alternatives més barates, per ordre de cost
Abans de saltar a software a mida, aquest és l’ordre raonable. Cada pas és més barat que el següent. Salta’n un només si tens evidència que no resol el teu cas, no per instint.
| Nivell | Què és | Cost orientatiu | Quan convé |
|---|---|---|---|
| 1 | Polir el teu Excel actual (templates, validacions, macros, documentació) | 1.500-4.000 € | Gairebé sempre abans de qualsevol altra opció |
| 2 | Low-code / no-code (Airtable, Notion, AppSheet, Bubble) | 3.000-12.000 € de setup + 50-300 €/mes | Procés definit però encara canviant, equips petits |
| 3 | SaaS vertical del teu sector | 50-500 € per usuari/mes | Procés estàndard del sector, sense diferenciació |
| 4 | SaaS genèric ben configurat (HubSpot, Notion, monday.com) | 50-300 € per usuari/mes + setup | Processos transversals (CRM, gestió, comunicació) |
| 5 | Personalització del SaaS que ja tens | 5.000-25.000 € | Hi ha un SaaS que cobreix el 80%, falta encaixar el 20% |
| 6 | Software a mida | 25.000-150.000 € | Diferenciació real, integracions profundes, propietat estratègica |
Per a més detall sobre quan Excel continua funcionant vs quan toca migrar, aquí cobrim l’escenari específic d’Excel. I si arribes fins al graó 6, abans de signar res convé revisar com avaluar el partner de desenvolupament.
I quan SÍ té sentit
Per no deixar-te penjat: hi ha casos on software a mida és la resposta correcta. Els quatre més clars:
- Processos diferencials que són part de la teva competitivitat. Si la teva manera de fer alguna cosa és el que et distingeix, sistematitzar-la en una eina estàndard t’iguala amb la resta del mercat. Aquí construir custom paga.
- Integracions profundes amb sistemes heretats. Quan necessites llegir i escriure en temps real sobre un ERP de 15 anys que cap SaaS sap tocar.
- Volum d’usuaris que trenca el model per-user. A partir de 100-150 usuaris, pagar SaaS surt més car que amortitzar custom en 3-4 anys.
- Necessitat estratègica de propietat del codi. Sectors regulats, dades sensibles, operacions en països on el SaaS no opera, decisions de M&A on la propietat del sistema pesa.
Els matisos entre les dues respostes viuen a Software a mida vs SaaS: quan triar cada un.
Si el teu cas encaixa en algun dels 6 escenaris
Estalvia els diners. No hi ha volta de full. Polir el que tens et farà més rendible aquest any que invertir en una aplicació a mida que arribarà d’aquí a 4-6 mesos i resoldrà un problema mal definit. I si el teu cas és un altre, o estàs en dubte real, parlem sense compromís. En 30 minuts solem saber si el teu cas entra dins dels 6 escenaris d’aquest post o si toca tirar endavant. El primer ho diem també: ens compensa més a llarg termini dir un no honest que signar un projecte que no havíem d’haver començat.
Recursos
- Software a mida vs SaaS: quan triar cada un: la decisió paral·lela quan sí hi ha cas.
- Migrar d’Excel a una aplicació a mida: si l’escenari 1 no t’aplica i l’Excel pesa.
- Modernitzar un ERP legacy: quan convé migrar i quan no: per als casos de l’escenari 4.
- Com triar partner de desenvolupament de software a mida: si després de tot decideixes que sí toca, com no equivocar-te a la contractació.
- Reserva un diagnòstic gratuït
Preguntes freqüents
Però si vull modernitzar-me, per què no invertir ja?
Perquè modernitzar sense un problema concret al darrere sol acabar sent un projecte sense mètriques d'èxit. L'equip l'arrenca amb energia, gasta 3-6 mesos construint alguna cosa bonica i, en entregar-la, ningú sap què va canviar al negoci. La modernització pagada de debò és la que parteix d'un dolor mesurable: un procés que costa X hores al mes, un coll d'ampolla que retarda Y comandes, un error que apareix Z vegades al trimestre. Sense un problema quantificable, el que es construeix és nostàlgia tecnològica, no negoci.
Com sé si el meu procés està estabilitzat o encara canvia molt?
Una regla pràctica: si els últims 6 mesos has canviat més de 3 vegades la manera de fer aquest procés (canvis substancials, no ajustos menors), encara no està estabilitzat. Sistematitzar alguna cosa que canvia cada pocs mesos en una aplicació a mida significa pagar dues vegades: la primera per construir, la segona per refer quan el procés torni a canviar. Itera en Excel, en Notion o en un low-code mentre vagi evolucionant. Només quan el procés porta 8-12 mesos estable, té sentit sistematitzar-lo seriosament.
Quant m'hauria de costar realment revisar el meu Excel abans de saltar a custom?
Una auditoria externa d'un Excel crític costa entre 1.500 i 4.000 € i es fa en 1-2 setmanes. Identifica fórmules fràgils, proposa validacions, suggereix macros que automatitzen el repetitiu i, sobretot, documenta què fa l'Excel realment perquè deixi de dependre d'una sola persona. En molts casos, aquesta intervenció retarda la necessitat de saltar a custom entre 1 i 3 anys, que en diners significa entre 30.000 i 80.000 € no gastats en una migració prematura.
Si em dius que NO, què faig amb el pressupost que ja tinc aprovat?
Tres opcions raonables: gastar-lo a auditar el sistema actual i millorar-lo (on el ROI sol ser molt alt), reservar-lo per quan el problema sí estigui clar i mesurable (la inflació tecnològica no és tan alta com sembla, esperar 12 mesos no encareix tant el projecte), o fer-lo servir per resoldre un problema diferent que sí estigui madur. El que no és bona idea és gastar-lo només perquè està aprovat: pressupostos no gastats són problemes que es posposen, pressupostos mal gastats són problemes que s'enquisten.