Hai un'idea di app e stai per bruciare il budget sul prototipo sbagliato: le 8 domande prima di spendere

L’idea non è il perimetro

Hai un’idea di app. Ci pensi da mesi, magari l’hai già schizzata su un foglio, ne parli con entusiasmo agli amici, e adesso sei pronto a spendere: cerchi uno sviluppatore, chiedi preventivi, vuoi vederla realizzata. Fermati un attimo, perché è esattamente qui che si bruciano i budget.

Il problema non è la tua idea. L’idea può anche essere ottima. Il problema è che l’idea non è il perimetro di quello che va costruito. Nella tua testa “un’app che fa X” è una cosa chiara e semplice. Nella realtà, “un’app che fa X” si trascina dietro cento decisioni che non hai ancora preso — chi la usa, quanto spesso, con quali dati, chi paga, cosa succede quando due persone fanno la stessa cosa insieme, cosa vede l’amministratore, cosa succede se salta la connessione. Ognuna di queste decisioni cambia cosa si costruisce, quanto costa, e quanto ci vuole. E se non le prendi tu, prima, le prenderà lo sviluppatore per conto suo mentre costruisce — indovinando. E ogni indovinello sbagliato è tempo e soldi buttati a rifare.

La verità scomoda è questa: la maggior parte dei budget bruciati nello sviluppo di app non muore per colpa del codice. Muore prima, nel vuoto tra “ho un’idea” e “so cosa va costruito”. Il founder salta quel vuoto — perché è impaziente, perché “l’idea è chiara, no?”, perché chi gli vende lo sviluppo ha tutto l’interesse a partire subito a fatturare ore — e sei mesi dopo si ritrova con un prototipo che tecnicamente funziona ma non è la cosa che serviva, e i soldi sono finiti.

Questo articolo è la conversazione che vorrei avere con te prima che tu spenda un euro. Sono 8 domande. Rispondere bene non ti costa niente e ti fa vedere il perimetro vero della tua idea — quello che nessun preventivo ti mostra finché non è troppo tardi. Te le faccio da chi costruisce queste cose e ha visto entrambi i finali: quello di chi ha risposto prima, e quello di chi ha pagato per rispondere dopo.

Le 8 domande da rispondere prima di spendere

Queste non sono domande “tecniche”. Sono domande che tu devi saper rispondere sulla tua idea. Se le rispondi bene, hai già in mano il perimetro. Se ti accorgi che non sai rispondere, hai appena scoperto dove il progetto rischia di esplodere — e l’hai scoperto gratis, invece che a metà budget.

1. Chi la usa davvero, e quanti sono? Non “tutti”. Chi, di preciso? Una persona sola in azienda, cento clienti, migliaia di utenti anonimi? Un’app usata da tre persone che conosci è un mondo diverso da una usata da diecimila sconosciuti: cambia tutto, dalla robustezza alla gestione degli errori, al costo. “Un’app per tutti” è la risposta che garantisce di costruire la cosa sbagliata per chiunque.

2. Quanto spesso la usano, e in che momento? Una cosa che si apre una volta al mese è diversa da una che si usa cento volte al giorno sotto pressione. La frequenza e il contesto d’uso — al computer con calma, o col telefono in piedi mentre si fa altro — decidono com’è fatta l’interfaccia e cosa deve essere velocissimo. Un’app usata di corsa e male progettata per la corsa non la usa nessuno, per quanto ricca sia.

3. Che dati tratta, e da dove vengono? Ogni app vive di dati. Da dove arrivano? Li inserisce l’utente a mano, arrivano da un altro sistema che hai già, si generano da soli? E soprattutto: quanto sono delicati? Dati personali, dati di pagamento, dati sanitari cambiano radicalmente cosa devi fare per tenerli al sicuro e in regola. Questa domanda, saltata, è quella che ti presenta il conto più salato dopo.

4. C’è un pagamento dentro? Di che tipo? Se l’app incassa — abbonamenti, acquisti, prenotazioni con caparra — hai aperto un mondo intero: metodi di pagamento, fatturazione, rimborsi, cosa succede se un pagamento fallisce a metà. Il pagamento non è “un bottone paga”: è una delle parti che costa e richiede più attenzione. Sapere ora se e come c’è dentro cambia il perimetro in modo enorme.

