22 dicembre 2023, ufficio di Calcinaia, le 19:30. Il dev di backend ha chiuso il PC un’ora fa, la ragazza in amministrazione è andata via prima per il regalo della figlia, e io sto guardando la fattura del mese che ho appena emesso. Sullo schermo accanto, il foglio Excel con le entrate degli otto mesi di Romiltec: aprile 2023 (zero), maggio (zero), poi una curva che non assomiglia a un hockey-stick di slide LinkedIn ma a una scala con qualche gradino più alto e due piani senza scalini. Otto mesi, tre persone, una società in attivo. È il momento del primo bilancio reale, e questo post di Workshop lo scrivo a mente lucida, prima delle vacanze, prima che gennaio arrivi col suo carico di ottimismo retrospettivo.
Cosa è successo in otto mesi (qualitativo)
Romiltec è stata fondata ad aprile 2023, dopo dodici anni passati in software house italiane (territorio italiano, ultima posizione da CTO). I primi due mesi sono stati setup: costituzione società, partita IVA, conto azienda, contratti standard di progetto, primi due clienti che venivano dal mio network territoriale toscano. Da giugno in avanti il pipeline si è stabilizzato su un ritmo sostenibile: una call di scoping nuova ogni due-tre settimane, una conversione su tre, sprint mensili a prezzo fisso (sul modello che ho descritto nel post di luglio di questa rubrica).
Numeri operativi che ho voglia di mettere su questo post, perché sono onesti e basta:
- Tre clienti attivi contemporaneamente a dicembre 2023, due dei quali partiti nei mesi estivi e ancora attivi (rinnovo silenzioso degli sprint mensili). Tutti e tre nel mondo editoriale italiano.
- Due dipendenti oltre a me: un dev senior backend con ~10 anni di esperienza Laravel, e una ragazza part-time per amministrazione e supporto ai clienti.
- Smart working diffuso. Io fra Calcinaia (Pisa) e Scordia (Catania) a seconda della settimana, il dev di backend in remoto stabile dalla Sicilia, l’amministrativa part-time in presenza qualche ora a settimana a Calcinaia.
- Zero ore di marketing pagato. Zero campagne, zero adv, zero SEO esterna. Pipeline tutto inbound da network e da blog tecnico.
- Codice in produzione su tre stack diversi (tre clienti, tre repository), con una base comune che sto già pensando di estrarre in libreria interna nel 2024.
Niente fund raising, niente VC, niente metriche da SaaS unicorno perché Romiltec a dicembre 2023 non è un SaaS, è un service business che fra dodici-diciotto mesi forse si trasformerà in qualcosa di più product-oriented. Per ora resta un service business sano: cassa positiva, clienti che pagano a 30 giorni, niente leva finanziaria.
Lo stack che funziona (overview tecnica, niente nomi reali di host)
In otto mesi la base tecnica con cui Romiltec lavora si è assestata su un setup che ora sento maturo. Lo lascio qui per chi è arrivato a questo post da una ricerca sullo stack di una software house piccola.
Backend. Laravel 10 su PHP 8.2, code-first con migration, queue Horizon su Redis per i job lunghi (import editoriali, generazione thumb, fetch di feed esterni). Niente framework esotici. Laravel mi permette di assumere dev italiani che lo conoscono già senza tre mesi di onboarding.
CMS. WordPress per il front-end editoriale, in container Docker, parla con il backend Laravel via REST API e Application Passwords. Scelta pragmatica: i giornalisti di una redazione italiana sanno usare WP, e il costo di formazione su un CMS proprietario sarebbe più grosso del costo di mantenere WP in produzione.
Database. MariaDB su VM Hestia. A dicembre 2023 ancora single-instance per ogni cliente. La replica circolare fra due nodi (codename interni di squadra, james e jason) la sto disegnando per il primo trimestre 2024, sui clienti con traffico più alto.
Search. Sui clienti con ricerca full-text seria, già a dicembre sto valutando Typesense. MeiliSearch è in produzione su un cliente come compromesso; Typesense è il candidato per il 2024.
Cache, reverse-proxy, TLS. nginx fastcgi cache per il front, Redis come object cache di WordPress. Davanti ai container, Caddy con TLS DNS-01 via Cloudflare. Era setup sperimentale a maggio, a dicembre è il default.
Telemetria. Grafana + Prometheus su una VM dedicata. Alert via email su tre soglie principali: 5xx rate, RAM, disk. Niente PagerDuty (non serve a tre persone), niente on-call formalizzato (ci sono io di notte, e questa è una cosa che voglio cambiare nel 2024).
Backup. restic su Backblaze B2 zona EU, retention 30 giorni daily + 12 settimane weekly. Scelta che rifarei dieci volte su dieci.
Repo runbook interno. Una repo Git separata dal codice cliente con i runbook operativi (deploy, restore, incident playbook). A maggio era un Notion confuso, a dicembre è una repo strutturata.
Cosa cambierei, se rifondassi Romiltec oggi
Una cosa, principalmente: avrei messo un sistema di project tracking interno fin dal primo giorno. A maggio 2023 ho iniziato con email + WhatsApp con i clienti, pensando che i tool fossero overhead per una società di tre persone. A novembre ho dovuto ricostruire da zero la timeline di un progetto per rispondere a una richiesta cliente di rendicontazione, e mi ci sono volute due giornate intere di archeologia su email e Slack. Il costo di un tool semplice (per quanto basico) dal giorno uno sarebbe stato inferiore al costo di quelle due giornate.
Il resto delle scelte le rifarei uguali. Costituzione società in S.r.l. e non in regime forfettario (un anno dopo è una scelta che paga). Smart working full-remote sui dev (mi ha permesso di assumere il senior in Sicilia senza farlo trasferire). Zero commerciali e prezzo fisso al mese (i due post precedenti di questa rubrica spiegano perché).
Tre cose imparate (una per sezione)
Vado al cuore. Otto mesi di operatività mi hanno insegnato tre cose che a giugno 2023 non sapevo, e che metterò in pratica più sistematicamente nel 2024.
Uno: la pianificazione settimanale è il vero strumento di leadership con dev senior remoti
A maggio 2023, quando il dev senior ha iniziato, io facevo “review on demand” dei suoi PR e niente di più. Pensavo che un senior con dieci anni di esperienza avesse bisogno di autonomia, non di struttura. È vero a metà: non ha bisogno di micro-management quotidiano, ha bisogno di un ritmo settimanale stabile.
A luglio ho introdotto un ritmo fisso: lunedì 10:00 una call di un’ora in cui rivediamo lo sprint della settimana e chiariamo le priorità. Venerdì 17:00 una call di 30 minuti di chiusura: cosa è andato in produzione, cosa è in coda, cosa servirà al cliente la settimana dopo. Niente ticket Jira, niente burndown chart. Solo il ritmo.
Dopo tre mesi il dev senior aveva una visibilità sul portafoglio clienti pari alla mia. Non era più “il dev che lavora sul cliente A”: era un co-decisore sulle priorità. Quando arrivava una richiesta fuori sprint, sapeva già quale cliente aveva precedenza in quella settimana e poteva rispondere senza chiedermelo. È il tipo di leverage che, in una società di tre persone, ti permette di prendere il quarto cliente senza saturarti come founder.
La lezione operativa: con un dev senior remoto non serve micro-management quotidiano, serve un ritmo settimanale visibile. Due call brevi alla settimana sono il minimo strutturale.
Due: il preventivo va scritto tutto in italiano semplice perché i clienti non leggono PDF da 12 pagine
A maggio 2023 il mio primo preventivo era un PDF da 11 pagine: premessa metodologica, architettura proposta, milestone, condizioni economiche, gantt provvisorio. Era il preventivo che avrei scritto da CTO dipendente. Il cliente lo ha letto a metà (lo so perché in una call mi ha fatto domande su cose scritte a pagina 7) e ha firmato perché si fidava di me, non perché aveva capito tutto.
A settembre, dopo che un altro cliente mi ha confessato in call ridendo di aver firmato il PDF “leggendo solo l’ultima pagina dei costi”, ho riscritto il template. Il preventivo attuale è di 3 pagine, scritte in italiano da non-tecnico:
- Pagina 1: cosa stiamo costruendo (in 200 parole, con vocabolario del cliente non mio).
- Pagina 2: cosa NON stiamo costruendo in questo sprint (il cap di scope esplicito, sempre).
- Pagina 3: costo mensile, durata, condizioni di rinnovo, accesso ai dati.
Niente diagramma, niente milestone elaborate, niente premessa metodologica. Se il cliente vuole un dettaglio tecnico, glielo do in call. Il PDF deve essere il riassunto che lui riapre fra sei mesi per ricordarsi cosa abbiamo deciso, non un trattato.
La lezione operativa: per un cliente non-tecnico (tutti i miei clienti editoriali del 2023 sono non-tecnici dal punto di vista del codice), il preventivo è un documento di chiarezza, non di precisione. Più è corto e leggibile, più protegge entrambe le parti dalle ambiguità future.
Tre: il rapporto fra ore tecniche e ore di chiarimento al cliente è 1:1, non 9:1 come pensavo a giugno
Questa mi ha sorpreso di più. A giugno 2023, calcolando il prezzo fisso al mese (vedi il post di luglio), assumevo il 75% del tempo del dev come fatturabile e il restante 25% come “tempo non produttivo” (ferie, malattia, formazione, riunioni). Quello che non avevo modellato era il tempo di chiarimento col cliente, e il motivo è semplice: lo facevo tutto io, e nei miei calcoli del costo del dev senior non comparivo.
Dopo otto mesi, con il calendario in mano, posso dire che il rapporto fra “ore tecniche del dev” e “ore di chiarimento al cliente che ho fatto io” è circa 1:1. Per ogni ora di codice che il dev senior scrive, io ho passato circa un’ora con quel cliente per chiarire requisiti, gestire feedback, tradurre fra linguaggio editoriale e linguaggio tecnico. A giugno pensavo fosse 1:9. Avevo sbagliato di un ordine di grandezza.
Il motivo: i clienti editoriali italiani non sono PM tecnici. La traduzione fra il loro linguaggio operativo (“chiudere l’edizione delle 17 senza che le foto blocchino la pubblicazione”) e l’astrazione di codice (“workflow asincrono di upload con stato di pubblicazione indipendente dallo stato delle media”) è un lavoro di costruzione concettuale che richiede ore. Quel lavoro lo fa il founder.
Conseguenza pratica per il pricing: il costo founder per cliente va modellato esplicitamente. Nel preventivo del 2024 sto inserendo una voce coordinamento e relazione cliente che era nascosta nel margine del 2023. Se ogni cliente costa 1:1 ore mie, il limite hard è quattro-cinque clienti attivi simultanei prima che il founder diventi il bottleneck.
La lezione operativa: il fattore limitante di una software house piccola non è la capacità di codice, è la capacità del founder di stare in call con i clienti. È un numero che va misurato e protetto.
Cosa farò diversamente nel 2024
Tre cose, in ordine di priorità.
Primo, alzare il livello di astrazione del backend Romiltec estraendo una libreria interna che capitalizzi le scelte ricorrenti dei tre clienti del 2023 (workflow editoriale, REST API, gestione dei ruoli). Smettere di riscrivere lo stesso layer su ogni progetto è il single point con il payback più immediato sul costo di delivery.
Secondo, formalizzare il ritmo settimanale del team su tutti i nuovi entranti del 2024. Lunedì 10:00, venerdì 17:00, niente eccezioni per i primi tre mesi. Il rito è il rito.
Terzo, ridisegnare il preventivo standard in versione 3 pagine come default, con il template salvato in una repo interna invece che in una cartella sul mio Mac. Banale, ma riduce la frizione di emissione di un preventivo da due ore a venti minuti.
Niente di rivoluzionario. Una società di tre persone che cresce con disciplina nei prossimi dodici mesi, senza forzare la curva. Se a dicembre 2024 saremo cinque persone con quattro clienti attivi e un primo abbozzo di prodotto interno, sarà già un anno meglio di quanto avrei previsto a giugno. Ne riparliamo in un altro bilancio fra dodici mesi.