Ho visto tre persone diverse gestire male la stessa schermata di trenta secondi — la scheda del piano che appare tra il tuo prompt e il build — e ognuna l'ha pagata con una valuta diversa. Una l'ha pagata con una ricostruzione. Una con tempo digitato inutilmente. Una con un prodotto incapace di fare ciò di cui aveva davvero bisogno. La scheda del piano è il momento più economico dell'intero processo per cambiare idea, ed è proprio per questo che è facile ignorarla di fretta.
Errore uno: approvarlo senza guardarlo
È il più comune. Lo scheletro sembra corretto, clicchi approva, vai avanti — l'ho fatto per settimane prima che mi si ritorcesse contro. Il build che finalmente mi ha fatto rompere l'abitudine è tornato con un checkout Stripe collegato a un sito statico che non aveva dove mettere lo stato dell'account richiesto da Stripe. Il piano diceva tipo di prodotto: sito statico in chiaro, proprio lì sulla scheda, e ci sono passato sopra perché l'elenco delle pagine sembrava a posto e avevo fretta.
Il danno di questo errore ha sempre la stessa forma: tutto ciò che segue il piano è corretto dato il piano, quindi il fallimento non emerge come un errore, emerge come un build funzionante ma strutturalmente sbagliato. Nessuno lo segnala perché nulla è rotto — un sito statico con un pulsante di pagamento fa semplicemente la cosa sbagliata in silenzio, oppure fallisce proprio nel momento in cui un utente reale clicca su "paga". Lo scopri in revisione, che è il posto più costoso in cui scoprirlo.
Errore due: specificare troppo per evitare un secondo giro
L'errore opposto sembra più responsabile ma non lo è. Alcuni, dopo essersi scottati con il primo errore, esagerano nella direzione opposta scrivendo un paragrafo di requisiti precisi già alla fase del piano — testo esatto, preferenze di spaziatura, quali funzionalità devono esserci e quali no, il tutto formulato come un documento di specifiche. L'ho fatto anch'io, spinto da una vaga ansia che saltare i dettagli ora significasse "sprecare" un giro di build più avanti.
È controproducente, ed ecco perché: il piano verrà comunque rivisto di nuovo una volta viste le pagine reali, indipendentemente da quanto sei stato attento la prima volta. E quando viene rivisto, non ottieni un confronto di ciò che è cambiato — ottieni una scheda nuova che incorpora già la tua modifica, punto, senza note di rilascio. Quindi la precisione digitata al primo giro non arriva intatta al secondo comunque; devi rileggere tutto in entrambi i casi. Due o tre giri del tipo "no, così" ti portano a un risultato migliore, più velocemente in termini di tempo reale, rispetto a un unico brief esaustivo — anche se scrivere il brief sembra più efficiente mentre lo fai.
Le modifiche in linguaggio naturale che funzionano davvero sono brevi:
- "Togli il blog, aggiungi una pagina prezzi" — sostituisce pulitamente l'elenco delle pagine.
- "Rendilo per due giocatori invece che per uno" — più grande di quanto sembri. Può toccare il modello dei dati, che ora traccia due partecipanti invece di uno, e il piano rivisto mostrerà quella ripercussione invece di nasconderla.
- "Serve un sistema di account utente" — se il piano attuale è un sito statico, questa è la frase che porta subito in primo piano la domanda sul tipo di prodotto.
Errore tre: trattare il tipo di prodotto come un campo negoziabile
Questo è quello costoso, ed è costoso perché tutto il resto sulla scheda è davvero recuperabile. Pagine, funzionalità dedotte, la maggior parte dei bivi decisionali — tutto correggibile con un'iterazione di versione dopo che il build è arrivato. Il tipo di prodotto no. Ci sono quattro categorie:
| Tipo di prodotto | Cosa significa |
|---|---|
| Sito statico | Semplice, senza logica lato server. |
| App installabile | Tipo PWA — utilizzabile offline, aggiungibile alla schermata home, ancora senza logica lato server. |
| Build su framework | Tipo React/Next, interattività lato client più marcata, ancora senza backend persistente. |
| App con backend | L'unica delle quattro con un vero database e sistema di account dietro. |
Approva un piano per sito statico, decidi tre versioni dopo che vuoi il login, e questo non è un aggiornamento di versione — è una ricostruzione da un tipo di prodotto diverso, e perdi la continuità che la cronologia delle versioni ti aveva dato per tutto il resto.
Le persone sbagliano in due modi. Primo, non controllano il proprio prompt rispetto al campo — se il tuo prompt contiene "account," "accesso," "salva," "dashboard che si aggiorna," "pagamenti," o "più utenti che modificano la stessa cosa," e la scheda non indica basato su server, quella è la modifica da fare prima di approvare, senza eccezioni. Secondo, confondono app installabile con build a framework, perché entrambe sembrano "un'app" nel linguaggio comune. Non sono intercambiabili: l'app installabile è adatta a uno strumento in cui tutto lo stato risiede sul dispositivo dell'utente — un calcolatore di mance, un timer per allenamenti. La build a framework significa più interattività e struttura a componenti, ma comunque nulla che persista lato server tra sessioni o dispositivi. Nessuna delle due è "un'app" nel senso di avere account e dati che ti seguono tra i dispositivi — solo il basato su server lo è. E sovradimensionare verso basato su server "per sicurezza" per un sito portfolio o una pagina di documentazione non è nemmeno la scelta sicura; ridimensionare in basso dopo comporta una ricostruzione tanto quanto farlo verso l'alto.
Cosa resta una volta smesso di fare questi tre errori
Una volta che non salti più la riga del tipo di prodotto, non scrivi più una specifica alla fase del piano, e non tratti più il linguaggio su account/dati/pagamenti nel tuo prompt come negoziabile, resta un controllo rapido e mirato:
- Leggi il tipo di prodotto.
- Confrontalo con il tuo prompt.
- Scorri l'elenco delle funzionalità dedotte per individuare qualcosa da scartare a colpo d'occhio.
L'elenco esiste proprio perché un prompt come "strumento di prenotazione per saloni di parrucchiere" attira cose che non hai scritto — vista calendario, promemoria SMS, elenco clienti, alcune delle quali volevi davvero e altre che sono scope creep aggiunto dal modello perché quelle funzionalità viaggiano insieme statisticamente. Elimina ciò che non serve con una frase, qui, invece che dopo che è stato costruito.
Tutto il resto — testo, spaziatura, quale sfumatura di colore d'accento, se il pulsante dice "Inizia ora" o "Provalo Gratis" — non è sulla scheda per niente, di proposito. Sono cose economiche da vedere e correggere su un build funzionante, quindi la scheda non spreca la tua attenzione su di esse, e nemmeno tu dovresti. Sono forse quindici secondi di vero giudizio dentro i trenta secondi che servono per leggerla.
