Spotex SRL: Quattro soci, una software house e un solo collo di bottiglia

Per ragioni di privacy userò nomi fittizi. I ruoli, le quote e le dinamiche descritte restano però quelli che ho vissuto direttamente.

La società era composta da quattro soci:

• Andrea, CTO, con il 35%: sviluppo software, infrastruttura, assistenza tecnica, consegne e prodotti interni;
• Marco, CFO e presidente del consiglio di amministrazione, con il 35%: finanza, rapporto con il commercialista e presidio societario;
• Luca, COO, con il 15%: organizzazione operativa, coordinamento e rapporto con i clienti;
• Davide, indicato come CMO e talvolta come socio finanziatore, con il 15% attraverso una sua società: marketing, commerciale e supporto alla crescita.

A prima vista la struttura aveva una logica. Il problema non era l’assenza di titoli, ma la distanza tra i titoli e il lavoro che veniva effettivamente svolto ogni settimana.

In una piccola società, un ruolo non vale per come è scritto in un organigramma. Vale per ciò che succede quando arriva una scadenza, un cliente chiama, un pagamento è in ritardo, un server ha un problema o serve prendere una decisione scomoda.

Una giornata tipo non iniziava con una roadmap ordinata, un blocco di deep work o la costruzione tranquilla di un prodotto SaaS.

Iniziava con messaggi dei clienti. Richieste di modifiche. Ticket. Errori da riprodurre. Siti da aggiornare. Preventivi da preparare. Servizi da tenere online. Un cliente con una necessità urgente non aspetta che una piccola software house abbia messo in ordine le proprie responsabilità interne. Vuole una risposta. E quella risposta, quasi sempre, arrivava dal CTO.

Nel frattempo cercavo di sviluppare il prodotto che avrebbe dovuto cambiare il modello della società: un CMS proprietario. L’idea era semplice: smettere gradualmente di vivere soltanto di lavori su misura e costruire qualcosa di replicabile.

Ma quel prodotto non aveva un team dedicato, un budget dedicato, una roadmap protetta o una divisione reale del carico operativo. Veniva costruito tra un ticket e l’altro, tra una consegna e l’altra, tra un problema cliente e l’altro.

Dopo il lavoro tecnico arrivava il lavoro commerciale minimo necessario per non far morire l’attività: cercare potenziali clienti, rispondere ai contatti, capire se un progetto poteva sostenere cassa e costi. Poi tornavo ai clienti già acquisiti, perché un contratto non elimina manutenzione, supporto, aggiornamenti e richieste fuori perimetro.

E dopo tutto questo, la sera, iniziava il secondo turno: quello in magazzino, necessario per vivere. Quando finiva il turno regolare, ricominciava quello al computer.

Ci sono state notti in cui ho continuato fino alle tre. Altre fino alle quattro. Per poi alzarmi alle sette e andare di nuovo al lavoro.

Non è disciplina. Non è mentalità da founder. Non è sacrificio virtuoso. È debito di sonno trasformato in modello operativo.

Il problema non era lavorare tanto. In una fase iniziale, lavorare tanto può anche essere normale. Il problema era la natura del lavoro: non c’era una funzione che potesse assorbire il caos senza scaricarlo sempre sulla stessa persona.

Il CTO diventava contemporaneamente:

• sviluppatore dei progetti dei clienti;
• supporto tecnico e gestione ticket;
• manutentore di hosting, domini, database e applicazioni;
• persona che interveniva nelle urgenze;
• project manager di fatto delle consegne;
• interlocutore tecnico dei clienti;
• persona che cercava nuovi lavori;
• sviluppatore del prodotto proprietario che avrebbe dovuto far evolvere l’azienda.

Questa struttura ha un difetto enorme: può sembrare che funzioni finché la persona centrale riesce a compensare tutto. Poi, improvvisamente, ogni ritardo, ogni errore e ogni nuova richiesta dimostrano che non esisteva un sistema. Esisteva solo una persona che cercava di non farlo cadere.

Raccontare una situazione difficile in modo onesto significa anche riconoscere ciò che gli altri hanno fatto nei momenti in cui erano presenti e utili.

Nei periodi migliori, Marco inviava al commercialista gli estratti conto dall’app bancaria, così da permettergli di predisporre gli F24 dell’IVA, e provvedeva ai bonifici per pagare il commercialista. Era un’attività concreta e necessaria, anche se non bastava da sola a dare alla società una visione finanziaria completa e aggiornata.

Davide portò almeno un piccolo lavoro da circa 40 euro. L’importo era simbolico rispetto al fabbisogno dell’azienda, ma il punto non è ridicolizzare un singolo cliente: il punto è capire la sproporzione tra ciò che serviva alla struttura e ciò che effettivamente entrava con continuità.

Luca, nei suoi momenti migliori, contattava alcuni clienti al posto mio e cercava di organizzare le attività che dovevo svolgere. Era un aiuto reale: avere qualcuno che assorbe parte della comunicazione può alleggerire il tecnico. Ma organizzare il lavoro di una persona sovraccarica non equivale a creare capacità operativa aggiuntiva.

Il problema non era che nessuno facesse mai nulla. Il problema era che i contributi non erano abbastanza costanti, coordinati o proporzionati da cambiare il centro di gravità del lavoro. Il sistema restava dipendente da una sola persona per la maggior parte delle attività che facevano avanzare o sopravvivere la società.

