Perché una software house può fallire anche quando sa costruire software

Il primo problema: nessuno decideva davvero.

I ruoli formali esistevano. Sulle carte. Nei documenti. Nei verbali. Peccato che i poteri reali fossero un'altra cosa.

Le decisioni importanti non seguivano un processo. Non erano documentate. Non erano condivise. Venivano prese, subite, o peggio: rimandate.

Risultato: qualcuno lavorava, qualcun altro aveva la carica. Governance a puttane.

Quando i soci smettono di parlarsi, ogni altro problema diventa irrisolvibile.

Le comunicazioni importanti diventano sporadiche. Le richieste restano senza risposta. Le questioni si trascinano per settimane. Mesi. Anni.

Non servono cento dipendenti per avere problemi di governance. Bastano tre persone che non riescono più a dirsi le cose in faccia.

La parte amministrativa è diventata un pantano. Nessuno aveva una visione chiara di: quali clienti erano attivi, quali dovevano pagare, quali erano i costi ricorrenti, quali servizi erano davvero profittevoli, quanto valevano gli asset.

Senza questi numeri, ogni decisione è una scommessa. E noi le scommesse le perdevamo.

Un errore classico delle piccole aziende: confondere il fatturato con la sostenibilità.

• Un cliente che deve pagare non è liquidità.
• Un contratto non è margine.
• Un progetto che fattura non è un progetto che guadagna.

Tre cose che tutti sanno e che nessuno applica finché non è troppo tardi.

Anche i clienti hanno contribuito. Alcuni pagavano in ritardo. Altri chiedevano assistenza sproporzionata rispetto a quanto valevano.

Il problema non era il cliente che non pagava. Era il rapporto tra quanto entrava e quanto lavoro ci costava.

Per una software house piccola, un cliente da poche centinaia di euro l'anno può richiedere decine di ore di supporto, manutenzione, urgenze. A quel punto non è un cliente. È un costo con la faccia gentile.

L'infrastruttura era un altro punto debole. Domini, hosting, VPS, database, applicazioni, configurazioni diverse, tutte accumulate nel tempo. Nessuno standard.

App non containerizzate. Sistemi distribuiti ovunque. Roba che richiedeva manutenzione manuale per respirare.

Conseguenze:

• Non sapevi dove fosse ogni applicazione.
• I backup erano un atto di fede.
• Trasferire un servizio era un incubo.
• Documentare l'infrastruttura? Mai sentito.
• Ridurre i costi? Dopo.
• Intervenire in emergenza? Nel panico.

A un certo punto è stato necessario razionalizzare. Troppo tardi. Quando la situazione è già complessa, ogni sistemata è un intervento d'emergenza.

Il problema non era la capacità tecnica. Quella c'era.

Il problema era l'assenza di gestione strutturata. Si lavorava sulle emergenze. Non sui processi che le prevengono.

Progetti, tecnologie, configurazioni e codice scritti in momenti diversi, senza standard per deployment, documentazione, backup, monitoraggio, manutenzione.

Risultato: il tecnico è diventato anche sistemista, DevOps, supporto clienti e — ciliegina — l'unico che si ricordava come funzionava ogni singolo servizio.

Modello che regge per due clienti. Non scala. Mai.

Quando possiedi domini, server, applicazioni, database, account, contratti e clienti, queste informazioni vanno scritte da qualche parte. Altrimenti il valore dell'azienda vive nella testa di qualcuno. E la testa di qualcuno non è un asset aziendale.

Se quella persona sparisce — o semplicemente è in ferie — domande banali diventano impossibili:

• Questo dominio dove punta?
• Questo cliente su quale server è?
• Chi ha accesso a questo account?
• Come si fa il backup?
• Quale applicazione usa questo database?
• Quanto paga questo cliente?

Documentare non è burocrazia. È quello che rende i tuoi asset vendibili, manutenibili e valutabili. Senza, valgono zero quando serve qualcuno al volante.

La comunicazione si degrada in modo invisibile. Email senza risposta. Messaggi persi. Informazioni date a voce. Decisioni mai scritte.

E senza traccia, non sai più:

• Chi ha deciso cosa.
• Quando.
• Chi era responsabile.
• Cosa sapeva chi.
• Quali attività erano in giro.

Poi subentra la regola non scritta delle aziende piccole: "qualcuno deve farlo". E quel qualcuno è sempre la persona più disponibile. O più competente. O più cogliona, dipende dai punti di vista.

Così ti ritrovi con responsabilità operative senza nessun potere decisionale. Che è il modo più elegante di farsi sfruttare senza rendersene conto.

Nel tempo si prendono decisioni che, col senno di poi, non stavano in piedi. Succede.

La difficoltà vera è distinguere tra un asset e lavoro tecnico che serve solo a tenere in piedi la baracca. Domini, clienti, contratti, hosting, applicazioni — hanno un valore. Ma va analizzato, non dato per scontato.

Ridurre tutto a "quanto incassiamo di canoni" significa ignorare clienti custom, software proprietario, manutenzione, infrastruttura, know-how. E significa anche non accorgersi che i costi ricorrenti stanno mangiando i ricavi.

Quando te ne accorgi tardi, la razionalizzazione non è più una scelta strategica. È un'ambulanza.

Mettendo tutto insieme, questo è il cuore della storia.

Non è stato un singolo problema a far fallire la società. È stata una catena:

governance debole → comunicazione scarsa → amministrazione confusa → poca visibilità finanziaria → decisioni lente → problemi con i clienti → infrastruttura ingestibile → sovraccarico operativo → rapporti distrutti.

Ogni problema rendeva più difficile risolvere il successivo. E alla fine la società si è trovata in un punto dove continuare non aveva più senso.

Nessuno l'ha deciso. È successo. Come succedono quasi tutte le cose brutte in azienda: una piccola cosa alla volta.

La liquidazione non è la fine improvvisa. È il punto finale di un processo iniziato molto prima.

Prima si deteriora la collaborazione. Poi la governance. Poi la gestione economica. Poi l'operatività. Infine arriva il momento in cui devi ammettere che non ci sono più le condizioni.

La lezione è semplice, e fa male: puoi avere un prodotto tecnicamente valido e fallire lo stesso.

Puoi avere codice, clienti, competenze, idee buone. Ma se mancano governance, contabilità, comunicazione, processi e controllo finanziario, stai costruendo qualcosa che funziona sulla scrivania e crolla nella realtà.