Abans de demanar pressupostos, aclareix què vols
Cap empresa es pot comparar bé amb una altra si cadascuna ha pressupostat una app diferent. Abans de la primera reunió, convé tenir clar:
- Què vols aconseguir amb l'app i com sabràs que funciona.
- Qui la farà servir: clients, professionals o el teu propi equip.
- El que és imprescindible per a la primera versió i el que pot esperar.
- Amb quins sistemes ha de parlar: un ERP, un CRM, un inici de sessió corporatiu.
- Qui decideix a la teva empresa i qui estarà disponible per revisar l'avenç.
Així, totes les empreses pressuposten el mateix i les diferències entre propostes diuen alguna cosa. La guia de cost té una llista completa del que convé portar preparat.
Estudi petit, agència gran, freelance o equip propi
No hi ha una opció millor per a tothom. El que canvia és qui fa la feina i quant t'hi implica a tu:
- Un estudi petit: parles amb les persones que dissenyen i programen l'app. Encaixa quan vols tracte directe i continuïtat, i l'app la pot portar un equip reduït.
- Una agència gran: té més gent i pot portar diversos fronts alhora (marca, campanyes, l'app). Encaixa en projectes molt grans o quan l'app és una peça d'alguna cosa més àmplia. Pregunta qui programarà la teva app i si l'equip és propi o subcontractat.
- Un freelance: pot ser l'opció més econòmica per a una cosa acotada. Mira què passa si no està disponible i qui s'encarrega del backend, del disseny i de la publicació.
- El teu propi equip: té sentit si l'app és el centre del teu negoci i la faràs evolucionar sempre. Compta amb el temps de contractar i amb que calen diversos perfils (disseny, iOS i Android, backend).
Start.cat és un estudi petit i sènior: el mateix equip porta el projecte del primer esbós al manteniment.
Què preguntar a la primera reunió
- Qui farà l'app? Les persones concretes, si l'equip és propi i si alguna part se subcontracta.
- Amb quina tecnologia? Si serà nativa, amb una base de codi per plataforma, o multiplataforma, com React Native o Flutter, amb una sola base per a iOS i Android. Totes dues opcions són vàlides; l'important és que t'expliquin per què la trien per a la teva app. Nosaltres fem servir React Native i baixem a codi natiu quan cal.
- De qui és el codi? Hauria de quedar per escrit al contracte que el codi i el disseny són teus en acabar. Amb nosaltres, el codi és del client.
- A nom de qui es publica l'app? El més habitual és que els comptes de desenvolupador d'Apple i Google siguin teus, a nom de la teva empresa: així l'app és teva encara que un dia canviïs de proveïdor.
- Què passa després del llançament? Qui manté l'app al dia amb cada versió d'iOS i Android, quant costa i què inclou.
- Quines apps ha publicat? Demana veure-les a les stores, no només en captures, i si continuen actualitzades.
Com és un procés sa
El que hauria de passar entre la primera trucada i l'app publicada:
- Una conversa per entendre el projecte: objectius, usuaris i limitacions. En el nostre cas, una trucada de 30 minuts.
- Una proposta per escrit amb abast, calendari i pressupost, sense lletra petita.
- Un prototip de les pantalles clau abans de programar. Canviar una pantalla al prototip costa minuts; a l'app ja programada, dies.
- Desenvolupament en iteracions curtes, amb versions de prova que pots instal·lar al teu mòbil des del principi. Si no veus l'app fins al final, és un senyal d'alerta.
- Publicació a l'App Store i Google Play, amb les fitxes, els formularis de privacitat i les revisions d'Apple i Google.
- Manteniment, perquè l'app continuï funcionant amb les versions noves d'iOS i Android.
Com a orientació, una app amb l'essencial triga de 2 a 3 mesos i una amb backend a mida, de 3 a 5 mesos; les que es connecten amb sistemes corporatius, més. Els detalls són a la guia de cost.
Dades, RGPD i on s'allotgen
Gairebé totes les apps tracten dades personals: un registre, un correu, una ubicació. Pregunta:
- On seran els servidors. Amb proveïdors a la Unió Europea, la protecció de dades és més senzilla. Nosaltres allotgem els backends principalment a Clouding.io, un proveïdor de Barcelona amb els servidors a Espanya.
- Si signareu un contracte d'encàrrec del tractament. Qui construeix i allotja l'app tracta dades per compte de la teva empresa, i el RGPD demana aquest contracte.
- Quines dades recull l'app i per què. Recollir només el necessari és més segur i més fàcil de justificar.
Si l'app tracta dades de salut, els requisits pugen: ho expliquem a la guia d'apps per a estudis clínics.
Senyals d'alerta en un pressupost
- Una xifra sense desglossament. Si no saps què inclou, no el pots comparar amb un altre.
- Hi falta el backend, el panell, les proves o la publicació. Si el més barat no ho inclou, ho pagaràs després.
- No diu res del manteniment. Una app sense manteniment deixa de funcionar bé en un o dos anys.
- No diu de qui és el codi ni a nom de qui es publica l'app.
- Un termini molt curt sense prototip ni versions de prova. El que és ràpid sense revisions sol acabar en canvis cars al final.
- Preu tancat per a un abast obert. Si l'abast no és clar, el preu tancat acabarà en discussions o en retallades.
Exemples d'apps publicades
Perquè vegis com és un projecte real, aquestes són algunes apps que hem fet:
- Club RUBI: app de fidelització per a professionals de la construcció, a les stores des de 2018.
- Compo Expert: catàleg de fertilitzants amb eines agronòmiques, sincronitzat amb els sistemes de l'empresa.
- Cohorte ARCA: seguiment mensual d'una cohort d'infants i adolescents amb asma, per a l'Institut de Recerca Hospital del Mar, a l'App Store des de 2017.
- La Teva Decisió: app i portal de decisió compartida per a pacients amb càncer de pròstata localitzat.
- D2M: calculadora de racions de proteïna per a l'Hôpital Robert-Debré de París.
Si véns de l'àmbit de la salut o la recerca, mira també apps per a salut i recerca.