5. Serve che funzioni offline? Sembra un dettaglio tecnico, è una domanda da founder. Se la tua app la usano dove non c’è rete — un magazzino, un cantiere, in giro — deve funzionare anche senza connessione e sincronizzare dopo. È una delle cose che fa lievitare di più la complessità. Se non serve, l’hai appena semplificata parecchio; se serve e non l’hai detto, l’hai appena fatta esplodere.

6. Ci sono ruoli e permessi diversi? Tutti gli utenti sono uguali o ci sono un amministratore, un utente normale, un ospite, un supervisore che vede cose diverse? I ruoli sembrano banali e non lo sono: ogni ruolo è un insieme di “questo lo può fare, quest’altro no” che va pensato e costruito. Un’app con cinque ruoli diversi è molto più di un’app con un ruolo solo.

7. Cosa succede se va storto? Qual è il rischio vero? Se l’app si ferma un’ora, cosa perdi? Un fastidio o un disastro? Se sbaglia un calcolo, spedisce un dato errato, perde un’informazione — qual è il danno? La risposta decide quanto devi investire in robustezza. Un’app il cui errore costa poco può permettersi di essere semplice; una il cui errore costa caro no. Sapere il rischio ti dice dove spendere davvero e dove no.

8. Cosa fanno gli altri che risolvono lo stesso problema? Quasi mai la tua idea è la prima al mondo a toccare quel problema. Chi lo risolve già, e come? Non per copiare: per capire cosa la gente si aspetta, cosa è già dato per scontato, e — importantissimo — se esiste già qualcosa che potresti comprare invece di costruire. Questa domanda ti può risparmiare l’intero budget, e chi te la fa fare sta lavorando per te, non contro il suo preventivo.

Rispondi a queste otto, e succede una cosa: l’idea nella tua testa diventa un perimetro sul tavolo. Vedi cosa è grande e cosa è piccolo, dove sono i rischi, cosa costa. È il primo passo di ogni progetto sano, ed è quello che nella costruzione di un MVP in 90 giorni determina se i 90 giorni bastano o se il progetto va fuori strada dal primo mese.

Cosa NON chiedere a ChatGPT (il competitor “facile”)

C’è oggi una tentazione nuova, e va affrontata perché ci caschi facile: “questa roba me la faccio dire dall’AI.” Apri ChatGPT, descrivi l’idea, e ti sputa fuori funzionalità, stime, addirittura pezzi di codice. Sembra che tu possa saltare tutto — la discovery, lo sviluppatore, il costo. Devo essere onesto con te, perché lo uso e lo conosco: l’AI su questo è un ottimo assistente e un pessimo padrone.

Ecco cosa l’AI fa benissimo e vale la pena usarla: farti da sparring partner sulle idee, aiutarti a mettere in ordine i pensieri, generarti una prima lista di cose a cui non avevi pensato, spiegarti concetti che non conosci. Usala per prepararti alle 8 domande, per non arrivare a mani vuote. È un moltiplicatore della tua testa.

Ecco cosa l’AI fa malissimo, e dove ti frega se ti fidi:

• Ti dà sempre una risposta, anche quando la risposta giusta è “non farlo”. L’AI è compiacente per costruzione: le chiedi come costruire la tua app e ti spiega come, non ti dice “guarda che esiste già e costa un decimo” a meno che non la incalzi. Non ha nessun interesse a fermarti, e nemmeno il fegato di dirti di no.
• Sottostima brutalmente il vero costo. Ti mostra il 20% facile — il caso ideale, la funzione base — e nasconde l’80% difficile: gli errori, i casi limite, i permessi, la sicurezza dei dati, il “cosa succede quando due persone…”. Ti fa sembrare piccolo un progetto grande, e con quella impressione firmi cose che poi esplodono.
• Non conosce il tuo contesto vero. I tuoi vincoli, i tuoi utenti reali, i tuoi dati sporchi, la tua azienda. Ragiona sul caso medio da manuale, e il tuo caso non è il caso medio — il valore è tutto nei dettagli tuoi che l’AI non ha.

