Il momento in cui ho capito che stavo costruendo un prodotto, non un servizio

Marzo 2024, una call con un caporedattore di un gruppo editoriale italiano, partner da quasi due anni. Mi mostrava in screen share il backend che gli avevamo scritto, mentre nello stesso ufficio due desk preparavano la chiusura del pomeriggio. È in quel momento che ho capito che il pivot da servizi a prodotto non era più un’ipotesi tattica: era già successo, dentro il loro workflow. Bisognava solo estrarlo come piattaforma. Vedi anche gli altri post di questa rubrica: Workshop.

Il metodo: stare nel processo

Anni fa, quando ottimizzavo un software di magazzino, ho passato una settimana a chiudere pacchi col reparto. Scotch, etichette, attese del corriere, code di fine turno. Da lì capisci dove si inceppa il flusso reale, non leggendo il backlog dei ticket.

Con Romiltec lavoriamo da software house: i clienti non li vediamo in faccia ogni mese. Ma li sentiamo, li guardiamo lavorare in screen share, leggiamo i log dei loro deploy, ascoltiamo i caporedattori discutere col commerciale durante le call settimanali di progetto. Lo strumento è cambiato, il metodo no: capire il processo che il software supporta, non solo il software.

Avevamo iniziato a costruire per il gruppo editoriale a metà 2022, con un primo progetto custom: WordPress multi-site come CMS editoriale, un layer in Laravel come application service (REST verso WP via token service-to-service, queue Horizon per i job lunghi), prime integrazioni con text-davinci-003 di OpenAI per assistere le bozze (qualità grezza, ma sufficiente per il workflow di prima assistenza), schema DB tarato sulle redazioni multi-testata (entità publication, desk, author, draft, revision). Deploy stabili, downtime quasi zero, una partnership che si era estesa a un secondo e poi a un terzo prodotto della stessa casa, ognuno con il suo workflow specifico ma costruito sopra le stesse fondamenta editoriali.

Per due anni quel partner è stato il nostro laboratorio in produzione: call settimanali coi desk, screen share durante i bug, telemetria sempre aperta. I requisiti reali li raccoglievamo sentendo i caporedattori discutere col commerciale, le ottimizzazioni nascevano dalla domanda perché questo passaggio ti rallenta? fatta a una persona che aveva la tastiera in mano dall’altro lato dello schermo.

La quarta conferma

A inizio 2024 sono arrivati altri tre editori italiani con richieste che ricalcavano lo stesso pattern: multi-testata, ruoli editoriali simili, automazione AI sopra le bozze (con OpenAI ormai a GPT-3.5/4, qualità diversa rispetto al 2022), pipeline di stilometria. Quattro richieste in cinque mesi, senza che le avessimo proposte. A quel punto la coincidenza non reggeva più.

Ma il vero motore di un pivot da servizi a prodotto non è mai il numero. Era che il prodotto lo conoscevamo già: lo avevamo testato in produzione per due anni col partner, con persone vere, in turni di chiusura veri. Il quarto editor è stata la conferma che il pattern era universale, non un caso isolato di un singolo gruppo.

Quel preventivo non l’ho mai preparato. Ho richiamato il quarto editor la mattina dopo e gli ho proposto una soluzione diversa dal custom: la stessa cosa, ma su una piattaforma multi-tenant che stavamo per estrarre dalla codebase, con accordo formalizzato con il partner storico. Costo più basso per lui, lavoro più ordinato per noi. Ha detto sì in quindici minuti.

Quel quarto editor è stato il primo tenant esterno di quello che oggi si chiama AI Multisite, il prodotto di Romiltec per la gestione di redazioni multi-testata. Il nome del cliente lo tengo fuori, è una scelta loro e una mia regola.

Cosa significa il pivot da servizi a prodotto sul codice

I primi sei mesi non sono stati epici, sono stati un refactor lungo, fatto a quattro mani col partner storico. Il vantaggio di una collaborazione lunga è che non lavori per loro, lavori con loro: ogni astrazione passava prima dal loro deploy in produzione, poi dal nuovo tenant.

In ordine, il lavoro tecnico:

