Sviluppo app a Trento. Il lancio è metà del lavoro.
Sviluppo software:
Sviluppo app Trento:
per i clienti o per chi ci lavora
Le app aziendali si dividono in due famiglie che hanno poco in comune, e conviene capire subito in quale si sta.
Ci sono le app rivolte al pubblico: fidelizzazione, ordini, prenotazioni, servizi. Vivono negli store, competono con tutto il resto, e il problema principale è convincere qualcuno a installarle.
Poi ci sono le app per chi lavora in azienda: raccolta dati in cantiere, magazzino, assistenza tecnica sul campo, ordini per i venditori. Qui il problema di farsi installare non esiste, e il valore si misura in tempo risparmiato.
Le seconde sono meno affascinanti e rendono quasi sempre di più. Sono anche la parte di sviluppo app a Trento che ci viene chiesta più spesso dalle aziende che ci conoscono.
Un’app che fa risparmiare mezz’ora al giorno a venti persone si ripaga da sola, e non deve piacere a nessuno.
Quando serve davvero un’app:
e quando basta un sito
Cominciamo dalla parte che ci fa perdere qualche progetto, così il resto si legge con più fiducia.
Un sito basta quando il bisogno è informarsi, leggere, contattare, comprare ogni tanto. Un sito moderno fa tutto questo, si apre senza installare niente e si trova su Google. Se qualcuno vi propone un’app per queste cose, chiedetevi perché.
Serve un’app quando c’è almeno una di queste ragioni: uso frequente e ripetuto, funzionamento anche senza connessione, accesso a fotocamera, posizione o lettore di codici in modo intensivo, notifiche che devono arrivare davvero, uso sul campo da parte di persone che lavorano.
Fuori da questi casi l’app è un costo che si aggiunge al sito, non che lo sostituisce.
Chi non vi fa questa domanda vi sta vendendo quello che sa fare.
Native o multipiattaforma:
cosa cambia davvero
È la scelta tecnica che pesa di più sul costo, e va fatta guardando il progetto, non le mode.
Le app che servono davvero nascono da come si lavora, e attorno a Trento si lavora in modi diversi.
In Trentino turismo di montagna, agroalimentare di qualità, vino e un polo di ricerca e tecnologie convivono. Un mercato attento alla sostenibilità e al racconto del territorio.
Se quello che serve è un sito e non un’applicazione, la pagina giusta è realizzazione siti internet a Trento.
Nativa. Un’app scritta per iOS e una per Android, con gli strumenti di ciascun sistema. Resa migliore, accesso completo alle funzioni del telefono, prestazioni superiori. In cambio sono due lavori, e due manutenzioni.
Multipiattaforma. Un solo codice che diventa entrambe le app. Costa in modo sensibilmente inferiore e oggi la differenza di qualità, per la maggior parte delle app gestionali e di servizio, non si nota.
La multipiattaforma è la scelta giusta nella maggioranza dei casi che incontriamo. La nativa resta necessaria quando servono prestazioni grafiche spinte, uso intensivo di funzioni particolari del telefono o integrazioni profonde col sistema.
Chiedete sempre perché vi viene proposta una strada. Se la risposta parla di voi e non della tecnologia, è una buona risposta.
Il team:
Continuità:
l’app vive finché qualcuno la segue
Su un’app la continuità non è un valore aggiunto, è un requisito tecnico.
Ogni anno arrivano nuove versioni dei sistemi operativi e nuove regole degli store. Serve qualcuno che se ne accorga per tempo e intervenga prima che l’app venga rimossa o smetta di aprirsi sui telefoni nuovi.
Da noi il progetto ha un referente che resta lo stesso, e il codice è vostro e documentato: se un domani volete portarlo altrove, potete farlo senza ricominciare.
Siamo oltre quaranta persone in un unico studio a Sarezzo, vicino a Brescia, e operiamo su Trento come nel resto d’Italia.
Un’app abbandonata dal suo sviluppatore ha una vita di circa due anni. Poi va rifatta.
Il preventivo:
come lo costruiamo
Facciamo sempre due passaggi, e il primo costa poco.
Prima si definisce cosa deve fare l’app, schermata per schermata, con le funzioni elencate e quelle escluse scritte nero su bianco. È un lavoro di qualche giorno che produce un documento vostro, utilizzabile anche per chiedere altri preventivi.
Poi si stima lo sviluppo su quel documento. A quel punto il numero è affidabile, perché si sa cosa si sta contando.
Chi dà una cifra prima di questo passaggio sta indovinando, e il conto vero arriva a metà progetto sotto forma di varianti.
Nel preventivo mettiamo separati: sviluppo, parte server, pubblicazione sugli store e mantenimento annuale.
Quattro numeri invece di uno. È meno comodo da leggere e molto più difficile da sbagliare.
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à.
È 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.
Notifiche:
Utili quando comunicano qualcosa che cambia: uno stato, un turno, una scadenza. Usate per promuovere, fanno disinstallare.
Store:
Account intestati a voi, revisione e possibili rifiuti, adempimenti su privacy e dati. Una fase con tempi propri.
Prove:
Su telefoni veri e con le persone che useranno l’app. Cinque utenti per due settimane dicono più di qualsiasi riunione.
Mantenimento:
Costo annuale non evitabile: i sistemi si aggiornano e un’app ferma smette di funzionare. Va messo a budget dall’inizio.
Proprietà:
Codice e account sono vostri, documentati. Se un domani il progetto va altrove, non si ricomincia da zero.
Diffusione:
Come farla installare, se è rivolta al pubblico. Va deciso prima di svilupparla, non dopo il lancio.
Raccontaci cosa dovrebbe fare. Ti diciamo se serve un’app, se basta un sito e quanto costerebbe l’una o l’altra strada.
Le recensioni dei clienti che ci hanno scelto.
Sviluppiamo strategie di comunicazione, marketing digitale, branding e innovazione su misura, integrando competenze creative e tecnologiche per accompagnare aziende e organizzazioni nel raggiungimento dei propri obiettivi.
Diventa il nostro prossimo cliente soddisfatto
Inviaci la tua richiesta, possiamo conoscerci in videoconferenza: indicaci il giorno e l’ora che preferisci nel form qui a fianco.
