Quant costa desenvolupar una aplicació a mida (i com no llençar els diners)
Per què dos pressupostos pel mateix es diferencien en un ordre de magnitud, quins costos no apareixen en cap proposta i les preguntes que cal fer abans de signar res.
· Desenvolupament full-stack
Demanes pressupost per a una aplicació i reps xifres que no s’assemblen entre si. No és que uns siguin cars: és que cadascú ha entès una cosa diferent, i cap ho ha dit. Aquest article serveix per demanar bé i per llegir el que t’arriba.
El que de debò mou el preu
El cost d’un desenvolupament no depèn de «quantes pantalles té». Depèn de cinc coses:
- Quants tipus d’usuari hi ha. Una aplicació amb un sol tipus d’usuari és un projecte. Amb tres —client, empleat, administrador— són gairebé tres projectes, perquè cada rol necessita els seus permisos, les seves pantalles i les seves proves.
- Amb quants sistemes es connecta. Cada integració —passarel·la de pagament, comptabilitat, facturació electrònica, missatgeria— és feina, i a més és feina que no controles: depens de la documentació i dels canvis de l’altre.
- Si hi ha diners pel mig. Cobrar exigeix seguretat, traçabilitat, gestió de devolucions i estats de pagament. Multiplica l’esforç.
- Si tracta dades personals sensibles. Salut, dades de menors, informació financera. Implica requisits legals que són disseny, no un paràgraf a l’avís legal.
- Quanta gent l’ha de fer servir alhora. Deu usuaris interns i deu mil de simultanis no són la mateixa arquitectura ni de bon tros.
Si el pressupost que t’arriba no esmenta aquestes cinc, no està pressupostant el teu projecte: està pressupostant una idea genèrica.
Els costos que no apareixen a la proposta
I aquí hi ha el motiu pel qual molts projectes surten al doble del previst:
- L’allotjament i els serveis. Servidor, base de dades, còpies, domini, certificats, correu transaccional. És un cost mensual, per sempre.
- El manteniment correctiu. El programari no s’espatlla sol, però el seu entorn canvia: sistemes operatius, navegadors, biblioteques amb vulnerabilitats, sistemes de tercers que modifiquen la seva manera de connectar-se. Una aplicació sense manteniment deixa de funcionar sola en dos o tres anys.
- La migració de dades. Passar el que avui viu en fulls de càlcul, amb vint anys d’inconsistències, gairebé sempre costa més del que ningú va estimar.
- La formació i el canvi d’hàbit. Si l’equip no la fa servir, el projecte ha fracassat encara que el programari sigui perfecte.
- Els canvis. Existiran. El que importa és que el contracte digui com es demanen, com es valoren i qui els aprova.
Una regla pràctica: pressuposta el manteniment anual com una fracció rellevant del desenvolupament inicial. Si ningú te l’ha esmentat, pregunta-la abans de signar.
L’error que més diners crema
Construir-ho tot abans que ningú ho faci servir.
Es defineix el sistema complet, se signa, es desenvolupa durant vuit mesos i es lliura. I la primera setmana d’ús real apareix que el flux principal no era aquell, que faltava un cas que passa cada dia i que la meitat de les funcions no les obre ningú.
L’alternativa: el mínim que resol el problema principal, en producció i amb usuaris reals, com abans millor. I a partir d’aquí, decidir amb dades què es construeix després. No és una moda: és l’única manera que el pressupost es gasti en el que es fa servir.
Abans de signar, pregunta això
- De qui és el codi? Que quedi per escrit. Si no és teu, estàs llogant.
- De qui són les dades i com les exporto? Demana veure una exportació real abans de començar, no al final.
- Què passa si desapareixeu? Repositori accessible, documentació de desplegament, accessos al teu nom. Un projecte que només pot tocar qui el va fer és un projecte segrestat.
- Què inclou el manteniment i què no? Amb temps de resposta escrits.
- Com es valoren els canvis?
- Quina tecnologia i per què? Si la resposta no s’entén, hi ha dues possibilitats i una és dolenta.
I la pregunta prèvia: de debò cal?
Val la pena dir-ho, encara que ens tregui feina: molts problemes que semblen requerir una aplicació a mida es resolen abans amb eines existents ben connectades. Un bon sistema de facturació, una base de dades compartida i dues automatitzacions resolen una part enorme dels casos, costen una fracció i es mantenen soles.
El desenvolupament a mida es justifica quan el que fas és la teva diferència competitiva, quan cap eina del mercat encaixa, o quan el cost de llicències per usuari ja supera el de construir. Fora d’aquests casos, hi ha camins més barats.
On és la frontera ho expliquem a quan l’Excel es queda curt.
Si aquest és el teu cas
Nosaltres comencem per veure si el teu problema es resol sense desenvolupar: això és l’auditoria de processos i IA, i surt amb un pla per escrit i una estimació honesta, inclosa la de no construir res. Si el desenvolupament és la resposta correcta, és desenvolupament a mida. I si el camí curt és automatitzar el que ja tens, és a què automatitzar primer.
Som Mindset & Code: automatització, dades i desenvolupament per a pimes i autònoms. Pots veure què fem i a quin preu.
Guia informativa. Qualsevol estimació concreta depèn de l’abast, de les integracions i del volum d’usuaris, i es fa per escrit abans de comprometre pressupost.