Il pericolo non è usare l’AI: è usarla come sostituto del giudizio invece che come assistente del giudizio. Un prototipo generato in fretta con l’AI, senza aver risposto alle 8 domande, è il modo più veloce del 2026 per bruciare tempo su un perimetro sbagliato — la versione moderna del prototipo buttato. Ne ho scritto proprio a partire da un caso di prototipo di intelligenza artificiale fallito: la tecnologia che genera in fretta illude che la parte difficile sia sparita, mentre la parte difficile — decidere cosa costruire e perché — è esattamente quella che nessuno può farti al posto tuo.

Figma non è un test di mercato

Secondo abbaglio, altrettanto comune: pagare per un bel prototipo cliccabile — le schermate disegnate, colorate, che si aprono una dopo l’altra quando premi — e credere di aver “validato” l’idea. Non è così, e la differenza ti costa cara.

Un prototipo disegnato è utile, per una cosa sola: capire come sarà fatta e allinearsi su cosa costruire. Serve a te e allo sviluppatore per vedere le schermate prima di scriverle, discutere i flussi, evitare fraintendimenti. È un ottimo strumento di progettazione. Ma è un disegno: dietro non c’è niente, i dati sono finti, i bottoni non fanno nulla di vero.

Il problema nasce quando confondi “è bello e sembra reale” con “il mercato lo vuole”. Un prototipo cliccabile risponde alla domanda “com’è fatto?”. Non risponde per niente alla domanda che conta davvero: “qualcuno lo userà e lo pagherà?”. Sono due domande diverse, e la seconda non la risolvi con nessun disegno, per quanto curato.

Come si testa davvero il mercato, prima di costruire? Con le persone vere, in modi che costano molto meno di un’app:

• Parlare con chi dovrebbe usarla, e ascoltare i problemi che hanno adesso — non chiedere “ti piace la mia idea?” (tutti dicono di sì per gentilezza), ma capire se il problema che risolvi è un problema che sentono e per cui già oggi fanno qualcosa (o pagano qualcosa).
• Mostrare il prototipo disegnato a persone vere e guardarle mentre ci provano: dove si perdono, cosa non capiscono, cosa chiedono. Questo il prototipo lo può fare, e lo fa benissimo.
• Cercare il segnale di impegno reale: qualcuno che dice “quando è pronto lo compro”, una lista di persone interessate, un pre-ordine. Le parole sono gratis; l’impegno è un segnale.

Il punto è: spendi poco per validare il mercato, spendi molto per costruire. Se inverti l’ordine — costruisci molto per scoprire dopo se il mercato c’era — è lì che si bruciano i budget. Il prototipo disegnato sta nel mezzo: economico, utilissimo per progettare, inutile come prova che qualcuno pagherà. Non chiedergli di essere quello che non è.

“App” non vuol dire una cosa sola: la domanda che sposta il budget

Quando dici “voglio fare un’app”, nella tua testa c’è probabilmente l’icona sullo schermo del telefono, quella che si scarica dallo store. Ma “app” è una parola che copre cose molto diverse per costo e complessità, e sceglierne una senza saperlo è uno dei modi più silenziosi di gonfiare il budget. Vale la pena capirlo prima, perché la scelta cambia il preventivo in modo enorme.

Semplificando, hai tre strade:

• Un’applicazione web: si apre dal browser, non si scarica da nessuno store, funziona su qualsiasi dispositivo con internet. È in genere la più economica e la più veloce da far evolvere, perché la aggiorni per tutti in un colpo. Per moltissime idee — soprattutto quelle usate al lavoro, da un pubblico che ha un computer o un telefono con connessione — è la risposta giusta, e spesso quella che il founder non aveva considerato perché fissato sull’icona da store.
• Un’app che si scarica dallo store (quella “nativa”): sta sul telefono, può usare le sue funzioni speciali (fotocamera, notifiche spinte, posizione, funzionamento offline vero) e dà l’esperienza più fluida. Ma costa di più, richiede il passaggio dagli store con le loro regole, e va mantenuta su piattaforme diverse. Ha senso quando serve davvero quello che solo lei sa fare.
• Una via di mezzo: soluzioni che con una base sola coprono sia il web sia il telefono. Un buon compromesso in molti casi, con i suoi limiti.