Una delle dinamiche più logoranti era la distanza tra chiedere visibilità e contribuire a creare le condizioni perché il lavoro finisse.

Il CMS veniva chiesto come prodotto da commercializzare. Venivano richiesti test, aggiornamenti, dimostrazioni e verifiche. Si discuteva di logo, slogan, posizionamento e di cosa avrebbe dovuto vendere l’azienda.

Sono discussioni legittime. Branding, marketing e qualità del prodotto contano. Ma diventano tossiche quando vengono aggiunte sopra un sistema in cui chi deve costruire il prodotto è già sommerso da clienti, supporto, consegne e lavoro esterno.

Una domanda come “quando è pronto?” è utile solo se si accompagna a una seconda domanda: “cosa togliamo dal tuo carico per renderlo possibile?”.

Testare un lavoro può migliorarlo. Pressare continuamente una persona già al limite, invece, può soltanto frammentare ulteriormente il poco tempo che ha per finirlo.

Le riunioni periodiche avrebbero dovuto essere il momento per guardare l’azienda in faccia: clienti attivi, crediti da incassare, costi ricorrenti, spese previste, entrate, margini, scadenze fiscali, valore degli asset e priorità.

Troppo spesso, però, la fotografia economica si riduceva al saldo del conto corrente e alla difficoltà di ottenere aggiornamenti dal commercialista.

Il saldo bancario è un dato. Non è una strategia finanziaria.

Non dice quali fatture devono ancora essere incassate. Non dice quali costi arriveranno il mese successivo. Non dice quali servizi si possono tagliare. Non dice quali progetti stanno bruciando ore senza margine. Non dice quanto costa davvero un cliente che apre ticket continuamente. Non dice se un prodotto interno ha un budget o viene finanziato con notti insonni.

Senza una lettura completa, ogni decisione diventa reattiva. Si interviene quando arriva il problema, non quando i dati mostrano che il problema sta crescendo.

Avere quattro soci non significa avere quattro persone che sostengono l’azienda in modo equivalente. Le quote distribuiscono proprietà, diritti e potenziali risultati economici. Non distribuiscono automaticamente lavoro, rischio operativo, responsabilità quotidiana o pressione psicologica.

Questo è uno degli errori più pericolosi nelle piccole società tecnologiche: confondere l’organigramma con il sistema operativo reale.

Puoi avere un CTO, un CFO, un COO e un CMO. Ma se il CTO continua a essere l’unico che chiude le consegne, risolve le urgenze, parla con i clienti, tiene in vita l’infrastruttura e costruisce il prodotto futuro, gli altri ruoli non stanno creando una rete. Stanno ruotando intorno al collo di bottiglia.

La domanda che avremmo dovuto farci prima non era: “che ruolo vogliamo avere?”. Era: “quale risultato produce ogni ruolo, ogni settimana, senza che una sola persona debba ricordarlo, sollecitarlo o compensarlo?”.

Con il senno di poi, non credo che avrei risolto tutto lavorando più ore. Quello era esattamente il riflesso che dovevo smettere di avere.

Avrei imposto prima alcune regole semplici:

1. Un responsabile per ogni area, con output concreti e una frequenza di aggiornamento: vendite, finanza, clienti, infrastruttura, prodotto.
2. Un bilancio operativo mensile, non solo il saldo in banca: ricavi, crediti, costi ricorrenti, margini, ore spese, scadenze e cassa prevista.
3. Un perimetro di supporto clienti, con tempi, priorità e attività fatturabili, invece di trattare ogni richiesta come urgente.
4. Tempo protetto per il prodotto, finanziato e sottratto esplicitamente alla delivery per i clienti.
5. Documentazione di accessi, infrastruttura, contratti e responsabilità, perché il valore dell’azienda non resti chiuso nella testa di una persona.
6. Decisioni scritte, con responsabile, data e conseguenza se l’attività non viene svolta.
7. Una soglia di sostenibilità personale: nessun progetto dovrebbe richiedere che una persona lavori di notte fino alle quattro e poi inizi un secondo lavoro alle sette per restare in piedi.

Queste non sono regole da grande azienda. Sono regole minime per non fondare una società sul sacrificio invisibile di chi è più disposto a reggere.

Non penso che questa esperienza dimostri che le società con soci siano destinate a fallire. Dimostra però che un gruppo di persone non diventa un’azienda solo perché ha quote, ruoli e una visura camerale.

Un’azienda esiste davvero quando le responsabilità sono chiare, gli impegni sono verificabili, i numeri sono condivisi, i clienti hanno un perimetro, l’infrastruttura è documentata e il lavoro non dipende dall’eroismo di una singola persona.

Il punto più doloroso è che per un po’ Spotex ha funzionato tecnicamente. I clienti avevano servizi. I progetti venivano consegnati. Le urgenze venivano risolte. Il CMS cresceva.

Ma funzionava perché qualcuno compensava continuamente i difetti del sistema con il proprio tempo, il proprio sonno e la propria disponibilità. Nessun modello del genere dura davvero.

Oggi non voglio più costruire software in quel modo. Voglio costruire prodotti e sistemi che possano essere mantenuti domani, con confini più chiari, costi più leggibili, responsabilità più concrete e meno complessità nascosta.