Maggio 2023, ufficio di Calcinaia, due monitor accesi su un terminale e un repo Laravel a metà refactor. Avevo appena chiuso una review architetturale di una piattaforma multi-tenant che avevo costruito da zero negli ultimi anni come CTO di una software house del territorio pisano. Il diff della pull request era pulito, lo stack era a posto, la roadmap dei prossimi tre mesi era già scritta. Fondare Romiltec dopo 12 anni da CTO dipendente è la decisione che ho preso quella settimana, dopo aver capito una cosa banale: stavo ancora lavorando come tecnico, ma non avevo più la latenza decisionale di un tecnico. Nei miei post di Workshop racconto come questo si è tradotto, mese dopo mese, in scelte concrete.
Cosa fa davvero un CTO dopo 8 anni nello stesso posto
Premessa onesta: non me ne sono andato per insoddisfazione. La software house dove ero CTO mi aveva dato gli ultimi otto anni più formativi del mio percorso. Ho gestito infrastrutture in produzione, ho assunto e fatto crescere dev junior che oggi sono senior in giro per l’Italia, ho riscritto due volte la stessa piattaforma legacy passando da PHP 5.6 a Laravel moderno, ho introdotto CI/CD su GitLab quando ancora si deployava via FTP, ho convinto la proprietà a investire su un cluster MariaDB con MaxScale invece di tenere il vecchio MySQL stand-alone.
Il punto è un altro. Dopo otto anni nello stesso ruolo, in una struttura strutturata, le decisioni tecniche passavano per livelli che non potevo cortocircuitare. Una scelta di stack che nel 2015 facevo in trenta minuti con il founder davanti, nel 2023 richiedeva tre meeting, una slide deck, l’allineamento con commerciale e il via libera del board. Per scelte giuste, beninteso. Ma il costo cognitivo era cresciuto in modo non lineare con il valore prodotto.
E c’era un’altra cosa: stavo continuando a scrivere codice ogni giorno, ma il codice non era più mio. Era della struttura. Ogni git commit finiva in un repo che non controllavo, dentro un product roadmap che non sceglievo io, con priorità che riflettevano accordi commerciali fatti in stanze dove non ero più chiamato a sedermi.
La sera in cui ho aperto un foglio Excel invece del terminale
Il momento concreto della decisione è stato un venerdì sera di aprile. Avevo appena chiuso una call con un cliente storico della software house, un editore italiano, con richieste tecniche a cui non riuscivo più a dire di no nei tempi che avrei voluto. Ho passato l’ora successiva non a scrivere codice, ma a buttare giù in un foglio i numeri di un’eventuale software house a mio nome: costo fisso mensile minimo, dimensione iniziale del team, soglia di break-even, riserva di liquidità necessaria per i primi sei mesi senza fatturato sicuro.
I numeri tornavano. Non con margini larghi, ma tornavano. Romiltec non sarebbe stata un salto nel buio: sarebbe stata l’estensione naturale di un set di skill che avevo affinato per dodici anni come tecnico e per otto come CTO. Sviluppo backend Laravel, sistemi Linux, MaxScale, Hestia, Docker, qualche pipeline FastAPI per i lavori AI che stavano iniziando a chiedere tutti.
Le tre scelte di setup, prese il primo mese
Ho registrato la S.r.l. ad aprile 2023 e da lì ho preso tre decisioni che ancora oggi sono la spina dorsale di Romiltec.
Prima. Niente livelli intermedi. Nessun project manager, nessun account, nessun commerciale. Il cliente parla con chi scrive il codice. Questa scelta è la più contestata da chi mi ha consigliato sui primi passi (in tanti me lo hanno detto: non scala). La mia tesi è che scala benissimo se accetti il vincolo dimensionale a monte: cinque persone, non venti. Se hai cinque senior che parlano direttamente coi clienti, elimini l’80% delle riunioni di allineamento interno. Vediamo nei prossimi mesi se reggo.
Seconda. Prezzo fisso al mese, sprint agili, paghi in anticipo. Niente preventivi a corpo, niente time and materials. Il cliente compra capacità di delivery, non ore. Questo sposta tutto il rischio operativo su Romiltec: se sbaglio le stime, perdo io. Lo accetto perché ho otto anni di stime alle spalle e so dove sbaglio sistematicamente (UI fini, integrazioni con SDK di terze parti senza sandbox, edge case sui flussi di pagamento). Per i primi clienti il rischio è mio: per i clienti dieci e venti, sarà più equo.
Terza. Niente codice a perdere. La regola più tecnica delle tre. Ogni progetto cliente è un’occasione per estrarre componenti riutilizzabili: un service WordPress, un microservizio FastAPI per la stilometria, uno scheduler Laravel per i job ricorrenti. Non per fare consulenza più veloce: per costruire, sotto al fatturato dei servizi, una codebase di prodotto che a un certo punto, se va bene, diventerà la nostra economia primaria.
Cosa NON ho portato da CTO dipendente
Tre cose che mi sono lasciato indietro consapevolmente.
La religione del processo. In strutture grandi i processi sono indispensabili: SLA su PR review, RFC scritte, retrospettive settimanali con board. In una società di cinque persone diventano peso morto. Ho deciso che Romiltec lavora per merito tecnico visibile (il codice in produzione, i log, la latenza p99), non per documenti interni.
La paura di dire no a un cliente. Da CTO dipendente i clienti li difendi anche quando hanno torto, perché la trattativa l’ha chiusa qualcun altro. Da founder posso permettermi di rifiutare un progetto se non rientra nello stack, nei valori o nei tempi che reggo con il team. È una libertà che pesa.
L’idea che la dimensione sia un obiettivo. Per anni ho lavorato in società che misuravano la salute aziendale dal numero di dipendenti. Io misurerò Romiltec dalla profittabilità per persona e dalla R&D che riusciamo a finanziarci da soli. Bootstrap, autofinanziato, niente investitori a meno di motivi tecnici stringenti.
I numeri di partenza (gli unici onesti che ho)
Nel maggio 2023, alla fondazione di Romiltec, eravamo in tre: io full-time, un senior dev part-time, un terzo collaboratore in onboarding. Il fatturato dei primi tre mesi è stato sufficiente a coprire il costo del lavoro e poco altro. Niente pitch deck, niente round, niente traction. Solo una S.r.l., un repo GitHub privato e una whiteboard con scritto: prodotto fra due anni.
Non sto vendendo una storia di successo. La conferma della tesi, se arriverà, sarà nei numeri dei prossimi due anni: il pivot a piattaforma, la crescita del fatturato, il portfolio di testate. Per ora quello che posso dire onestamente è solo questo: fondare Romiltec dopo 12 anni da CTO dipendente non è stato un atto di coraggio, è stato un calcolo a tavolino, fatto sapendo dove avevo sbagliato negli anni prima e dove invece il mio modo di lavorare poteva reggere senza la coperta della struttura.
Tre cose che mi porto a casa dal primo mese da founder
Le scrivo qui per ritrovarle quando rileggerò questo post fra due anni.
Una. La latenza decisionale è la prima vera differenza fra CTO dipendente e founder tecnico. Decidere alle 9 del mattino e fare il primo commit alle 9:15 non è un dettaglio: cambia il tipo di problemi che riesci ad affrontare in una settimana.
Due. Il cliente ti rispetta di più se sa che parla con il proprietario del codice. La dinamica commerciale cambia, anche sui prezzi. La gentilezza è un metodo, non un atteggiamento: vale dal primo giorno.
Tre. Le scelte di setup contano più delle scelte di strategia. Niente commerciali, prezzo fisso, niente codice a perdere: tre vincoli posti il primo mese. Tutta la traiettoria dei due anni successivi sarà la conseguenza naturale di queste tre regole, non di una visione di mercato. Ho letto tanti founder come Patrick McKenzie ripetere lo stesso punto: il setup di vincoli iniziale è il vero design strategico di una società di servizi.
Stavo ancora chiudendo la pull request della mia precedente vita lavorativa quel venerdì di aprile. Il git push finale l’ho fatto la settimana dopo. Da lì in poi, il repo è nostro.