Il punto non è quale sia “meglio” in assoluto — non esiste. Il punto è che la scelta dipende dalle risposte alle 8 domande, non dal tuo immaginario. Serve l’offline vero in un magazzino senza rete (domanda 5)? Allora forse serve quello che sa fare l’app scaricabile. La usano al lavoro davanti a un computer (domanda 2)? Allora un’applicazione web ti fa risparmiare parecchio e va evoluta molto più in fretta. Chi parte dall’“icona sullo store” per default, senza fare questo ragionamento, rischia di pagare il doppio per avere qualcosa che poteva essere più semplice, più economico e più facile da migliorare. È esattamente il tipo di decisione che una discovery mette sul tavolo prima che tu firmi, invece di scoprirla a metà budget.

Quanto tenere per il dopo-MVP

Errore da founder che vedo rovinare progetti anche buoni: spendere tutto il budget per arrivare al lancio, e non tenere niente per il dopo. È come costruire una casa e finire i soldi il giorno del trasloco, prima di poterci vivere.

Ecco la verità che nessuno che ti vende lo sviluppo ti dice volentieri: il lancio non è la fine, è l’inizio. Il giorno in cui l’app va live è il giorno in cui scopri cosa avevi sbagliato — perché finalmente ci sono utenti veri che la usano in modi che non avevi previsto. E quello che scopri va sistemato, subito, mentre l’interesse è caldo. Se hai finito i soldi al lancio, sei bloccato: hai un’app che quasi funziona, gli utenti che ci sbattono contro, e niente per aggiustarla. È il momento peggiore per restare senza budget.

La regola sana è brutale ma salva progetti: non spendere tutto per arrivare al primo giorno. Tieni una riserva concreta per le settimane e i mesi dopo il lancio — per sistemare quello che emerge, per la manutenzione, per la seconda ondata di miglioramenti fatti sui dati veri e non sulle ipotesi. Un MVP è per definizione la versione minima che sta in piedi: nasce apposta per imparare dagli utenti veri, e imparare senza budget per agire su ciò che impari non serve a niente.

Come si divide, in pratica? Non prendere una cifra precisa come oro colato, ma il principio è: pensa a quello che ti serve per costruire l’MVP, e poi assicurati di avere ancora una parte significativa oltre quella cifra per il dopo. Se il budget totale copre a malapena il lancio, hai un budget troppo piccolo per il progetto che stai immaginando — meglio saperlo ora, e magari partire da un perimetro più piccolo che ti lasci margine, piuttosto che schiantarti al traguardo. Su cosa significhi davvero “il dopo” — la manutenzione, l’evoluzione, il costo di tenere viva una cosa — vale la pena capirlo prima di firmare, ed è il tema del cosa succede dopo il go-live.

Come capire se hai davanti uno sviluppatore o un venditore di slide

Questa è la parte che ti protegge il portafoglio, perché quando cerchi chi costruisce la tua app incontrerai due specie molto diverse, e all’inizio sembrano uguali. Imparare a distinguerle vale più di qualsiasi preventivo.

Il venditore di slide ti fa sentire benissimo. Ama la tua idea, la trova geniale, ti mostra presentazioni patinate, parla di quanto sarà bello, ti proietta il successo. Dice sempre di sì. A tutto. Ogni funzione che nomini, “certo, si può fare, nessun problema”. Ti dà una stima precisa e ottimista al primo incontro, senza aver capito niente del perimetro. Ti fa fretta di firmare. E soprattutto: non ti fa mai domande scomode.

Lo sviluppatore vero — quello che ti conviene — fa l’opposto, e all’inizio è meno piacevole. Ti fa le domande difficili (quelle otto, e altre). Ti dice “dipende” quando la risposta è dipende, invece di inventare una certezza. Ti mette in guardia sui rischi invece di nasconderli. A volte ti dice cose che non vuoi sentire — “questa parte è più complessa di come la immagini”, “questa funzione la lascerei per dopo”, o addirittura “forse non ti serve costruire, esiste già”. E se ti dà una stima, te la dà dopo aver capito il perimetro, non prima.

I segnali per riconoscere il venditore di slide, concreti:

