Due settimane. Poi decidi tu.

Sai già cosa va fatto. Hai la scaletta delle funzionalità, hai un'idea di come costruirle, e quello che ti manca non è un piano: è sapere se andiamo veloci quanto ti serve.

Non c'è modo di rispondere a parole. Si prende una cosa dalla tua lista e si fa.

$ settimana 1 → controlli tutto, riga per riga. È giusto così

$ settimana 2 → controlli quello che ti preoccupa

$ poi → decidi tu se c'è un poi

Cosa succede davvero

Cosa ottieni

Codice che resta tuo, non una demo

Si sviluppa qualcosa che avevi già in programma di fare. Alla fine ce l'hai, funzionante, nel tuo repository — anche se decidi di non continuare. E hai cominciato presto e con poco: due settimane adesso, invece di due mesi di codice da far controllare dopo.

Cosa vedi

Il metodo in funzione, non descritto

Un ciclo di lavoro completo: come si specifica un'attività, come si stima, come passa dalla revisione, come arriva in un ambiente dove la provi. È lo stesso ciclo di un progetto vero, fatto una volta.

Cosa ti impegna

Due settimane e qualcuno che risponda

Serve un interlocutore tecnico che possa decidere in giornata. È l'unico requisito, ed è anche il motivo per cui funziona meglio con un CTO che con un founder non tecnico.

Due settimane costano di più a giornata di un impegno lungo — te lo diciamo adesso invece che dopo. È l'unico inizio che non chiede niente in cambio.

Cosa non è

Non è un impegno a continuare

Finisce, e finisce davvero. Se non ti sei trovato, hai comunque una funzionalità in più e sai una cosa che prima non sapevate.

Starter

Le porte.

Build, Scale e Rescue sono impegni lunghi, e prima di prenderli è normale volerci vedere chiaro.

Gli starter sono il modo di cominciare senza impegnarsi: durano poche settimane, costano poco, e finiscono con qualcosa in mano che vale anche se poi lavori con altri. Tre ti danno una risposta prima di partire: un piano, una verifica, un audit. Il quarto, il Dry Run, ti fa vedere come lavoriamo su un pezzo vero del tuo progetto.

Come si lavora, da lì in poi

  1. Prima

    Decidi tu su cosa si spende la capacità

    Ogni attività viene descritta, progettata dal punto di vista tecnico e dell'interfaccia, stimata in impegno, e resta ferma finché non la approvi. Così vedi cosa verrà realizzato prima che si spenda il tempo per farlo. Non stai approvando una fattura: stai decidendo dove va a finire il tempo che hai già comprato.

  2. Ogni giorno

    Vedi la pipeline mentre si muove

    Hai accesso allo strumento dove vivono le attività: in che stato sono, in quale sprint di due settimane cadono, se si è in anticipo o in ritardo. Non un riepilogo a fine mese — la stessa vista che usiamo noi.

  3. Durante

    Nessuno rilascia il proprio codice

    Chi scrive non è chi approva. Ogni modifica passa da un secondo tecnico prima di arrivare da qualsiasi parte.

  4. Prima del rilascio

    Un ambiente dove provarlo tu

    Il lavoro arriva dove puoi vederlo prima della produzione. Se non è come te l'aspettavi, torna indietro.

  5. Sempre

    Codice e server restano tuoi

    Nessun vincolo tecnico che ti costringa a restare.

Il metodo, nel dettaglio