Sviluppo app per iOS e Android.

La prima domanda che facciamo a chi ci chiede un'app è se gli serve davvero. Un'app va installata, aggiornata, tenuta in vita su due store con due set di regole: è un impegno che continua per anni, non una consegna che finisce il giorno del rilascio. Se l'obiettivo è farsi trovare e raccogliere contatti, un sito fatto bene costa meno e rende prima.

L'app diventa la scelta giusta quando c'è un uso ripetuto e personale: notifiche che devono arrivare al momento giusto, accesso rapido a qualcosa che l'utente consulta ogni giorno, funzioni che hanno bisogno della fotocamera, della posizione o del funzionamento anche senza rete. Lì il vantaggio è reale e si sente subito.

È esattamente il caso di Medyom, la piattaforma di assistenza sanitaria a domicilio di cui curiamo il software: il paziente prenota, paga e segue l'operatore dal telefono, e l'app mobile affianca la piattaforma web invece di duplicarla. Quel progetto è la ragione per cui conosciamo da vicino i problemi veri dello sviluppo mobile — le disponibilità sincronizzate, i pagamenti, le notifiche che non devono arrivare due volte.

Sviluppiamo con Flutter. Significa che la stessa base di codice produce l'app per iPhone e quella per Android, con un'interfaccia fluida su entrambe. Non è un compromesso al ribasso: è il modo per non pagare due volte lo stesso lavoro e, soprattutto, per non ritrovarsi fra un anno con due app che si sono allontanate l'una dall'altra.

Quando serve, l'app parla con un back-end che costruiamo noi: autenticazione, dati in tempo reale, pagamenti, notifiche push. Usiamo Firebase e Stripe dove hanno senso, e soluzioni su misura dove i servizi pronti diventano una gabbia. Anche qui vale la regola di sempre: la tecnologia la scegliamo in base al problema, non in base a cosa è di moda.

La pubblicazione sugli store la gestiamo noi, comprese le parti noiose: schede, screenshot, informative sulla privacy, revisioni rifiutate da Apple e da rifare. È la fase in cui più progetti si arenano, ed è meglio che se ne occupi chi l'ha già attraversata.

Un'app non è finita quando è online. I sistemi operativi cambiano ogni anno, le librerie vanno aggiornate, gli store introducono requisiti nuovi. Un progetto lasciato fermo per dodici mesi smette semplicemente di funzionare, e rimetterlo in piedi costa più che tenerlo aggiornato.

Per questo, quando prendiamo in carico un'app, mettiamo in conto la manutenzione fin dal preventivo e ne parliamo apertamente prima di iniziare. Preferiamo dirti un numero onesto all'inizio piuttosto che presentarti un conto a sorpresa il secondo anno.

Vale anche il contrario: se hai già un'app e chi l'ha costruita non c'è più, possiamo riprenderla in mano. Prima la guardiamo davvero — codice, dipendenze, stato degli store — e poi ti diciamo se conviene recuperarla o rifarla. La risposta non è sempre quella che ci farebbe comodo vendere.

Il prezzo di un'app non dipende dal numero di schermate ma da quanto deve succedere dietro. Un'app che mostra contenuti e raccoglie richieste è un progetto contenuto; un'app con account utente, pagamenti, disponibilità sincronizzate in tempo reale e un pannello di gestione è un'altra cosa, perché ogni funzione va anche protetta, testata e mantenuta.

Pesano poi le integrazioni con i sistemi che già usi — gestionali, CRM, strumenti di fatturazione — soprattutto quando quei sistemi non sono stati pensati per parlare con l'esterno. È la voce che più spesso viene sottovalutata nei preventivi, e quella che più spesso fa saltare i tempi.

Noi preferiamo affrontarla all'inizio: prima di fare un numero guardiamo davvero cosa c'è da collegare. Se serve, proponiamo una prima versione ridotta all'essenziale, da mettere in mano agli utenti presto e far crescere con quello che impari usandola. Costruire tutto al buio per sei mesi è il modo più affidabile per costruire la cosa sbagliata.