• Dice sempre di sì. Nessuna funzione è un problema, niente lo preoccupa. La realtà è fatta di compromessi; chi non ne nomina nessuno o non ha capito o non te lo dice.
• Stima precisa troppo presto. Ti spara una cifra e una data al primo colloquio, senza discovery. È impossibile stimare seriamente senza aver capito il perimetro — quindi o sta indovinando, o sta ancorando basso per farti firmare, sapendo che poi rincarerà.
• Non ti fa domande. Se in un’ora di conversazione non ti ha chiesto niente di scomodo sui tuoi utenti, i tuoi dati, i tuoi rischi, non sta pensando al tuo progetto: sta pensando a chiudere il contratto.
• Vende la tecnologia di moda, non la soluzione. Riempie di paroloni e trend invece di parlare del tuo problema. Se il “come” arriva prima del “cosa” e del “perché”, stai comprando fumo.
• Ti mette fretta. L’urgenza artificiale (“offerta valida fino a…”, “dobbiamo partire subito”) è una tecnica di vendita, non un modo di lavorare bene.

Ti dico tutto questo sapendo che sto descrivendo anche come dovrei comportarmi io con te — ed è voluto. Uno che costruisce sul serio non ha paura di dirti “non partire” o “ti serve meno di quello che pensi”, perché il suo interesse vero è che il tuo progetto vada bene, non che tu firmi oggi. Questo è tutto il senso di una discovery onesta, ed è il cuore del modo in cui affronto il comprare software su misura: la fiducia si costruisce facendo le domande giuste, non promettendo tutto.

Il deliverable di una discovery (e resta tuo)

A questo punto la domanda giusta è: “va bene, ma allora come si comincia bene?”. La risposta è: si comincia con una discovery — una fase corta, pagata ma poco costosa, in cui prima di costruire qualsiasi cosa si risponde alle domande e si definisce il perimetro vero. E il punto cruciale, quello che devi pretendere, è: da una discovery esce un deliverable concreto, e quel deliverable è tuo.

Cosa ti deve restare in mano dopo una discovery fatta bene:

• Il perimetro scritto: cosa fa l’app e cosa non fa (i confini sono importanti quanto il contenuto), chi la usa, quali sono i flussi principali. Nero su bianco, non a voce.
• Le risposte alle 8 domande, esplicite: chi, frequenza, dati, pagamenti, offline, ruoli, rischi, alternative esistenti. Documentate, così non si ridiscutono ogni mese.
• Le decisioni prese e le alternative scartate, col perché. Tra sei mesi ricorderai perché avevate deciso così, invece di rifare le stesse discussioni.
• Una stima seria — a questo punto possibile, perché il perimetro c’è — con le fasi e cosa tenere per il dopo-MVP.
• Un prototipo disegnato, se serve, dei flussi principali, per allineare tutti su com’è fatto.

E qui la cosa non negoziabile: questo deliverable è di tua proprietà. Non è “materiale interno” di chi te lo prepara. È tuo, e se dopo la discovery decidi di far costruire l’app a qualcun altro — o di non costruirla affatto — te lo porti via e lo usi. Una discovery fatta onestamente ti dà valore anche se non prosegui con chi l’ha fatta: hai il perimetro, le risposte, la stima, e puoi andare da chiunque con le idee chiare. Chi ti lega la discovery a sé (o non ti lascia niente di concreto in mano) ti sta legando a sé, non servendo.

Questo, per me, è il test di onestà di chi ti propone di lavorare insieme: ti dà qualcosa che resta tuo, utile anche se poi non mi scegli. È l’opposto del venditore di slide, che ti tiene attaccato con la vaghezza. Se qualcuno ti propone una discovery il cui risultato è tuo e ti serve comunque, hai trovato qualcuno che ragiona da tuo alleato.

Quando NON partire

Chiudo con la parte che nessuno che ti vende sviluppo ti dirà mai, e che invece è la più preziosa: le volte in cui la risposta giusta è non costruire. Perché a volte lo è, e dirtelo è il segno che chi hai davanti lavora per te.

Non partire — o fermati e ripensa — se:

