Packly
Un travel planner con AI progettato, sviluppato e pubblicato in autonomia su Google Play. Non una storia di ostacoli: un esercizio di architettura Android fatta bene, dal primo modulo.
In 30 secondi
Packly pianifica i viaggi con l'AI: packing list intelligenti, itinerari generati, spese multi-valuta. L'ho costruita da solo, dall'inizio alla fine, come esercizio tecnico preso sul serio: un'app greenfield strutturata come la codebase di un grande team, con un'architettura nata dallo studio di ciò che Google stessa raccomanda oggi. Questa pagina racconta quell'architettura e il perché di ogni scelta.
Cos'è, e perché esiste
Packly dà a ogni viaggio tre superfici: una packing list con template e suggerimenti AI, un itinerario pianificato giorno per giorno (a mano o generato) e il tracciamento spese con cambi in tempo reale. È su Google Play in 10+ lingue, con un piano gratuito e un abbonamento Pro via Play Billing.
Nasce come esercizio: volevo imparare a integrare davvero l'AI in un progetto Android, e un'app greenfield senza legacy era l'occasione per applicare lo stato dell'arte senza compromessi. Prima di scrivere il primo modulo ho studiato cosa raccomanda oggi Google stessa, prendendo ispirazione da Now in Android, il loro progetto vetrina open source, e adattandolo a questo prodotto.
Il mio ruolo
Tutto è mio: design dell'interfaccia, sviluppo, test, release e gestione dello store. E proprio perché non ci lavora nessun altro, l'architettura conta di più, non di meno: convenzioni e confini tra moduli fanno il lavoro che altrimenti farebbe la code review di un team.
L'architettura
30+ moduli Gradle con una regola di scoping rigorosa
L'app è divisa in 6+ moduli feature (packing list, itinerario, spese...) e 20+ moduli core (UI kit, data, database, network, AI...). I moduli feature non dipendono mai tra loro, e il codice viene promosso a modulo core solo quando serve ad almeno due feature. I confini restano onesti, le build parallele, e ogni pezzo ha una casa sola e chiara.
Convention plugins: la build logic scritta una volta sola
Quattro plugin Gradle custom (library, compose, hilt, feature) vivono in build-logic e si applicano a ogni modulo. Creare un modulo nuovo richiede minuti e zero copia-incolla, e una modifica di configurazione arriva ovunque in un colpo solo. È questo che rende 30+ moduli gestibili da una persona.
Un solo paradigma di UI, senza eccezioni
100% Jetpack Compose con Material 3 e navigazione type-safe (Navigation 3 con route serializzabili). Ogni schermata è un ViewModel che espone un singolo stato UI immutabile via StateFlow, con gli eventi che fluiscono in una direzione. Nessuna schermata devia dal pattern, così ogni schermata si legge allo stesso modo.
Astrazione dove compra testabilità
I repository sono internal dietro interfacce pubbliche, e ogni modulo Hilt vive accanto all'implementazione che collega: le feature vedono solo contratti. I test unitari usano fake, non framework di mocking. Un compromesso deliberato: il domain model coincide con l'entity di Room, zero layer di mapping, perché in un'app di queste dimensioni i mapper sarebbero cerimonia, non protezione.
L'AI come componente sostituibile
Tre provider LLM (Anthropic, OpenAI, Google) stanno dietro un'unica interfaccia con fallback automatico: se uno fallisce, risponde il successivo. Il resto dell'app non sa quale modello stia parlando. Le chiavi non viaggiano mai nell'APK: arrivano via Remote Config, protette da Play Integrity.
I numeri
- 30+ moduli Gradle, 6+ feature e 20+ core
- 4 convention plugin custom in build-logic
- 100% Jetpack Compose, Material 3
- 10+ lingue sul Play Store, release via Fastlane
- Su Google Play con un modello di business reale (piano gratuito più abbonamento Pro). Niente numeri di utenti, per scelta: l'app è giovane, e il suo valore in questo portfolio è l'ingegneria.
Cosa ho imparato
Lavorando da soli la disciplina deve vivere nella struttura, non nella memoria: convenzioni, confini tra moduli e plugin sono ciò che mantiene il centesimo modulo pulito quanto il primo.
L'esercizio ha ripagato oltre l'app: pattern production-grade per l'integrazione LLM (provider sostituibili, fallback, distribuzione dei secret) e un progetto di riferimento per il greenfield Android che posso difendere scelta per scelta.