Smetti di chiederti se la tua idea è fattibile. Te lo dimostro costruendola.

Ecco alcuni esempi di problemi che diventano un sistema: preventivi — la richiesta arriva via email e il sistema prepara la bozza di offerta con i tuoi listini e le tue condizioni, pronta da rivedere; report per i clienti — i dati vengono raccolti dalle piattaforme che usi e impaginati ogni mese nel tuo formato; documenti in entrata — fatture, contratti o schede tecniche vengono letti e i dati finiscono dove servono, senza ricopiarli a mano.

E ancora: un gestionale su misura per appuntamenti, scadenze e rinnovi al posto dei fogli Excel che nessuno aggiorna; un assistente interno che risponde alle domande ricorrenti del team o dei clienti pescando dai tuoi documenti; verbali e azioni da fare generati dalla registrazione della call con il cliente. Il tuo caso quasi certamente non è in questa lista: sono esempi del tipo di problema, non un catalogo. Il punto in comune è sempre lo stesso — qualcosa che rifai uguale ogni settimana.

Perché è il modo per non buttare via i soldi dello sviluppo. I progetti software falliscono quasi sempre per la stessa ragione: si inizia a costruire prima di aver chiarito cosa serve davvero. Si scopre a metà strada che il perimetro era sbagliato, i costi raddoppiano e il progetto si arena.

Inoltre i 1.999 € dello sprint vengono scalati interamente dal preventivo di realizzazione se decidi di proseguire con me. In pratica, se andiamo avanti la progettazione non ti è costata nulla in più. Se non andiamo avanti, hai speso 1.999 € invece di scoprire il problema dopo averne spesi dieci volte tanti.

Per un prototipo da mostrare, spesso sì. Per un sistema su cui basare il lavoro, quasi mai. Questi strumenti sono ottimi per arrivare rapidamente a qualcosa che sembra funzionare. Il problema arriva dopo: gestione degli errori, sicurezza dei dati, integrazione con i sistemi che già usi, costi che crescono con l'uso, comportamenti imprevedibili quando l'AI viene messa sotto pressione da casi reali.

Il mio lavoro non è scrivere codice al posto tuo: è capire quali sono le decisioni che ti si ritorceranno contro tra sei mesi e prenderle bene adesso. È la differenza tra una demo che funziona una volta e un sistema che regge tutti i giorni — la stessa differenza che ho imparato lavorando su piattaforme enterprise dove un errore in produzione ha un costo immediato.

Ricevi cinque cose concrete: 1) un prototipo funzionante del sistema, utilizzabile e mostrabile a terzi; 2) la definizione dello scope, cioè cosa deve fare la versione di produzione e cosa è stato volutamente escluso; 3) la stima di costi e tempi per realizzarla; 4) i requisiti tecnici e le integrazioni necessarie; 5) una roadmap in fasi, con cosa fare subito e cosa dopo.

Il percorso è scandito così: settimana 1 inquadramento del problema e scelta del perimetro, settimana 2 costruzione del prototipo, settimana 3 test sul tuo caso reale, rifiniture e consegna del piano. Ci sentiamo con un punto fisso a settimana, così non ci sono sorprese alla fine.

Lo dico chiaramente, così non ci sono equivoci. Lo sprint non include: la versione di produzione del software, le integrazioni con i tuoi sistemi in uso (gestionale, CRM, e-commerce), la messa online con utenti reali, la manutenzione e l'assistenza continuativa.

Tutto questo è la fase successiva, con un preventivo separato che nasce proprio dai numeri emersi durante lo sprint — e da cui, se prosegui con me, vengono scalati i 1.999 €. Tenere separate le due fasi serve a te: decidi se investire nella realizzazione quando hai in mano dati veri, non prima.

Nessun problema e nessun vincolo. Prototipo, codice, documentazione e piano restano tuoi: puoi tenerli nel cassetto, riprenderli tra un anno o affidarli a un altro fornitore. Non ci sono penali, canoni o clausole di esclusiva.

Capita, ed è un esito legittimo: a volte i numeri dicono che il gioco non vale la candela. Scoprirlo dopo 21 giorni e 1.999 € è una vittoria, non una sconfitta — soprattutto rispetto all'alternativa, cioè scoprirlo dopo sei mesi di sviluppo.

Hai tre strade e le valutiamo insieme già durante lo sprint, perché questa decisione cambia come va progettato il sistema. Puoi affidare a me la manutenzione con un canone mensile concordato; puoi far gestire il sistema al tuo fornitore IT o a uno sviluppatore interno, con la documentazione che ti lascio; oppure, per sistemi semplici, puoi gestirlo in autonomia.

In ogni caso il progetto viene costruito per essere manutenibile da chiunque: tecnologie standard e diffuse, documentazione scritta per essere letta anche da chi non c'era. Non lavoro creando dipendenza: se resti con me deve essere perché ti conviene, non perché sei bloccato.

Firmiamo un NDA prima di entrare nel merito della tua idea, già dalla prima call se preferisci. Quello che mi racconti resta tra noi e non viene usato in altri progetti né citato pubblicamente senza il tuo consenso esplicito.

Sul fronte dati: durante lo sprint lavoriamo quando possibile con dati di esempio o anonimizzati. Se il sistema deve trattare dati personali o riservati, le scelte tecniche vengono prese di conseguenza — dove risiedono i dati, quali modelli AI possono vederli, cosa resta all'interno della tua infrastruttura. È una parte del lavoro di progettazione, non un dettaglio da sistemare dopo.

Dipende dal perimetro, ed è proprio questo che lo sprint serve a stabilire. Un sistema che automatizza un singolo processo interno ha costi molto diversi da una piattaforma usata da clienti esterni con account, pagamenti e integrazioni.

Quello che posso garantirti è il metodo: alla fine dello sprint hai una stima costruita su un prototipo reale, non su un'ipotesi. E la roadmap è divisa in fasi proprio perché tu possa partire da un primo blocco sostenibile, verificarne il ritorno, e decidere se procedere con il resto.

Lavoro con liberi professionisti, studi, agenzie e piccole imprese: chi ha processi ripetitivi da automatizzare, un servizio da trasformare in prodotto, o un'idea che richiede un software per esistere. La dimensione dell'azienda conta meno della qualità del problema.

Il criterio vero è un altro: il problema deve ripetersi. Se una cosa la fai una volta l'anno, non ha senso costruirci un sistema. Se la fai ogni settimana, o ogni volta che entra un cliente nuovo, allora vale la pena parlarne. Se non è il tuo caso te lo dico in call, senza farti perdere tempo.