• Non sai rispondere a chi la userà e perché pagherebbe. Se le prime due domande sono nebbia, non hai un progetto: hai un’intuizione da validare prima, parlando con le persone, non costruendo.
• Esiste già qualcosa che fa quello che ti serve, e ti va bene. Se c’è un prodotto pronto che risolve il tuo problema a un decimo del costo, comprarlo è la scelta intelligente. Costruire su misura ha senso per il 20% di esigenze tue che il pronto non copre — non per rifare da zero l’80% che esiste già e funziona. Onestà: molte “idee di app” sono già risolte da un abbonamento da poche decine di euro al mese.
• Il budget copre a malapena il lancio. Se non hai margine per il dopo, o parti da un perimetro più piccolo, o aspetti di avere la riserva. Partire sottocapitalizzati è il modo più sicuro di sprecare quello che spendi.
• Stai costruendo per convinzione, non per un problema sentito da altri. “So io che serve” senza nessun segnale dal mercato è la premessa classica del prodotto che non usa nessuno. Cerca il segnale prima, non dopo.
• Non hai il tempo di seguirlo. Un’app non è un oggetto che compri e dimentichi: va seguita, decisa, corretta. Se non hai la testa per starci dietro nei mesi dopo il lancio, anche il miglior sviluppo si spegne.

Dire “non partire” quando è giusto non è perdere un cliente: è essere quello a cui torni la volta buona, e quello che raccomandi agli altri. Se hai un’idea e vuoi capire, prima di spendere, se sta in piedi e qual è il perimetro vero, è esattamente da qui che si comincia — con le domande, non col preventivo. Guarda come lavoro o scrivimi e le ragioniamo sul tuo caso, anche solo per dirti onestamente se e come ha senso partire.

Domande che mi fanno prima di iniziare

1. Quanto costa una discovery rispetto a costruire subito? Una frazione. È una fase corta il cui scopo è definire il perimetro e rispondere alle domande, non costruire. Costa poco proprio perché ti evita di spendere molto sul perimetro sbagliato — è l’assicurazione più economica del progetto.

2. Ma se ho già le idee chiarissime, non posso saltare la discovery? Rispondi tu stesso alle 8 domande. Se le sai tutte, con dati e non con intuizioni, hai già fatto la discovery da solo: ottimo, si può partire a costruire. Se ti accorgi che su tre di quelle domande vai a naso, hai appena scoperto perché la discovery ti serve.

3. Non posso farmi il prototipo con l’AI e portartelo già fatto? Portami pure quello che l’AI ti ha aiutato a mettere in ordine, è utile come punto di partenza. Ma un prototipo generato in fretta non è un perimetro validato: l’AI ti mostra il facile e nasconde il difficile, e non conosce il tuo contesto vero. Usala per prepararti, non per decidere.

4. Il prototipo disegnato mi dice se l’idea funzionerà? Ti dice com’è fatta e serve moltissimo per allinearsi e progettare. Non ti dice se il mercato la vuole: quello si scopre parlando con persone vere e cercando segnali di impegno reale, cose che costano molto meno di un’app.

5. Quanto budget dovrei tenere per dopo il lancio? Una parte significativa, oltre a quella che serve per costruire l’MVP. Il lancio è l’inizio, non la fine: è quando scopri cosa aggiustare con utenti veri. Se il budget copre a malapena il primo giorno, conviene partire da un perimetro più piccolo che ti lasci margine.

6. Come faccio a fidarmi di chi costruisce? Guarda se ti fa le domande scomode invece di dirti sempre di sì, se ti dà una stima dopo aver capito il perimetro e non prima, se ti mette in guardia sui rischi, e se il risultato della discovery resta tuo anche se poi scegli un altro. Chi ti tiene attaccato con la vaghezza e la fretta è un venditore di slide.

7. E se dalla discovery esce che non conviene costruire? È uno degli esiti possibili e utili: ti sei risparmiato di bruciare il budget. Magari esiste già un prodotto che fa al caso tuo, magari il perimetro va ripensato, magari serve prima validare col mercato. Scoprirlo con una spesa piccola è una vittoria, non una sconfitta.

8. Il materiale della discovery lo posso usare con un altro sviluppatore? Sì, deve restare tuo: perimetro, risposte, decisioni, stima. Una discovery onesta ti dà valore anche se non prosegui con chi l’ha fatta. Se qualcuno te lo nega o non ti lascia niente di concreto in mano, sta legando te a sé invece di servirti.