La resposta curta
Un plec tècnic per a una app mòbil falla gairebé sempre pel mateix: descriu una solució en lloc d'un resultat. Quan el plec diu quina tecnologia fer servir, quines pantalles fer i quantes hores dedicar, ha decidit pel licitador i ha renunciat a comparar propostes de debò.
La Llei de contractes del sector públic empeny justament en la direcció contrària, i dona dues eines que s'utilitzen poc:
- Consultes preliminars del mercat (article 115), per parlar amb operadors econòmics abans d'iniciar el procediment i preparar correctament la licitació.
- Prescripcions tècniques neutrals (article 126), que prohibeix les que afavoreixin un licitador concret, incloses referències a marques, patents o procediments particulars, i obliga a basar-se en característiques de rendiment o requisits funcionals.
És a dir: la llei ja diu que el plec descrigui què ha d'aconseguir el sistema, no amb què es construeix.
Abans d'escriure: la consulta preliminar
És l'eina més infrautilitzada de la contractació pública de programari. Permet preguntar al mercat què és viable, en quins terminis i amb quins riscos, abans de fixar res.
Serveix per evitar els tres defectes que arruïnen plecs d'app:
- Terminis incompatibles amb l'abast descrit.
- Requisits desproporcionats per al risc real del sistema.
- Especificacions que només pot complir un producte concret, moltes vegades sense que ningú ho pretengués.
I no compromet a res: informa els operadors dels plans de contractació i els seus requisits, cosa que a més millora la qualitat de les ofertes que arriben.
Els criteris: qualitat, no només preu
L'article 145 exigeix que el disseny dels criteris d'adjudicació permeti obtenir serveis de gran qualitat, incorporant aspectes qualitatius, mediambientals, socials i innovadors vinculats a l'objecte del contracte, buscant la millor relació qualitat-preu i no el preu més baix.
Per a una app, això es tradueix en criteris que es puguin puntuar sense arbitrarietat:
- Accessibilitat: nivell compromès i mètode de verificació. És obligació legal, amb la seva declaració i el seu procediment de reclamació — és a accessibilitat en una app pública.
- Seguretat: mesures conformes a la categoria del sistema a l'Esquema Nacional de Seguretat, amb les evidències que es lliuraran. La categoria la determina l'organisme, i decideix la resta — és a l'ENS també t'aplica a tu.
- Pla de traspàs: què es lliura i com es garanteix que un altre equip pugui continuar.
- Metodologia i lliurables verificables per fita, no per hores.
- Equip compromès, amb mecanisme real si canvia. Un currículum a l'oferta que desapareix al mes dos és el problema clàssic.
El que ha d'estar al plec sí o sí
- Titularitat del codi i dels comptes. Repositori i comptes de desenvolupador a nom de l'organisme, amb el proveïdor convidat. Sense això, l'administració queda captiva — el detall del que costa sortir-ne és a transferir una app a un altre compte.
- Categoria ENS del sistema, determinada abans de licitar.
- Nivell d'accessibilitat i qui audita.
- Requisits d'identitat: si cal identificar, signar, o totes dues coses — no és el mateix, i és a integrar Cl@ve.
- Versions mínimes de sistema operatiu a suportar, com a decisió de cobertura ciutadana.
- Manteniment evolutiu i correctiu, amb el seu abast. Una app sense manteniment contractat deixa de funcionar sola quan canvien els requisits de les botigues.
- Traspàs com a lliurable, no com a cortesia final.
El que no hi hauria de ser
- El framework. Fixar la tecnologia redueix la competència i trasllada a l'organisme una decisió que hauria de justificar qui la mantindrà. Si hi ha un motiu real —un equip intern que ja hi treballa—, s'expressa com a requisit de mantenibilitat, no com a marca.
- El nombre de pantalles. És la pitjor unitat de mesura possible: premia partir pantalles i castiga simplificar.
- Les hores. Comprar hores és comprar presència, no resultat.
- Requisits copiats d'un altre plec sense revisar. Es nota, i generen preguntes que endarrereixen el procediment.
Els lots: obligatoris, i amb un advertiment honest
L'article 99 inverteix la regla anterior: dividir en lots és la norma, i cal justificar a l'expedient la no divisió, per facilitar l'accés de les pimes.
L'advertiment tècnic, que convé posar per escrit quan es justifiqui: partir app, backend i disseny en lots diferents trasllada el risc d'integració a l'organisme. Si es fa, cal designar qui integra i amb quina autoritat, o el resultat són tres adjudicataris assenyalant-se entre ells quan alguna cosa falla.
Justificar la no divisió per integració tècnica és legítim si s'argumenta. El que no funciona és dividir i no nomenar un responsable d'integració.
Com comprovar que el plec és bo
Tres proves ràpides abans de publicar:
- Es pot complir amb dues tecnologies diferents? Si no, és un plec dirigit encara que no fos la intenció.
- Cada requisit és verificable? Si no es pot comprovar en el lliurament, no hauria de puntuar.
- Un licitador podria estimar-ho sense trucar? Si li falten dades crítiques —categoria ENS, entorns, integracions—, les ofertes vindran amb risc incorporat, i aquest risc el paga l'organisme.
Quan cal criteri tècnic independent per redactar o avaluar, és exactament la feina que fem com a CTO as a Service, i el context complet és a apps per al sector públic.
Font primària, consultada el 14 d'agost de 2026: Llei 9/2017, de contractes del sector públic, articles 99, 115, 126 i 145.
