Quanto reinvestiamo in R&D: il 26-50% spiegato voce per voce

Su profilo aziendale e nei pitch dico spesso che Romiltec reinveste tra il 26% e il 50% del fatturato in R&D. È una frase che mi è stata chiesta di motivare più volte: dai commercialisti che devono qualificare la posta nei bilanci, dai potenziali clienti che vogliono capire perché un’agenzia da 5 persone fa quello che fa, da altri founder bootstrap che si chiedono dove finiscano i ricavi.

Questo post è il dettaglio per voce. Non farò il salto agli importi assoluti in euro, perché il rapporto percentuale è il numero che racconta meglio le scelte di un’azienda autofinanziata: 26% in un trimestre carico di custom dev fatturato, 50% in un trimestre dove l’80% del team è dietro a sviluppo prodotto. Vedi anche gli altri post di questa rubrica: Workshop.

Perché una forchetta, non un numero singolo

Il primo equivoco da chiarire: in una software house bootstrap senza investitori esterni, il budget di R&D non è un numero pianificato a inizio anno. È il residuo di una funzione semplice: ricavi del trimestre meno costi diretti (stipendi imputabili al delivery custom, hosting per i clienti, servizi terzi pass-through) meno cassa di sicurezza. Tutto il resto, in pratica, è R&D.

Questo significa che la forchetta non si stringe per scelta: si stringe quando la composizione del team cambia. In un trimestre con due nuovi clienti enterprise da onboardare, dove serve avere 3 persone full-time sul delivery, l’R&D scende verso il 26%. In un trimestre dove la pipeline custom è bassa e il team riconverte le ore su roadmap prodotto, sale verso il 50%.

La forchetta non è una promessa di marketing: è la finestra dentro cui ci muoviamo, dichiarata all’utente perché eviti di credere che reinvestire il 50% sia automatico ogni mese.

Le quattro voci di spesa

Quando guardo le timesheet del team a fine trimestre e segno cosa è stato custom-billable e cosa è stato R&D interno, le ore “non fatturate al cliente” si distribuiscono su quattro voci stabili.

1. Sviluppo prodotto core (40-55% della quota R&D)

La voce più grossa, quasi sempre. È lo sviluppo di AI Multisite, il prodotto SaaS per redazioni multi-testata che gestisce 45M di visite/mese su 40+ testate. Sotto questa voce finiscono:

• iterazioni sul backend Laravel (Action-DTO-Policy architecture, refactor periodici di sezioni che hanno raggiunto la complessità critica)
• frontend Vue 3 + Vuetify, con cicli di refactor sui componenti che ricorrono in più viste (data table editoriali, modali di review AI)
• microservizio analytics in FastAPI + ClickHouse, dove la maggior parte del lavoro recente è stata sull’ottimizzazione delle materialized view e sul parallel query execution
• stilometria computazionale: il modello a 10 parametri proprietario che converte uno stile autoriale in istruzioni quantitative per LLM
• adapter multi-provider LLM (OpenAI, Anthropic, xAI, Google, DeepSeek, Mistral, Ollama, DeepL): ogni nuovo modello rilasciato richiede valutazione, tuning dei prompt, A/B test in produzione
• integrazione WordPress nativa: sync bidirezionale via REST API che dobbiamo mantenere coerente con i breaking change di ogni major WP

È la voce che giustifica più di tutto il pivot da servizi a prodotto: senza R&D continuativo su AI Multisite, il prodotto smette di essere competitivo nel giro di due trimestri. I provider LLM evolvono troppo in fretta per un ciclo di rilascio di sei mesi.

2. Sperimentazione su prodotti minori (15-25% della quota R&D)

La voce che fa storcere il naso ai consulenti finanziari, ma che per noi è strategica. Sotto questa voce abbiamo R&D su prodotti adiacenti che ci permettono di testare in produzione idee architetturali (multi-tenancy, integrazioni AI verticali) prima di portarle in piattaforma.

Perché ce li teniamo, considerando che il fatturato attuale viene quasi tutto da AI Multisite, Tech Performance e custom dev? Per due ragioni tecniche concrete:

• ognuno di questi progetti esplora uno stack o un pattern che poi entra nella cassetta degli attrezzi del prodotto principale (pattern mobile-first che useremo per la futura mobile app di AI Multisite, sperimentazioni multi-tenancy che diventano banco di prova per il prossimo refactor di AI Multisite)
• il team senior si annoia con un solo prodotto. Avere due o tre contesti tecnici diversi, anche a tempo parziale, tiene alta la curva di apprendimento e bassa la curva di turnover

3. Infrastruttura interna (10-20% della quota R&D)

L’infrastruttura non fattura, ma se non funziona non fattura nulla nemmeno il resto. Sotto questa voce:

• lab Proxmox interno: cluster di nodi PVE per ambienti di staging, esperimenti di ML, test di scalabilità. Su questo lab abbiamo simulato i carichi che poi sono andati in produzione sul cluster del network editoriale
• container orchestration: pipeline GitHub Actions self-hosted, container registry interno, build cache condivisi
• monitoring stack: Prometheus + Grafana + Loki + Sentry, con dashboard custom per ogni prodotto. La parte più costosa in ore è la manutenzione delle alerting rule: troppo aggressive generano fatigue, troppo lasche fanno scoprire i problemi al cliente
• HA databases: cluster MariaDB con replica circolare e MaxScale come router, OpenSearch su cluster a 3 nodi LXC + dashboards. Lavoro continuo di tuning, capacity planning, runbook per gli incident
• internal tools: dashboard interne per metriche editoriali, automazioni di ops, documentazione tecnica. Non si vende, ma fa risparmiare ore al team ogni settimana