1. Codifica esplicita dei processi editoriali. Tutto quello che era ancora lo sa il caporedattore lo abbiamo scritto come state machine: stato della bozza, ruoli che possono transitarla, side effect di ogni transizione (notifiche, embedding, indicizzazione, hook editoriali).
2. Astrazione multi-tenant in shared-schema. Schema DB con tenant_id come discriminante, applicato come Eloquent Global Scope su tutti i model tenant-aware, middleware HTTP che injecta il TenantContext in request, queue payload e cache key prefix. Scelta consapevole di shared-schema invece di database-per-tenant: con due dev e mezzo, il costo operativo di N database (backup, migrations, monitoring) era insostenibile.
3. Adapter unificato per i provider LLM. Una sola interfaccia LlmProvider con implementazioni: all’inizio solo OpenAI, durante l’estrazione 2024 abbiamo aggiunto Anthropic (Claude era appena arrivato in GA) come secondo backend e parametrizzato il routing per costo, latenza e capability per richiesta. Ogni chiamata loggata con tenant_id, modello, token in/out e costo in euro: base per il pricing al tenant e per il fallback su modelli più economici a quota superata.
4. Pipeline di stilometria come microservizio FastAPI. Consumer su Redis/Horizon, payload con riferimento al draft, callback al backend Laravel via webhook firmato. Disaccoppiare il ciclo di rilascio del modello stilometrico dal deploy del backend ci ha permesso di iterare sul modello senza toccare il monolite editoriale.
5. Migrazione dati del partner storico. Script idempotenti, re-mapping degli ID legacy in chiavi composite (tenant_id, id), replay dei job pendenti dalla dead-letter queue di Horizon, finestre di downtime negoziate testata per testata in call con il referente tecnico del cliente. Niente big bang.

Sopra: CI/CD da zero in GitHub Actions, container Docker per backend e workers, deploy su VM Debian Proxmox con dataset ZFS dedicato per tenant, tre ambienti (dev, staging, production).

Per sei mesi ho fatto più il sistemista e il DevOps che il product manager. Niente di scenografico. Eravamo due e mezzo: io, un senior dev full-time, un dev part-time. Entrambi, in momenti diversi, mi hanno chiesto siamo sicuri?. Ho detto sì entrambe le volte.

I numeri

A marzo 2024, il giorno della decisione di pivot da servizi a prodotto: 15.000 € di MRR, una manciata di clienti editoriali, due anni di partnership profonda con il gruppo storico, quattro nuovi tenant in coda.

A fine 2024 il fatturato Romiltec era cresciuto del 229% sul 2023, frutto della transizione del fatturato custom legacy verso il ricorrente di piattaforma e dell’arrivo dei nuovi tenant. Il fatturato è rimasto fermo per qualche mese durante la fase di estrazione: in piena astrazione non si possono accettare progetti custom che non vivano sulla piattaforma, sennò l’astrazione si sporca subito e si torna indietro.

Il pivot non è merito del numero. È merito di quando è stato deciso: dopo due anni passati nel processo che volevamo prodottizzare, non prima.

Servizio o prodotto: la differenza pratica

Per anni avevo letto founder raccontare il pivot da servizi a prodotto come se fosse una questione di pricing. Sul campo si vede che è un cambio di metodo: il valore non lo crei più con le ore, lo crei una volta sola e lo replichi sui tenant. E le buone astrazioni le scrivi solo dopo aver vissuto il processo, non leggendolo in un PDF di requisiti.

Quello che mi sono portato a casa dal pivot da servizi a prodotto

Tre cose, in ordine di importanza tecnica.

Prima. L’astrazione giusta la fai dopo aver vissuto il processo, non dopo aver visto un diff fra repo. Sandi Metz ha la regola: duplica due volte, astrai alla terza. Kent C. Dodds chiama questo principio AHA, Avoid Hasty Abstractions. Vale per il codice quotidiano e ancora di più per il portfolio del pivot da servizi a prodotto: se astrai dopo due custom diverse, senza essere stato dentro al workflow, l’astrazione si rompe alla terza implementazione. Ogni pivot da servizi a prodotto sano nasce qui, da una dolorosa pazienza tecnica.

Seconda. I pivot conviene farli in silenzio. Annunciarli prima costringe il team a difendere una posizione che non ha ancora codice né processo dietro. Sei mesi dopo, se ha funzionato, l’annuncio lo fa la roadmap da sola.

Terza. Le partnership lunghe sono il vero R&D di una software house. Il gruppo editoriale per noi non è stato fatturato ricorrente, è stato un laboratorio in produzione per due anni. Nessun consulente esterno mi avrebbe dato lo stesso valore: ti puoi pagare il consulente migliore del mondo, ma non hai modo di vedere il caporedattore in chiusura di edizione che ti mostra, schermo alla mano, dove l’interfaccia lo aiuta e dove lo rallenta.

Stavo per preparare un preventivo. Se l’avessi mandato, oggi manterrei quattro repo paralleli invece di una piattaforma con un manifest di tenant. La differenza, in retrospettiva, l’hanno fatta i due anni passati con la tastiera dentro al flusso del partner: senza quelli, il quarto editor sarebbe sembrato solo il quarto progetto custom, e il pivot da servizi a prodotto sarebbe rimasto una buona idea senza fondamenta.