Il brief reale
L’utente deve prendere una decisione economica prima di accettare un lavoro. I dati arrivano da fonti diverse, alcune voci cambiano spesso e il risultato deve poter diventare un documento leggibile dal cliente. Il rischio di prodotto non è soltanto sbagliare un’operazione: è nascondere un costo, confondere prezzo e margine o rendere il flusso troppo lento per l’uso quotidiano.
Ho quindi trattato RouteBudget come sistema decisionale, non come una lunga calcolatrice. La pagina RouteBudget EU conserva guide e contenuti operativi; qui descrivo esclusivamente il lavoro di prodotto e sviluppo, così i due domini non competono per la stessa ricerca.
Guarda il prodotto in funzione
Il video documenta una versione precedente dell’app: inserimento dei dati, risultati economici e passaggio al preventivo. Le immagini aggiornate qui sotto provengono dalla scheda attuale. La riproduzione parte solo dopo l’interazione.
Il video non può essere riprodotto. Apri il file MP4.
Versione 1.7.2: un flusso più leggibile
La scheda italiana verificata il 19/09/2026 descrive risultati spiegati, una data del trasporto facoltativa e lo scambio tra origine e destinazione. I prezzi carburante MIMIT mostrano fonte, data e verifica; l’inserimento manuale resta disponibile. Questi dati richiedono rete e non sono garantiti in tempo reale.
La data del trasporto resta distinta da quella di emissione del PDF. Sono disponibili tre calcoli gratuiti; Pro offre calcoli illimitati e documenti con logo, nome e dati aziendali. Le immagini seguenti sono materiali promozionali ufficiali dello Store, non acquisizioni dirette dello schermo.
1. Ridurre il problema senza impoverirlo
La prima scelta è stata separare ciò che l’utente inserisce, ciò che il sistema deriva e ciò che compare nel documento finale. Questo evita moduli interminabili e rende ogni risultato tracciabile.
- Input: dati del mezzo, distanza e parametri scelti dall’utente.
- Calcolo: voci aggregate e scenari economici.
- Decisione: punto di equilibrio, confronto tra scenari e valore proposto.
- Output: salvataggio locale e PDF condivisibile.
In un progetto custom questa fase vale più di aggiungere schermate: definisce quali dati devono restare coerenti quando l’utente modifica un singolo parametro.
2. Mostrare conseguenze mentre cambia un dato
Quando una persona modifica distanza, costo o scenario, il valore utile deve aggiornarsi senza costringerla a ricostruire il ragionamento. L’interfaccia mette quindi in relazione input e anteprima, poi consente di approfondire il dettaglio.
Ho evitato di presentare una sola cifra come verità assoluta. Tre scenari rendono visibile la differenza tra soglia minima, proposta consigliata e obiettivo ideale. Non sostituiscono il giudizio dell’utente: lo rendono più consapevole.
La cronologia versioni pubblica mostra anche lavoro meno visibile: navigazione più fluida, ripresa dei calcoli salvati, coerenza delle date, supporto a schermi piccoli, Dynamic Type, tema chiaro/scuro e interfaccia RTL. Questi interventi fanno parte del prodotto quanto la prima schermata.
3. Offline-first, con limiti dichiarati
Calcoli e archivio restano sul dispositivo e non richiedono un account. È una scelta di affidabilità e privacy: il lavoro principale continua anche con connettività debole e non dipende da un profilo cloud.
“Offline-first” non significa fingere che tutto funzioni senza rete. La distanza stradale automatica, i prezzi locali del carburante e gli abbonamenti richiedono connessione, come dichiara la scheda App Store. Rendere chiaro il confine evita promesse tecniche impossibili e permette di progettare fallback espliciti.
Per altri prodotti la decisione può essere diversa. Un gestionale collaborativo richiede spesso sincronizzazione, ruoli e audit log. La scelta corretta nasce dal contesto, non da una preferenza astratta per locale o cloud.
4. Il PDF è parte del flusso, non un accessorio
Un risultato utile sullo schermo non basta quando deve passare a un cliente. Il documento deve mantenere cifre, lingua, identità e struttura del calcolo salvato. RouteBudget consente di esportare il preventivo e, nella versione Pro, usare il logo aziendale.
Questa funzione ha richiesto attenzione alla continuità tra anteprima, archivio e documento. Gli aggiornamenti pubblicati includono correzioni specifiche per conservare il logo anche nei PDF esportati dall’archivio: esempio concreto di come test reali trovino problemi che un mockup non può mostrare.
5. Pubblicare significa gestire regole, non solo codice
Account sviluppatore, metadata, screenshot, privacy, acquisti in-app e App Review entrano nel lavoro prima del rilascio. Le App Review Guidelines di Apple richiedono un’app funzionante, informazioni corrette e un modello di pagamento coerente. L’approvazione non può essere promessa: si prepara il prodotto per ridurre motivi evitabili di rifiuto e si risponde alle verifiche.
RouteBudget è passato da una prima versione a miglioramenti su lingue, stabilità, accessibilità e recupero degli acquisti. Questo è il motivo per cui nei preventivi di sviluppo considero manutenzione e rilascio come parti separate: un’app pubblicata continua a vivere.
Cosa dimostra il progetto
| Esigenza | Risposta di prodotto |
|---|---|
| Molti dati collegati | Input separati, anteprima e dettaglio coerenti |
| Decisione non binaria | Tre scenari confrontabili |
| Connettività variabile | Core e archivio locali; rete solo dove necessaria |
| Consegna al cliente | PDF collegato al calcolo salvato |
| Utenti internazionali | Sette lingue, RTL e formati adattati |
| Prodotto nel tempo | Versioni, correzioni, acquisti e compatibilità |
Non presento numeri di utenti, fatturato o risultati che non siano pubblici e verificabili. La prova è il prodotto disponibile, la sua scheda ufficiale e la cronologia degli aggiornamenti.
Come applicherei lo stesso metodo a un’altra app
- Definire decisione o lavoro da rendere più semplice.
- Eliminare funzioni che non servono alla prima versione utile.
- Disegnare dati, stati vuoti, errori e casi limite prima di moltiplicare schermate.
- Scegliere cosa resta locale, cosa richiede backend e perché.
- Costruire piano di test e rilascio insieme allo sviluppo.
- Separare budget iniziale, servizi ricorrenti e manutenzione.
La guida quanto costa sviluppare un’app traduce queste scelte in una struttura di preventivo. Il confronto tra web app e app nativa aiuta a scegliere l’architettura; la guida sul costo di manutenzione di un’app separa il lancio dal lavoro successivo. Se hai già un processo, un foglio o un prototipo, posso partire da quello e restituire un perimetro tecnico verificabile.
Hai un problema che merita un prodotto?
Raccontami utenti, decisione da supportare e dati già disponibili. Ti rispondo con domande tecniche, rischi e prossimo passo.
Case study aggiornato il 19/09/2026. Versione pubblica verificata: 1.7.2. Funzioni e versioni verificate sulla scheda ufficiale RouteBudget su App Store. Contenuti operativi del prodotto sono pubblicati su RouteBudget EU.