Sviluppo app a Verona. Anche per dirti che non ti serve.

Dipende quasi tutto da una cosa: quante funzioni deve avere. Ogni schermata è progettazione, sviluppo e prove su due sistemi operativi.

Le altre variabili che pesano sono la scelta fra nativa e multipiattaforma, e soprattutto cosa c’è dietro: se l’app deve dialogare con i vostri gestionali, il lavoro sul server può costare quanto l’app.

C’è poi una voce che va tenuta separata e che quasi nessuno mette nel primo preventivo: il mantenimento annuale. Non è assistenza opzionale, è quello che tiene l’app pubblicata quando i sistemi si aggiornano.

Il nostro modo di lavorare è definire prima cosa deve fare l’app, schermata per schermata, e stimare su quello. Una cifra data prima di quel passaggio è un’ipotesi che cambierà.

Spesso sì, e prima di rifare guardiamo perché non viene usata.

Le cause ricorrenti sono tre. La prima: l’app fa cose che si potevano fare sul sito, quindi non c’era motivo di installarla. La seconda: fa troppe cose e quella utile è sepolta. La terza: funziona male sui telefoni di oggi perché nessuno l’ha aggiornata.

Nel terzo caso è manutenzione, e costa relativamente poco. Nel secondo si interviene togliendo, che è meno caro di quanto sembri. Nel primo caso, onestamente, la risposta giusta a volte è chiuderla e investire quei soldi sul sito.

Guardiamo i dati d’uso, se ci sono, e ve lo diciamo senza girarci intorno.

È la prima domanda che facciamo, e in parecchi casi la risposta onesta è che basta un sito.

Un sito moderno si apre senza installare niente, si trova su Google e fa quasi tutto: informare, prenotare, vendere, farsi contattare. Installare un’app invece è un ostacolo, e chi lo supera vuole qualcosa in più.

Un’app serve quando c’è uso frequente e ripetuto, quando deve funzionare senza connessione, quando usa in modo intensivo fotocamera, posizione o lettore di codici, quando le notifiche devono arrivare davvero, o quando la usano persone che lavorano sul campo.

Se il vostro caso non rientra in questi, l’app diventa un costo che si aggiunge al sito invece di sostituirlo, e la strada giusta è la realizzazione di un sito fatta bene. Preferiamo dirlo prima di prendere il lavoro.

Per la maggior parte dei progetti aziendali oggi la multipiattaforma è la scelta giusta.

Si scrive un codice solo che diventa sia l’app iOS sia quella Android: il costo scende in modo sensibile e la manutenzione è una invece di due. Per app gestionali, di servizio e di raccolta dati la differenza di qualità non si percepisce.

La nativa resta necessaria quando servono prestazioni grafiche spinte, uso molto intensivo di funzioni specifiche del telefono, o integrazioni profonde con il sistema operativo.

Non abbiamo una preferenza da difendere: valutiamo sul progetto. Quello che consigliamo è di chiedere sempre perché vi viene proposta una strada, e diffidare se la risposta parla della tecnologia invece che del vostro caso.

Per un’app essenziale, poche schermate e nessun collegamento con i vostri sistemi, dalle otto alle dodici settimane.

Per un’app aziendale con parte server, accesso utenti e dialogo con il gestionale, dai quattro ai sei mesi. La parte lunga raramente è l’app: sono i collegamenti e le prove sul campo.

A questi tempi va aggiunta la pubblicazione sugli store, che richiede una revisione da parte loro. Di solito è questione di giorni, ma può capitare un rifiuto da correggere, quindi conviene non fissare il lancio con margini stretti.

Lavoriamo per versioni successive: si mette in mano alle persone qualcosa di funzionante presto, così se serve cambiare direzione lo si scopre al secondo mese e non al quinto.

È la domanda giusta, e va fatta prima di firmare.

Un’app, a differenza di un sito, si degrada se nessuno la tocca. I sistemi operativi si aggiornano una o due volte l’anno e cambiano requisiti, permessi e componenti. Gli store impongono scadenze per adeguarsi, e un’app non aggiornata prima o poi viene rimossa o smette di aprirsi sui telefoni nuovi.

Quindi esiste un costo annuale anche se non aggiungete nessuna funzione. Va considerato parte del progetto, non un extra.

Nei nostri preventivi lo indichiamo dall’inizio con una cifra di riferimento. Le app che ci arrivano da fuori da sistemare sono quasi sempre app di cui nessuno aveva spiegato questa parte.

Sul vostro, sempre, ed è un punto su cui insistiamo anche quando all’inizio sembra un fastidio burocratico.

Gli account da sviluppatore hanno un costo annuale e vanno intestati alla vostra azienda. Un’app pubblicata sull’account del fornitore diventa un problema il giorno in cui volete cambiare fornitore: recensioni, storico e continuità degli aggiornamenti sono legati a quell’account.

Vi aiutiamo ad aprirli e configurarli, e li usiamo con le autorizzazioni che ci date.

Vale lo stesso per il codice: è vostro e documentato. Se un domani il progetto va altrove, chi lo riceve deve poterci lavorare senza ricominciare da zero.

Sì, e per molte app aziendali è la ragione principale per cui si fa un’app invece di un sito.

L’app tiene i dati sul dispositivo e li sincronizza quando la connessione torna. È la situazione tipica di chi lavora in cantiere, in capannone, in campagna o in zone con copertura scarsa.

La complessità sta nella sincronizzazione: cosa succede se due persone modificano la stessa cosa mentre sono scollegate, quali dati vincono, come si segnalano i conflitti. Sono decisioni da prendere all’inizio, perché determinano l’impianto.

È un lavoro che aggiunge costo, e nei casi in cui serve ripaga più di qualsiasi altra funzione.