Questa voce è dove un’azienda che sta crescendo paga il debito tecnico di quando era piccola. È invisibile ai clienti ma misurabilissima in MTTR sugli incident.

4. Ricerca AI applicata (10-20% della quota R&D)

La voce più giovane, ma in crescita. Sotto questa voce finiscono ore di ricerca che non hanno un deliverable di prodotto immediato:

• stilometria computazionale: il modello a 10 parametri è già in produzione, ma la ricerca su come estenderlo a nuove lingue, su come gestire la variabilità intra-autore (lo stesso giornalista scrive diverso fra editoriale e cronaca breve), su come validare il modello contro un golden set, è continua. Esiste un paper in lavorazione che vorremmo sottomettere a una conferenza italiana di NLP
• multi-LLM orchestration: il routing fra provider non è banale. Quale modello per quale task, con quale temperature, con quale fallback su rate limit. Stiamo costruendo un benchmark interno che testa la stessa generazione su 8 provider e segna quale risposta passa il filtro stilometrico con score più alto
• fine-tuning sperimentale: abbiamo provato fine-tuning di Llama 3 e di Mistral su un golden set di articoli editoriali. La conclusione provvisoria è che il fine-tuning non batte il prompt engineering ben fatto + stilometria, ma il lavoro di valutazione ha tirato fuori dati che usiamo per migliorare i prompt
• firewall semantico: validazione e riscrittura semantica degli input per prevenire prompt injection, che oggi è un layer di sicurezza, ma domani potrebbe essere un componente standalone

Questa voce è quella più vera nel senso accademico del termine: spesso non produce una feature, produce un report, un benchmark, una decisione di architettura. È anche la voce che ci permette di scrivere le menzioni R&D nei bilanci e nella documentazione per il registro startup innovative.

Trade-off: il prezzo dell’autofinanziamento

Il rovescio della medaglia di reinvestire 26-50% in R&D, senza investitori che mettano cassa, è che ogni euro speso in prodotto è un euro non disponibile per:

• assumere subito un altro senior dev (la decisione di restare in 5 è anche una conseguenza di questa scelta)
• aprire la pipeline commerciale con figure dedicate (non abbiamo commerciali interni, la crescita è 100% da passaparola fino a oggi)
• comprare ads o partecipare a fiere di settore con stand pagati (stiamo investendo R&D senza spendere in marketing strutturato; il riconoscimento, quando arriva, è derivato, non cercato)

È una scelta consapevole, non subita. Reinvestire nel prodotto significa che fra due anni il prodotto sarà diverso, magari migliore di quello che pagheremmo a un commerciale per vendere quello attuale. Significa anche che ogni trimestre dobbiamo dimostrare a noi stessi che la quota R&D ha prodotto qualcosa di tangibile: una nuova feature in produzione, un benchmark concluso, un’infrastruttura più solida. Se la R&D diventa una scusa per non lavorare sul delivery, il modello collassa nel giro di due trimestri.

Come misuriamo la quota R&D

Una nota tecnica per gli altri founder che ci seguono. Non abbiamo un sistema di time tracking enterprise. Usiamo una combinazione semplice:

• ogni issue su GitHub ha un label billable/internal/r&d e un’estimation in story points
• a fine sprint guardiamo il rapporto fra story points chiusi billable e r&d
• a fine trimestre incrocio le ore stimate con le entrate fatturate del trimestre per validare il rapporto

È un metodo da 5 persone, non scalerà a 50. Per ora basta. Quando cresceremo dovremo passare a un sistema più strutturato, e quel passaggio sarà a sua volta una voce di R&D infrastrutturale.

Quello che mi sono portato a casa

Prima. Una forchetta è più onesta di un numero. Dichiarare 50% sarebbe vendere un’astrazione che non esiste in nessun trimestre reale. Dichiarare 26% sarebbe sottovendere quello che effettivamente facciamo nei trimestri di alto investimento. La forchetta racconta la realtà.

Seconda. R&D in un’azienda autofinanziata non è discrezionale, è quello che resta dopo aver pagato gli stipendi e l’hosting. Questo significa che cresce solo se cresce il fatturato, e che ogni euro speso in R&D ha un costo opportunità verso assunzioni o commerciali. È una disciplina, non un lusso.

Terza. Le quattro voci (prodotto core, sperimentazione, infrastruttura, ricerca AI) sono interdipendenti. Tagliare la sperimentazione per dare tutto al prodotto core sembra razionale, ma toglie al team senior il contesto tecnico che lo tiene fresco. Tagliare l’infrastruttura per dare tutto al prodotto sembra razionale, ma il primo grosso incident in produzione costa più del risparmio. Sono trade-off non risolti, gestiti trimestre per trimestre.

Se siete una software house bootstrap che si chiede dove finisce il fatturato, spero questa scomposizione vi sia utile. Se invece siete un cliente che si chiede perché paga un canone a Romiltec, spero che vi sia chiaro che quel canone non sta finendo in dividendi: sta tornando in tecnologia, e prima o poi nel prodotto stesso che usate.