Il progetto non compila più
Flutter, Xcode, Gradle, Kotlin, CocoaPods o altre dipendenze possono essere diventati incompatibili con l'ambiente attuale.
Prendo in carico applicazioni Flutter, iOS e Android già esistenti, anche quando sono state sviluppate da altri, sono diventate difficili da mantenere o hanno perso il loro sviluppatore.
A volte sì. Molto spesso no. Un'app esistente porta con sé la sua storia: versioni del framework, dipendenze, configurazioni, account, certificati, backend e decisioni tecniche prese negli anni.
Flutter, Xcode, Gradle, Kotlin, CocoaPods o altre dipendenze possono essere diventati incompatibili con l'ambiente attuale.
Lo sviluppatore non è più disponibile, il repository è incompleto o gli accessi necessari sono rimasti in mano a qualcun altro.
Signing, certificati, requisiti di Apple e Google e nuove versioni dei sistemi operativi possono trasformare una release in un problema.
Questo servizio è pensato per chi ha già investito in un'app mobile e vuole continuare a usarla, aggiornarla e farla evolvere senza dover ricominciare da zero.
L'app è online, ma manca qualcuno che ne conosca davvero il codice e possa occuparsene nel tempo.
Un cambio di SDK o una nuova release di iOS/Android non dovrebbe fermare un prodotto che continua a servire i suoi utenti.
Prima di decidere di riscrivere tutto, vale la pena capire cosa c'è realmente nel progetto e quanto costa riportarlo sotto controllo.
Puoi avere un riferimento tecnico esterno per manutenzione, aggiornamenti, release e piccoli interventi evolutivi.
Non propongo un canone sulla base del nome del framework. Ogni app ha una storia a sé. Il percorso parte sempre da una verifica tecnica.
Una prima verifica tecnica per capire se il progetto è prendibile in carico e individuare subito eventuali blocchi evidenti.
Se serve andare più in profondità, definiamo un'analisi tecnica completa e il relativo perimetro dopo il check iniziale.
Recupero, configurazione, aggiornamento e stabilizzazione del progetto fino a renderlo nuovamente gestibile e rilasciabile.
Una volta presa in carico l'app, possiamo definire un rapporto continuativo per manutenzione, aggiornamenti, release ed evoluzione.
Un'app può sembrare semplice da mantenere e richiedere invece giorni solo per essere riportata a uno stato compilabile e verificabile. Per questo non ha senso promettere un prezzo di manutenzione prima di aver visto il progetto.
Repository, stack e versioni, dipendenze, ambiente di build, configurazioni iOS e Android, Firebase e servizi collegati, accessi, signing, store e possibilità reale di produrre una build.
Una prima risposta concreta: possiamo procedere oppure no, quali sono le criticità principali e quale percorso ha senso seguire per il progetto.
L'unico costo definibile prima di vedere il progetto è quello del tempo necessario per fare il primo check. Tutto ciò che viene dopo dipende da quello che troviamo.
Una verifica iniziale per capire se l'app può essere presa in carico e quale livello di analisi o intervento è realmente necessario.
Se serve un Technical Assessment, una fase di stabilizzazione o un intervento specifico, il lavoro viene definito e quotato sulla base di ciò che abbiamo effettivamente trovato.
Possiamo definire un piano di Ongoing Maintenance con un canone concordato in base a complessità, criticità e reale necessità di assistenza.
Ogni app ha una storia a sé. Il prezzo finale delle attività successive viene definito solo dopo aver visto il progetto.
Raccontami brevemente che tipo di app è, su quale piattaforma gira e cosa non sta funzionando. Il primo passo è capire cosa abbiamo davanti.
Prenota una consulenza dal sito principale oppure contattami per iniziare dal check tecnico.
Prenota una consulenza →