MASTER PROG BUSINESS — dal business plan al primo cliente pagante¶
Programma dei programmi per business plan.txt (Dense-Armor, 29 SKU, 2026-2029). Ogni riga è una missione con una cartella, come in PROGRAMMA_2.md; ogni riga nasce da una sezione del piano e si conferma con te. Aggiornato il 2026-10-23.
Regole fisse, sempre valide: ogni numero del piano è un claim da validare (lo dice il piano stesso, §2 e §10) e diventa un fatto solo con uno script del repository o con una riga di prova (URL, data, citazione copiata dalla pagina, controllata dallo script check_evidence.py di dense-business); un claim senza prova si scrive assunzione o si ritira. Le parti tecniche si verificano sui paper del quantumrag e sul codice (grep della classe prima di scrivere che esiste o non esiste). Nessuna promessa di ricavi. Le azioni legali, fiscali e organizzative sono del titolare, non di DeepSeek. Cartelle e regole come per le missioni N0x (regole nuove cartelle).
Stato: ✅ fatto · 🟡 in parte · ⬜ da fare · 👤 azione del titolare.
Fondi: si parte da zero o da 100 euro. Il piano è scritto per un seed da 3 M€; con i fondi di oggi vale solo la parte "primo cliente": B01, B02, B03, B04, B07 (stato "ora"). Le altre missioni partono dopo il primo incasso.
Le missioni¶
| # | Missione | Sezioni del piano | Cosa consegna | Come si verifica | Stato |
|---|---|---|---|---|---|
| B01 | Catalogo → codice | §4 e "Riconciliazione catalogo" (29 SKU) | per ognuno dei 29 SKU: le classi di Dense-Armor che lo realizzano (percorso, grep), cosa esiste, cosa è parziale, cosa non esiste; la regola degli alias 17-19 = 26-28 |
grep -rn "class <Nome>" per ogni classe nominata; nessun SKU senza riga |
⬜ ora |
| B02 | Validazione dei claim tecnici | §2 "Vincoli di realtà", §10 rischio 1, "Cosa fare" punto 1 | i 7 SKU dell'onda 1 (#1, #2, #10, #13, #21, #24, #25) e i claim "98 µs VaR", "99% fraud recall", "1.000 ROC-AUC" misurati su dati pubblici (Kaggle, log ArduPilot), con script nel repository, mediana, 90° percentile e massimo, metriche per eventi (Tatbul) e senza F1 con point-adjust (Kim 2021); ogni claim confermato, ridimensionato o ritirato | gli script girano su Kaggle; il numero del piano si confronta con quello misurato | ⬜ ora |
| B03 | Motore di licenza | §7.2 punto 3, §9.1 Q1, §9.3 | licenza firmata Ed25519 offline, revocation list firmata, impronta hardware, server di rilascio (FastAPI + SQLite), SDK client, controllo a runtime; test di manomissione | firma valida e firma alterata; paper: Bernstein 2011 e RFC 8032 | 🟡 ora: il piano scrive "deployment ✅", da verificare nel codice |
| B04 | Pagamenti e consegna self-service | §5.2 self-service, §6.2, KPI "time-to-first-license < 24h", §9.3 | pagamento con Stripe → licenza automatica, pagina di vendita, ricevuta | prova end-to-end in modalità di test; tempo misurato | ⬜ ora |
| B05 | Contatore di volume | §4.1 #1, §5.1, §8.3 (SaaS a volume: #1, #4, #26, #29) | contatore live di eventi, tier per volume, report mensile per cliente | test con stream sintetico etichettato synthetic; il conteggio coincide con quello generato |
⬜ dopo il primo incasso |
| B06 | Pilota #1 AntiFraud | §4.1, "Cosa fare" punto 2 | pipeline di #1 con le classi che B01 ha trovato, dati sintetici e un dataset pubblico (B02), interfaccia a riga di comando o API, installazione in un comando | test, copertura, pagina guida | ⬜ dopo il primo incasso |
| B07 | Pacchetti self-service a basso prezzo | §4.4 #10, #13, #21, #25, #24; onda 1 | per ogni SKU: pacchetto, licenza (B03), guida da zero, esempi | pip install pulito e pagina che stampa l'output scritto |
⬜ ora |
| B08 | Prove di mercato | §3.1 TAM/SAM/SOM, §3.2 buyer, §3.3 trend, §1 | ogni numero del §3 (49,7 mld $, "75% batch", "66 mld $ edge AI", scadenze AI Act, DORA, regolamenti droni UE) con riga di prova o marcato assunzione/ritirato; prezzi dei concorrenti del §7 |
check_evidence.py esce 0; nessuna citazione di sintesi senza URL |
⬜ dopo il primo incasso |
| B09 | Mappa di conformità | §3.3, §4.4 #11 #12 #13 #31, §5.3 AI Compliance Pack | per ogni obbligo (AI Act, DORA): l'articolo del testo ufficiale, quale funzione del prodotto lo copre e quale no; senza scrivere che il prodotto "risolve l'obbligo" | citazioni dei testi ufficiali verificate dallo script | ⬜ dopo il primo incasso |
| B10 | One-pager commerciali | "Cosa fare" punto 3, (C) e (D) | one-pager di #1, #4, #31, poi uno per SKU delle onde 1 e 2; i numeri solo da B02 e dai prezzi del piano | ogni numero ha una fonte nella cartella | ⬜ dopo il primo incasso |
| B11 | Modello finanziario | §8, (A) | foglio con P&L, cassa, unit economics per SKU e tre scenari; ogni ingresso è una cella con fonte o assunzione dichiarata; ricalcolo del §8 e le incoerenze qui sotto risolte | lo script ricalcola ricavi, margine, EBITDA e cassa e confronta con il piano | ⬜ dopo il primo incasso |
| B12 | Pitch deck | (B) | 12 slide, solo dopo B02, B08 e B11 | ogni numero delle slide è nel modello B11 | ⬜ dopo il primo incasso |
| B13 | Marchio e brevetti difensivi | "Cosa fare" punto 4 (#31, #29) | descrizione tecnica dei due moduli ricavata dal codice, per il professionista; la domanda di marchio e di brevetto è del titolare | — | 👤 dopo il primo incasso |
| B14 | SOC2, ISO 27001, AI Act interno | §9.1, §11.1 | piano e fornitori; non è una missione di codice | — | 👤 dopo il primo incasso |
Ordine (da confermare)¶
Perimetro attivo con 0-100 euro: B01 → B02 → B03 → B04 → B07, per dipendenza e non per date. B07 parte con un solo SKU self-service, la strada più corta al primo euro. Dopo il primo incasso: B05 e B06 (volume e pilota), B08 e B09 (prove e conformità), B10, B11, B12. B13 e B14 sono del titolare. Le date del piano (onde da Q1 a Q4 2026) sono passate o in corso: il programma non le usa.
Incoerenze del piano¶
Il piano originale è salvato in old/business plan (originale).txt. In business plan.txt ho corretto solo ciò che si ricava dal piano stesso.
Risolte - Numero di SKU: sono 28, non 29: i numeri 1-31 meno gli alias 17, 18, 19. Corretto in tutto il testo, nell'Area G (9 righe, non 7), nell'Onda 4 (4 SKU, non 5) e nella tabella del §5.1 (4 volume, 9 seat, 7 OEM, 8 enterprise con il revenue share #5, totale 28, contati dalla colonna "Modello"). - Margine lordo: il §1 diceva 82%; il P&L del §8.1 dà 86% (Y1) e 88% (Y3). Il §1 ora riporta i valori del P&L. - Ripartizione del seed: il §1 e il §11.1 divergevano. Ho allineato il §1 al §11.1 (45% team, 30% R&D, 15% legale, 10% marketing), perché è il dettaglio; il "team commerciale da 8 FTE" è ora "8 FTE" con i ruoli reali della tabella delle assunzioni. - Cassa: la cassa finale era seed meno perdite senza spiegare 0,75 M€. Ora è seed più EBITDA cumulato: 2,60 / 3,19 / 4,23 M€, e la nota nel testo dice cosa non è modellato (capex, circolante, imposte). - Somma della SAM: 6,77 M$, scritta ~6,8 (era ~6,7).
Da decidere tu - Clienti a fine Y1: il §8.1 e il §1 dicono 45; l'Onda 4 dice 90 "fine Y1" e l'Onda 3 dice 60 cumulativi. - Cassa del Y1: se esistono davvero 0,75 M€ di uscite oltre l'EBITDA (assunzioni anticipate, capex, circolante), vanno scritte come voce. - Prodotto #29: il catalogo lo dà in abbonamento, la tabella del §8.3 lo conta fra i SaaS a volume. - I 4 prodotti "rinumerati" nella riconciliazione (Hedge, Non-Blocking, Layers, VisionCausal): se sono già alias di altri SKU, gli SKU unici scendono sotto 28.
Controlli che tornano: clienti × ARR medio = ricavi (45 × 15k = 675k; 180 × 22k = 3,96 M; 420 × 15,5k = 6,51 M); EBITDA dei tre anni; somma del mix di ricavi = 6,5 M€; somma del TAM = 49,7 e del SOM = 104.
Decisioni¶
- Nome: si sceglie alla fine. Il prodotto chiamato Dense Guard (cartella
X01_dense_guard, strumento a riga di comando per CSV) è nel catalogo e si unisce allo SKU #1 "Dense-Guard AntiFraud"; l'unione si fa dentro B06. - X02 /
dense-business: la ricerca ha scelto un solo verticale, robot industriali, con 13 righe di prova; il piano ne copre sette. Il rapporto fra i due si decide prima di B06 e B07. - Fondi: si parte da zero o da 100 euro. Perimetro attivo: B01, B02, B03, B04, B07.