Sviluppo app a Treviso. Per fare una cosa, fatta bene.

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à.

Sì. È vostro, ve lo consegniamo e lo teniamo documentato.

Non lavoriamo con impianti chiusi che vi legano a noi: se un domani volete portare il progetto a un altro fornitore o gestirlo internamente, potete farlo senza rifare tutto.

Vale anche per gli account degli store, che sono intestati a voi, e per i server, che possono stare su infrastrutture vostre se preferite.

Lo diciamo perché il contrario è frequente e produce situazioni sgradevoli: aziende che devono rifare da zero un’app funzionante solo perché non hanno accesso a niente di quello che l’ha prodotta.

Sì, la maggior parte dei nostri clienti non è vicina a noi.

Siamo a Sarezzo, in provincia di Brescia, e seguiamo progetti in tutta Italia. Progettazione, sviluppo e prove si fanno a distanza senza perdere nulla.

C’è un’eccezione: le app per uso interno. Lì un sopralluogo serve davvero, perché bisogna vedere come si lavora, in che condizioni, con che tempi. Una raccolta dati progettata a tavolino e non provata sul campo si scopre inadatta al primo giorno di uso vero.

Per quei progetti veniamo, almeno una volta all’inizio e una durante le prove.

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.