Native e cross-platform per iOS e Android. Arrivare sugli store è la parte facile: quella difficile è che qualcuno la riapra il giorno dopo.
analizza --uso "cosa fa la persona in 30 secondi"
1 sola mano · schermo piccolo · rete incerta
verifica --serve-davvero-un-app
se basta consultare informazioni, un sito costa una frazione
./store --requisiti
[ok] account Apple e Google intestati a te
[ok] tempi di revisione previsti in pianificazione
in attesa
$ ./app --giorno 30
Una schermata iniziale non ha spazio infinito e nessuno la riordina per gentilezza. Nei primi giorni dopo l'installazione le app che non danno un motivo per riaprirle spariscono da sole. Guarda.
20 app ancora aperte
Ne restano 3. Il lavoro è essere una di quelle.
// quando serve
Pubblicare è facile. Difficile è meritarsi un posto nella schermata iniziale di qualcuno. Se non riconosci almeno tre di questi punti, probabilmente ti serve un sito fatto bene.
// cosa costruiamo
Cambia chi la usa, e cambia tutto: interfaccia, priorità, perfino la scelta della tecnologia.
Prenotazioni, ordini, fidelizzazione, assistenza. Il canale diretto con chi ti sceglie, senza intermediari che si prendono una percentuale.
Rilievi, checklist, rapportini, magazzino, firme. Funzionano anche senza rete e si sincronizzano quando il segnale torna.
Il compagno mobile di un gestionale o di un portale: stessi dati, stessa logica, interfaccia pensata per il telefono.
Non abbiamo una tecnologia da difendere. Una base di codice quando conviene, due quando servono prestazioni o sensori.
// come ci arriviamo
La revisione di Apple e Google è variabile e non dipende da noi: la mettiamo in conto dall'inizio, insieme al margine per un'eventuale richiesta di modifica.
Chi la userà, dove, con quanta rete e con quante mani libere. Da qui esce anche l'onestà: a volte la risposta è che un'app non serve.
Un flusso vero che si tocca sul telefono, non slide. Lo provi con chi la userà prima che esista codice definitivo.
Build installabili ogni due settimane su TestFlight e canale interno Android. Si prova sul dispositivo vero, non nel simulatore.
Schede store, screenshot, privacy label, revisione. Poi manutenzione con un accordo scritto, o formiamo il tuo team.
$ cat stack.json
$ ./domande --frequenti
Sì, e devono essere intestati a te, non a noi: la scheda sugli store, le recensioni e gli incassi devono restare tuoi anche se un domani cambi fornitore. Ti guidiamo nell'attivazione e nella configurazione, ma gli account sono vostri.
Allo sviluppo va aggiunto il tempo di revisione degli store, che è variabile e non dipende da noi. Lo mettiamo in conto nella pianificazione fin dall'inizio, insieme al margine per un'eventuale richiesta di modifica.
Se serve, sì. È una decisione che va presa all'inizio perché cambia l'architettura: aggiungerla dopo costa molto più che prevederla subito.
Possiamo occuparcene noi con un accordo di manutenzione, oppure formiamo il vostro team. Gli account store e le credenziali sono vostri fin dal primo giorno, quindi la pubblicazione non dipende mai da noi.
Dipende da cosa deve fare. Cross-platform conviene quando l'app è fatta di schermate, dati e flussi: tempi e costi si riducono davvero. Nativo conviene quando servono prestazioni grafiche, uso intensivo dei sensori o integrazioni profonde con il sistema. La decisione la prendiamo insieme in discovery, con i motivi scritti.
Le variabili sono quante schermate, quante integrazioni e se serve funzionare offline. Diamo un numero dopo il prototipo, quando il perimetro è visibile: prima sarebbe una scommessa travestita da stima.
fymera init --progetto "il tuo"
Trenta minuti in video per capire chi la userà e se ha senso farla. Se ti basta un sito, te lo diciamo.
