Sviluppo app che arrivano allo store — e sul campo.

App che fanno parte di un sistema

DeenLytics sviluppa app come parte di un sistema funzionante, non come download isolati. La maggior parte delle app che vale la pena costruire ha bisogno di un backend per i dati, di un pannello di amministrazione per chi gestisce l'azienda e di un'API che li collega. Costruiamo tutti e tre. Iqra Billing Software è un'applicazione web Laravel con un'app Android nativa per gli incassi sul campo e un gateway di pagamento bKash integrato. L'app da campo di Canberra Limited permette agli agenti di inserire ordini sulle giacenze reali direttamente dal negozio, mentre la sede vede gli ordini arrivare in tempo reale.

Partiamo da cosa deve cambiare l'app

Un'app è un modo costoso di risolvere il problema sbagliato. Prima di definirne il perimetro chiediamo cosa deve cambiare per l'azienda — incassi registrati sul posto invece che a fine mese, ordini che smettono di essere ribattuti, un servizio raggiungibile dal telefono che le persone hanno già in mano — e se un'app sia davvero la strada più breve. A volte non lo è, e te lo diciamo. Quando lo è, quella prima conversazione decide cosa deve fare la versione uno e cosa può aspettare la versione due.

DeenLytics è un team di agenzia, non un singolo sviluppatore freelance. Chi disegna le schermate, chi costruisce l'API, chi scrive il codice Android e chi mantiene sane le release lavora nello stesso team: per questo un progetto può iniziare come app e finire come sistema senza cambiare mani a metà strada.

Nativa, cross-platform o web app installabile?

Non esiste un'unica risposta giusta, e non ti spingeremo verso quella più comoda per noi. Ecco come decidiamo:

1. 01

   Android nativo (Kotlin)

   quando l'app ha bisogno di accesso all'hardware, affidabilità offline, lavoro in background o un SDK di pagamento che richiede un ambiente nativo. L'app di incasso di Iqra Billing è nativa proprio per questi motivi.

2. 02

   Cross-platform (React Native / Flutter)

   quando servono iOS e Android da un solo codice con una sensazione nativa, e l'app è fatta soprattutto di schermate, moduli e dati.

3. 03

   Web app installabile (PWA)

   quando il pubblico è interno o conosciuto, l'app si usa da smartphone ma non ha bisogno della distribuzione sugli store, e vuoi aggiornarla senza passare dalla revisione. L'app da campo di Canberra è costruita così: ogni nuova versione raggiunge tutti gli agenti nel momento in cui la pubblichiamo.

Cosa include un progetto app tipico

1. 01

   Analisi e perimetro scritto: ruoli utente, schermate, dati, integrazioni e cosa deve fare la versione uno.

2. 02

   Un prototipo navigabile entro 72 ore, così il flusso è concordato prima di scrivere codice.

3. 03

   API backend (Laravel) con autenticazione, accessi per ruolo e un elenco di endpoint documentato.

4. 04

   Pannello di amministrazione per l'azienda

   di solito Next.js — per gestire utenti, contenuti, ordini o ciò di cui l'app si occupa.

5. 05

   L'app stessa, testata su dispositivi reali con le dimensioni di schermo e le versioni del sistema operativo che i tuoi utenti usano davvero.

6. 06

   Integrazione dei pagamenti dove serve: bKash, Nagad, SSLCommerz, Stripe.

7. 07

   Pubblicazione sugli store, gestione delle release e segnalazione dei crash.

8. 08

   Supporto post-lancio: aggiornamenti del sistema operativo, cambi di policy degli store, nuove funzionalità.

Pronte per l'Europa, costruite per il Bangladesh

Dalla sede di Biella serviamo clienti italiani ed europei che hanno bisogno di app iOS e Android curate, con gestione dei dati conforme al GDPR e pubblicazione in italiano e inglese. Da Dhaka costruiamo per un mercato in cui le app devono funzionare su dispositivi Android di fascia media, con dati mobili incostanti, in bengalese e con metodi di pagamento locali. La disciplina è la stessa: bundle leggeri, tolleranza all'offline, tipografia chiara e flussi di pagamento che le persone riconoscono.

Sicurezza e dati

Ogni app parla con un'API, ed è nell'API che vive la vera sicurezza. Usiamo autenticazione basata su token, autorizzazione per ruolo su ogni endpoint, validazione dell'input, limiti di frequenza e trasporto cifrato. I gateway di pagamento vengono verificati lato server, mai fidandosi del dispositivo. I segreti non vengono mai inclusi nel bundle dell'app.

Dopo la prima release

Pubblicare la versione uno è metà del lavoro. Android e iOS cambiano ogni anno, gli SDK di pagamento vengono deprecati e il primo mese di uso reale insegna sempre qualcosa che il piano non prevedeva. Noi restiamo: aggiornamenti di sistema operativo e SDK, cambi di policy degli store, monitoraggio dei crash e una coda di piccoli miglioramenti rilasciati con regolarità, invece di una ricostruzione due anni dopo.