Ogni agenzia, freelancer e software house del pianeta ti dirà di avere un "processo collaudato." Butteranno lì termini come Agile, Scrum, Lean, Design Thinking — e la maggior parte delle volte queste parole non significano assolutamente nulla nella pratica. Gli sviluppatori improvvisano. I requisiti cambiano ogni settimana. E il prodotto finale arriva in ritardo, fuori budget e mezzo rotto.
Dopo aver costruito oltre 100 prodotti software in più di 12 anni come CEO di Lasting Dynamics — in settori come fintech, healthtech, difesa, immobiliare, pubblica amministrazione e lusso — ho smesso di cercare di essere "certificato Agile" e ho iniziato a fare ciò che funziona davvero. Il nostro processo non è puro Agile e non è Waterfall. È un ibrido collaudato sul campo che prende in prestito da entrambi, scarta ciò che non funziona e aggiunge lezioni duramente apprese da progetti che vanno da MVP da $10K a piattaforme enterprise multimilionarie.
In questo articolo ti accompagnerò attraverso ogni singola fase di come costruiamo software — dalla prima conversazione all'iterazione post-lancio. Niente buzzword. Niente promesse vaghe. Solo i passi concreti, le tempistiche reali e i costi effettivi. Che tu sia un founder che sta definendo il suo primo MVP, un CEO che sta valutando le agenzie, o un product manager alla ricerca di un modo migliore per rilasciare — questo è il playbook.
E se vuoi capire quanto potrebbe costare il tuo prodotto specifico, leggi il mio articolo complementare dove analizzo numeri e range reali.
Fase 0: Discovery & Strategia (2 Settimane)
Questa è la fase che separa i team seri dalle fabbriche di codice. Prima di scrivere una singola riga di codice — prima ancora di aprire uno strumento di design — dedichiamo due settimane concentrate a comprendere il problema che stiamo effettivamente risolvendo. Non il problema che pensi di avere. Quello vero.
Durante la Fase 0, lavoriamo direttamente con te (il founder, il CEO o il product owner) per mappare quattro dimensioni critiche:
- Contesto di business: Qual è il modello di business? Chi paga? Come generi ricavi? Quali sono i tuoi vincoli (budget, tempistiche, normative)?
- Mercato e competitor: Chi altro sta facendo qualcosa di simile? Qual è la tua differenziazione? Dove sono le lacune che puoi sfruttare?
- Utenti: Chi sono gli utenti principali? Quali sono i loro pain point? Come si definisce il successo per loro — non per te, per loro?
- Panorama tecnico: Ci sono sistemi esistenti con cui integrarsi? Dati da migrare? Requisiti di conformità (GDPR, HIPAA, SOC 2)?
L'output della Fase 0 è un Product Brief — un documento conciso e azionabile che include: personas degli utenti validate, una lista di funzionalità prioritizzata usando il metodo MoSCoW (Must have, Should have, Could have, Won't have), uno schema architetturale di alto livello e una raccomandazione tecnologica preliminare. Se vuoi sapere come scegliamo lo stack giusto, ho scritto una guida completa alla scelta del tech stack.
La Fase 0 costa tipicamente tra $3.000 e $8.000 a seconda della complessità. So cosa stai pensando: "Perché dovrei pagare $5K prima ancora che inizi lo sviluppo?" Perché questa fase fa risparmiare regolarmente ai nostri clienti $50.000 o più. Elimina le cattive idee in anticipo. Previene lo scope creep. Allinea l'intero team prima che un singolo euro venga speso nello sviluppo.
Il Punto di Vista di Michele
Ecco il segnale d'allarme a cui voglio tu faccia attenzione: se un'agenzia è disposta a iniziare a scrivere codice nella prima settimana senza una fase di discovery, scappa. Significa che non gli interessa costruire la cosa giusta — gli interessa fatturare ore. Abbiamo ereditato decine di progetti da team che hanno saltato la discovery. Ognuno di essi è costato di più da sistemare di quanto sarebbe costato farlo bene dall'inizio. Ogni. Singolo. Uno.
Alla fine della Fase 0, hai totale chiarezza. Sai cosa stai costruendo, perché lo stai costruendo, indicativamente quanto tempo ci vorrà e quanto costerà. E la parte migliore: la Fase 0 è indipendente. Se decidi di non proseguire con noi, il Product Brief resta tuo. Puoi portarlo a qualsiasi altro team. Zero vincoli.
Fase 1: Design & Prototipazione (2–3 Settimane)
Con il Product Brief in mano, il nostro team di design si mette al lavoro. Ma non saltiamo direttamente ai mockup belli — è un errore che vedo fare costantemente ai designer junior. Un buon design segue una sequenza deliberata:
La Sequenza di Design
- UX Research: Mappiamo i flussi utente — i percorsi esatti che un utente compie per raggiungere i propri obiettivi. Da dove partono? Quali decisioni prendono? Dove potrebbero confondersi o abbandonare?
- Wireframe: Layout a bassa fedeltà che stabiliscono la gerarchia delle informazioni, la navigazione e i pattern di interazione. Niente colori, niente font elaborati — solo struttura.
- UI Design: Design visivo ad alta fedeltà costruito sopra i wireframe validati. È qui che entrano in gioco l'identità del brand, la tipografia, i sistemi di colore e la finitura visiva.
- Prototipo Cliccabile: Un prototipo completamente interattivo in Figma che sembra e si comporta come il prodotto reale. Puoi cliccarci, navigare tra le schermate e sperimentare il prodotto prima che venga scritta una singola riga di codice.
Ecco il passaggio che la maggior parte dei team salta — ed è quello che conta di più: testiamo il prototipo con utenti reali prima che inizi lo sviluppo. Usando strumenti come Maze, eseguiamo test di usabilità moderati e non moderati con persone che corrispondono al tuo pubblico target. Osserviamo dove si confondono, dove esitano, dove cercano di cliccare qualcosa che non esiste.
Questa fase di test individua l'80% dei problemi di UX prima che diventino errori di sviluppo da $20K. Modificare un wireframe richiede 20 minuti. Modificare una funzionalità già sviluppata richiede 2 settimane e $15K.
I deliverable della Fase 1 sono:
- Design System: Una libreria di componenti riutilizzabili (bottoni, form, card, modali) che garantisce coerenza e accelera lo sviluppo.
- Prototipo Validato: Testato con utenti reali, con feedback documentato e iterazioni applicate.
- Specifica Tecnica: Un documento dettagliato che traduce il design in requisiti di sviluppo — endpoint API, modelli dati, gestione dello stato, integrazioni con terze parti.
Quando la Fase 1 è completata, non ci sono più sorprese. Il cliente sa esattamente come sarà il prodotto. Gli sviluppatori sanno esattamente cosa devono costruire. E le stime fornite nella Fase 0 sono ora affinate con una precisione del 10-15%.
Fase 2: Sviluppo — Basato su Sprint (8–16 Settimane)
Ora costruiamo. È qui che la natura ibrida del nostro processo diventa evidente. Usiamo cicli di sprint di 2 settimane — presi in prestito da Scrum — ma senza l'overhead cerimoniale dogmatico che fa sembrare il puro Scrum un esercizio burocratico. Ogni sprint segue un ritmo disciplinato:
Il Ciclo di Sprint
| Giorno | Attività | Chi è Coinvolto |
|---|---|---|
| Giorno 1 | Sprint Planning — selezione delle storie dal backlog, stima, impegno | Team di sviluppo + Product Owner |
| Giorni 2–9 | Sviluppo — codifica, code review, unit testing | Team di sviluppo |
| Giorno 10 | QA Interna — test sull'ambiente di staging | Team QA + Team di sviluppo |
| Giorno 10 (pomeriggio) | Sprint Demo — walkthrough dal vivo delle funzionalità completate | Tutti + Cliente |
| Fine dello sprint | Retrospettiva — cosa ha funzionato, cosa no, cosa miglioriamo | Team di sviluppo + PM |
Comunicazione: Nessuna Scatola Nera
Una delle lamentele più frequenti che sento dai founder che hanno lavorato con altre agenzie è: "Non avevo idea di cosa stesse succedendo per settimane intere." Con noi non succede. Ecco come ti teniamo aggiornato:
- Standup asincrono giornaliero: Ogni mattina il team pubblica un breve aggiornamento su Slack — cosa ha fatto ieri, cosa fa oggi, eventuali blocchi. Puoi leggerlo o ignorarlo.
- Call di sincronizzazione settimanale: Una videochiamata di 30 minuti dove discutiamo i progressi, segnaliamo i rischi e ci allineiamo sulle priorità per la settimana successiva. Telecamera accesa, condivisione schermo, conversazione reale.
- Accesso alla board: Hai accesso in lettura completo alla nostra board di progetto (Linear o Jira). Ogni task, ogni stato, ogni commento — totale trasparenza.
- Sprint demo ogni 2 settimane: Vedi il prodotto reale in esecuzione su un server di staging. Non slide. Non screenshot. La cosa vera.
Standard Ingegneristici: Non Negoziabili
Questo è il punto in cui siamo rigidi e senza scuse:
- Code review su ogni pull request. Nessuna eccezione. Ogni riga di codice viene revisionata da almeno un altro sviluppatore senior prima di essere mergiata. Questo individua bug, garantisce coerenza e diffonde la conoscenza nel team.
- CI/CD dal primo giorno. Configuriamo pipeline di continuous integration e continuous deployment nel primo sprint. Ogni merge sul branch principale attiva test automatizzati e deploy sull'ambiente di staging. Hai sempre una versione funzionante da consultare.
- Strategia di branching Git. Usiamo trunk-based development con feature branch. Storico pulito, rollback facili, nessun incubo di merge.
- Documentazione. Documentazione API, registri delle decisioni architetturali, runbook. Se il nostro team venisse investito da un autobus, un altro team competente potrebbe prendere in mano il codebase e proseguire.
Se sei un founder non tecnico e ti chiedi se hai bisogno di un co-founder tecnico per gestire tutto questo — la risposta è no. Ma hai bisogno di un team che operi con questo livello di disciplina. È per questo che stai pagando.
Fase 3: QA & Testing (Continuo)
Devo affrontare un equivoco che persiste in questo settore: il testing non è una fase. Non è qualcosa che si fa "alla fine" dopo che gli sviluppatori hanno "finito". Il testing è integrato in ogni singolo sprint fin dal primo. Ecco la nostra piramide di testing:
Testing Automatizzato
- Unit test: Singole funzioni e componenti testati in isolamento. Si eseguono in pochi secondi e danno feedback immediato. Puntiamo al 70-80% di code coverage sulla logica di business.
- Test di integrazione: Gruppi di componenti testati insieme — endpoint API, query al database, interazioni tra servizi. Verificano che i pezzi funzionino insieme, non solo singolarmente.
- Test end-to-end (E2E): Percorsi utente completi automatizzati con strumenti come Playwright o Cypress. Simulano un utente reale che clicca attraverso l'applicazione. Copriamo ogni percorso critico: registrazione, login, workflow principali, flussi di pagamento.
QA Manuale
I test automatizzati catturano regressioni ed errori logici. Ma non catturano la cattiva UX, i difetti visivi o i casi limite che solo un occhio umano nota. I nostri specialisti QA eseguono test esplorativi su ogni funzionalità — testando su diversi browser, dimensioni di schermo e dispositivi. Cercano di rompere le cose. Usano il prodotto nel modo in cui lo userebbe un utente reale confuso e impaziente.
Sistema di Triage dei Bug
Quando vengono trovati dei bug (e verranno trovati — è proprio lo scopo del testing), vengono classificati immediatamente:
| Severità | Definizione | Tempo di Risposta | Esempio |
|---|---|---|---|
| Critico (P0) | Sistema down o perdita di dati | Fix entro 4 ore | Elaborazione pagamenti fallisce, dati utente cancellati |
| Maggiore (P1) | Funzionalità core non funzionante, nessun workaround | Fix entro 24 ore | Gli utenti non riescono a completare la registrazione, la dashboard non si carica |
| Minore (P2) | Funzionalità compromessa ma esiste un workaround | Fix nel prossimo sprint | Il filtro non si resetta, l'export manca una colonna |
| Cosmetico (P3) | Problema visivo o testuale | Backlog, fix quando conveniente | Typo nel footer, problema di allineamento di 1px |
Questo sistema significa che non dovrai mai chiederti "questo bug viene preso seriamente?" Ogni problema ha una severità chiara, un responsabile chiaro e uno SLA chiaro.
Fase 4: Lancio & Post-Lancio
Il giorno del lancio non è "deploy e prega." È un evento coreografato con una checklist dettagliata che abbiamo affinato in centinaia di lanci. Ecco cosa copre la nostra checklist di preparazione al lancio:
- Performance: Load testing completato. Core Web Vitals in verde. Time to first byte sotto i 200ms. Punteggio Lighthouse sopra 90.
- Sicurezza: OWASP Top 10 revisionata. SSL configurato. Autenticazione rafforzata. Rate limiting attivo. Dipendenze scansionate per vulnerabilità.
- Monitoraggio: Error tracking (Sentry), monitoraggio uptime (Better Uptime), monitoraggio performance (Vercel Analytics o Datadog), e aggregazione log — tutto configurato e testato.
- Backup & recovery: Backup del database automatizzato. Procedura di recovery documentata e testata. Piano di rollback pronto in caso di deployment fallito.
- SEO & analytics: Meta tag, sitemap, robots.txt, dati strutturati. Google Analytics / Plausible configurato. Tracciamento conversioni impostato.
Soft Launch vs. Hard Launch
Raccomandiamo quasi sempre un soft launch prima — rilasciando a un piccolo gruppo di utenti beta (10-50 persone) per 1-2 settimane prima del lancio pubblico. Questo individua problemi del mondo reale che nessuna quantità di test sullo staging potrà trovare: comportamenti utente inaspettati, colli di bottiglia nelle performance su larga scala, flussi di onboarding confusi.
Un hard launch (rilascio pubblico con push di marketing) arriva dopo che il feedback del soft launch è stato incorporato. L'unica eccezione è quando c'è una scadenza esterna tassativa — una conferenza, una milestone di finanziamento, una data normativa. Anche in quel caso, pianifichiamo un ciclo di iterazione rapida nelle prime due settimane post-lancio.
“Il lancio non è la fine. È l'inizio. Tutto ciò che hai costruito era basato su ipotesi. Ora scopri quali ipotesi erano sbagliate — ed è lì che inizia il vero sviluppo del prodotto.”
— Michele Cimmino · CEO, Lasting Dynamics
Dopo il lancio, passiamo alla modalità di monitoraggio e risposta rapida. Monitoriamo tassi di errore, metriche di performance, analytics sul comportamento utente e ticket di supporto come falchi. Gli hotfix vengono rilasciati entro poche ore. I miglioramenti non critici vengono accodati per lo sprint successivo. Ogni decisione è ora guidata da dati reali degli utenti, non da ipotesi.
Fase 5: Scalare & Iterare
L'MVP è live. Gli utenti stanno arrivando. E ora? È qui che molti team perdono la rotta. O congelano il prodotto e smettono di iterare (morte per stagnazione) o cercano di costruire tutto in una volta (morte per over-engineering). La risposta è l'iterazione disciplinata.
Da MVP a V1 a Prodotto Maturo
Pensiamo all'evoluzione del prodotto in fasi chiare:
- MVP (Mese 0-3): Proposta di valore core. Un tipo di utente, un workflow, un mercato. L'obiettivo è validare che le persone vogliano questa cosa. Leggi la mia analisi dettagliata sui costi e ambito dell'MVP.
- V1 (Mese 3-9): Sulla base del feedback degli utenti reali, espandi il set di funzionalità. Aggiungi le funzionalità "Should have" dalla lista MoSCoW. Rafforza la sicurezza, migliora le performance, aggiungi le integrazioni che gli utenti stanno richiedendo.
- Prodotto Maturo (Mese 9+): Ora stai ottimizzando, non esplorando. A/B testing, ottimizzazione delle conversioni, analytics avanzata, funzionalità enterprise, API per integrazioni con terze parti.
Scalare il Team
Quando e come scalare il team è una decisione su cui aiutiamo i nostri clienti a riflettere attentamente. Aggiungere sviluppatori troppo presto crea overhead di coordinamento che ti rallenta. Aggiungerli troppo tardi crea burnout e scadenze mancate. Il pattern generale che seguiamo:
- Fase MVP: 2-3 sviluppatori, 1 designer, 1 PM/QA. Mantienilo piccolo e veloce.
- Fase V1: 4-6 sviluppatori, 1-2 designer, QA dedicato, PM. I feature team possono iniziare a formarsi.
- Fase di scala: Più feature squad, team piattaforma, DevOps/SRE, team design dedicato. È a questo punto che assumere il tuo team inizia ad avere senso dal punto di vista economico.
In tutta questa fase ci concentriamo sullo sviluppo guidato dagli analytics. Ogni decisione sulle funzionalità è supportata dai dati — analytics sul comportamento utente, analisi dei funnel, retention per coorte, punteggi NPS. Smettiamo di indovinare e iniziamo a misurare. Il refactoring strategico avviene parallelamente alle nuove funzionalità — miglioriamo continuamente la qualità del codice, riduciamo il debito tecnico e ottimizziamo le performance in modo che il prodotto diventi migliore man mano che cresce, non peggiore.
Tempistiche e Budget Realistici
Sto per mostrarti la tabella che avrei voluto qualcuno mi avesse mostrato quando ho iniziato a costruire prodotti. Questi numeri sono basati sulla nostra effettiva storia dei progetti — non numeri aspirazionali di marketing, ma quanto costano realmente le cose e quanto tempo ci vuole davvero quando si lavora correttamente.
| Tipo di Prodotto | Discovery + Design | Sviluppo | Tempistica Totale | Range di Budget Totale |
|---|---|---|---|---|
| Landing Page / MVP di Validazione | 1 settimana | 1–2 settimane | 2–3 settimane | $5K – $15K |
| SaaS Semplice / Web App | 3–4 settimane | 8–12 settimane | 3–4 mesi | $30K – $80K |
| SaaS Complesso / Piattaforma Multi-tenant | 4–5 settimane | 12–20 settimane | 4–6 mesi | $80K – $200K |
| App Mobile (Cross-platform) | 3–4 settimane | 10–16 settimane | 3–5 mesi | $50K – $150K |
| Marketplace / Piattaforma a Due Lati | 4–6 settimane | 16–24 settimane | 5–8 mesi | $100K – $250K+ |
| Sistema Enterprise / ERP Custom | 6–8 settimane | 24–40 settimane | 8–12 mesi | $200K – $500K+ |
Un Avvertimento sulle Promesse Irrealistiche
Se qualcuno ti promette un prodotto complesso e ricco di funzionalità in 4 settimane per $20K, sta mentendo, è incompetente, o sta pianificando di consegnare qualcosa tenuto insieme con il nastro adesivo. L'ho visto centinaia di volte. Il preventivo iniziale sembra ottimo. Poi arrivano gli ordini di modifica, le "complessità impreviste", i ritardi. Alla fine hai pagato 2-3 volte il preventivo originale e ancora non hai un prodotto di cui andare fiero. Aspettative realistiche in partenza ti fanno risparmiare una fortuna nel lungo periodo.
Queste tempistiche presuppongono un team competente e dedicato che lavora al tuo progetto — non un team diviso su cinque clienti. Includono discovery, design, sviluppo, QA e lancio. Non includono la fase di iterazione post-lancio (Fase 5), che è continuativa.
I range di budget sono ampi perché ogni prodotto è diverso. Un "SaaS semplice" con tre ruoli utente, permessi complessi e cinque integrazioni costa di più di un SaaS semplice con un tipo di utente e CRUD di base. La complessità dei tuoi requisiti specifici determina il numero finale — ed è esattamente per questo che partiamo dalla Fase 0.
Perché Questo Processo Funziona (Quando gli Altri No)
Voglio essere diretto sul perché sto condividendo tutto questo. Non è perché il nostro processo sia una salsa segreta che nessun altro può replicare. È perché la maggior parte dei team non segue alcun processo in modo coerente. Hanno un processo sul loro sito web e una realtà completamente diversa nei loro canali Slack.
Il nostro processo funziona grazie a tre principi su cui non scendiamo mai a compromessi:
- Validazione prima dell'esecuzione. La Fase 0 e la Fase 1 esistono specificamente per assicurarci di costruire la cosa giusta prima di spendere la maggior parte del budget per costruirla. Sembra ovvio, ma resteresti sconvolto da quanti progetti partono con "inizia a scrivere codice, lo capiremo strada facendo."
- Trasparenza come impostazione predefinita. Vedi tutto — la board, il codice, il server di staging, i bug. Non c'è nessun posto dove nasconderci, e non vogliamo nasconderci. La fiducia si costruisce sulla trasparenza, non su report di avanzamento patinati.
- Qualità continua, non qualità a fine progetto. Testing, code review e CI/CD avvengono ogni giorno, non in una "fase di QA" alla fine. Questo significa che il prodotto è sempre in uno stato rilasciabile. Se hai bisogno di lanciare prima, puoi. Se le priorità cambiano, ci adattiamo senza ricominciare da capo.
Il Punto di Vista di Michele
Sono in questo settore da abbastanza tempo per sapere che un processo senza disciplina è solo teatro. Chiunque può disegnare un bel diagramma del proprio "processo agile" su un mazzo di slide. Ciò che conta è: fanno davvero code review? Scrivono davvero test? Fanno davvero deploy sullo staging ogni sprint? Chiedi le prove. Chiedi di vedere la loro board di progetto. Chiedi referenze. Se esitano, hai la tua risposta.
Applichiamo Questo Processo al Tuo Prodotto
Questo è il modo in cui costruiamo software. Non qualche volta — ogni volta. Che si tratti di un MVP da $15K o di una piattaforma enterprise da $500K, il processo è lo stesso. Le fasi si scalano, la dimensione del team si adatta, ma la disciplina e gli standard non cambiano mai.
Se stai leggendo questo e pensi "questo è il tipo di team con cui voglio lavorare" — ecco cosa ti suggerisco: inizia con la Fase 0. Una sessione di discovery di 2 settimane in cui ci immergiamo nel tuo business, nei tuoi utenti, nel tuo mercato e nella tua idea di prodotto. Alla fine ottieni un Product Brief validato, un tech stack raccomandato, una tempistica realistica e una stima di budget dettagliata.
Costa tra $3K-$8K a seconda della complessità, e ti dà totale chiarezza su cosa serve per trasformare la tua idea in un prodotto reale. Nessun impegno oltre a questo. Se ti piace il piano ma vuoi un team diverso per eseguirlo — sei proprietario dei deliverable, senza vincoli.
La maggior parte dei clienti che fanno la Fase 0 con noi finisce per restare per l'intero sviluppo. Non perché siano vincolati — perché finalmente si sentono sicuri di sapere esattamente cosa stanno ottenendo, quando lo stanno ottenendo e quanto costa. E quella sicurezza? È tutto il punto.
Prenota una call introduttiva gratuita e parliamo del tuo progetto. Nessun pitch deck richiesto — dimmi semplicemente cosa stai cercando di costruire, e ti dirò onestamente se (e come) possiamo aiutarti.