Un team, una fattura: smettere di accumulare vendor SaaS

Il vendor sprawl è il lento accumulo di fornitori separati (un designer, un'agenzia frontend, un contractor backend, un freelance DevOps, più sei abbonamenti SaaS) che insieme dovrebbero consegnare un solo prodotto. La promessa è flessibilità. La realtà è che i founder passano più tempo a coordinare contratti che a spedire software.

Lo schema si vede subito. Un founder ingaggia un designer per il brand, un'agenzia per il sito marketing, un contractor per l'MVP, un altro studio per l'app iOS, e un altro contractor quando il primo sparisce. Sei mesi dopo, il lavoro è diviso tra cinque fatture, tre canali Slack, e zero persone che tengono in mente il quadro completo.

I numeri dietro al vendor sprawl

I dati sugli stack multi-vendor sono coerenti in tutti i recenti report di settore.

• L'azienda media usa 305 applicazioni SaaS secondo il SaaS Management Index 2026 di Zylo. Le aziende mid-market stanno tra 96 e 131 app a seconda del numero di dipendenti.
• Tra il 20% e il 30% delle licenze SaaS non viene mai usato o viene usato meno di una volta al mese, con il 15-25% della spesa software recuperabile in un singolo audit.
• Uno stack tecnologico frammentato può portare fino al 36% in più di costo totale di proprietà rispetto a uno unificato, in gran parte nascosto nell'overhead di integrazione.
• La consolidazione dei vendor di solito porta tra il 10% e il 20% di risparmio diretto nel primo anno, con tagli al costo del supporto IT che arrivano al 30% in tre anni.
• Il 95% degli IT executive intervistati nel 2025 ha dichiarato che la loro organizzazione sta pianificando una consolidazione vendor nei prossimi 12 mesi.

Per un'azienda SaaS di 20 persone che spende 200.000 € l'anno in tool e servizi, il budget recuperabile è tra 30.000 e 50.000 €. Più o meno un mese di engineer ogni anno, perso in coordinamento invece che in prodotto.

Perché la soluzione ovvia non funziona

L'istinto, quando lo sprawl diventa scomodo, è assumere un project manager che coordini i vendor. È la soluzione sbagliata. Un PM aggiunge un'altra fattura, un altro ciclo di meeting, e un altro layer di traduzione tra il founder e le persone che fanno il lavoro. Il PM è ritenuto responsabile della consegna ma non può cambiare gli incentivi di nessuno, perché ogni vendor continua a ottimizzare per il proprio scope.

La seconda soluzione sbagliata è consolidare verso una grande agenzia. Le agenzie risolvono il problema della fattura ma ne creano un altro: i senior partner vendono, lo staff junior consegna, e il founder finisce per pagare tariffe senior per un output che non sempre riflette giudizio senior. Ne abbiamo scritto in il pezzo sull'agency tax, dove il gap tra tariffa fatturata e seniority effettivamente consegnata è tipicamente del 20-40%.

La terza soluzione sbagliata è andare completamente in-house. Per un SaaS pre-Series-B, costruire un team prodotto completo (design, frontend, backend, DevOps, design system) assorbe 12-18 mesi di attenzione del founder prima che il team sia funzionante. La maggior parte dei founder non ha quella runway.

Cosa significa davvero un team con una sola fattura

Il modello studio collassa il lavoro di design, engineering e infrastruttura in un singolo team che opera su un solo statement of work, una sola fattura, un solo canale Slack. Il team è piccolo abbastanza da tenere l'intero prodotto in memoria di lavoro, e senior abbastanza che le persone che scrivono il codice sono anche quelle che prendono le decisioni.

Un contratto, uno scope

Lo studio firma un singolo accordo che copre discovery, design, build, setup infrastruttura e maintenance post-launch. Le modifiche di scope sono emendamenti allo stesso documento, non un nuovo contratto con un nuovo vendor. La review legale avviene una volta, non cinque. Per i founder che hanno passato un procurement aziendale, già solo il tempo risparmiato qui è significativo.

Una sola fonte di verità per le decisioni tecniche

Quando lo stesso team possiede il design system, il codice Next.js, lo schema Supabase e la pipeline di deploy, le decisioni smettono di rimbalzare tra vendor. Il team frontend non incolpa il team backend per una query lenta, perché loro sono il team backend. L'effetto cumulativo sulla velocità è la parte che sorprende di più i founder: feature che richiedevano tre sprint perché attraversavano tre vendor ora ne richiedono uno, perché attraversano zero handoff.

Una sola relazione commerciale, niente margini accumulati

Ogni vendor in uno stack multi-vendor aggiunge un margine. Uno sviluppatore subappaltato di solito costa 1,4-2 volte quanto costerebbe lo stesso sviluppatore ingaggiato direttamente. Quando un solo team gestisce l'intero stack, il founder paga un margine invece di tre o quattro. Il risparmio è spesso maggiore del project fee che inizialmente sembrava più alto della baseline freelance.

Una persona responsabile dell'outcome

Gli stack multi-vendor hanno una famosa modalità di fallimento: il bug che nessuno possiede. Il frontend punta all'API, l'API punta al database, il vendor del database punta alla rete, e tre settimane dopo il bug è ancora in produzione. Con un singolo team, l'escalation ha un solo indirizzo. La responsabilità non è finzione contrattuale, è realtà operativa.

Il problema shadow IT che la maggior parte dei founder sottovaluta

Il vendor sprawl non è solo un problema di fatture. È un problema di sicurezza. Il Cost of a Data Breach report 2025 di IBM ha trovato che il 35% delle violazioni coinvolge asset non gestiti o shadow, e il costo medio di una violazione ha raggiunto i 4,88 milioni di dollari a livello globale. Ogni vendor aggiuntivo è un set di credenziali in più, un pannello admin in più, e una superficie in più per il tipo di attacco supply-chain diventato routine dal 2024.

Gartner ha previsto che le organizzazioni senza gestione centralizzata del ciclo di vita SaaS saranno cinque volte più esposte a incidenti di perdita dati entro il 2027. Per una startup SaaS i cui clienti sono a loro volta enterprise con questionari di sicurezza, questo non è un rischio teorico. È un blocco di vendita.

Quando accumulare vendor è ancora la scelta giusta

Il modello studio non è sempre la risposta. Ci sono tre casi in cui lo stacking multi-vendor vince ancora.

Lavoro regolatorio specialistico. Compliance fiscale, consulenza legale, audit di sicurezza e certificazione di accessibilità sono meglio gestiti da specialisti di dominio. Uno studio che dichiara di fare tutto questo o subappalta in silenzio o non è qualificato.

Piattaforme consolidate con ecosistemi profondi. Se il prodotto gira su Salesforce, NetSuite o HubSpot, i vendor specializzati in quelle piattaforme sono di solito una scelta migliore di uno studio generalista.

Necessità geograficamente distribuite. Una startup statunitense che si espande in Giappone spesso ha bisogno di un partner giapponese per la localizzazione e l'UX market-specific, anche se il team prodotto core è consolidato.

Fuori da questi casi, il founder che sceglie un team e una fattura, nella nostra esperienza, spedisce più velocemente, spende meno, e dorme meglio.

Come si traduce in pratica

Un tipico founder SaaS con cui parliamo nella fascia seed-to-Series-A arriva con: un designer contractor, due sviluppatori backend di un'agenzia offshore, un consulente DevOps statunitense, sei abbonamenti SaaS core (Vercel, Supabase, Stripe, Linear, Slack, Notion), e un'agenzia marketing per il sito. Burn mensile totale di quello stack vendor: 18.000-25.000 €, senza una singola persona in grado di rispondere alla domanda sul perché la dashboard è lenta il martedì.

La consolidazione che proponiamo di solito: un team studio che possiede design, engineering e infrastruttura (una fattura, un project rate), gli abbonamenti SaaS esistenti rivisti e tagliati del 25-35%, e l'agenzia marketing tenuta perché fa lavoro specialistico che lo studio non fa. Il nuovo conteggio vendor: tre. Il nuovo burn mensile: circa il 30% più basso, con cadenza di rilascio misurabilmente più rapida.

Il punto non è che gli studio sono universalmente più economici di freelance o agenzie. Il punto è che accumulare vendor è il modo più costoso di costruire un prodotto, e la maggior parte dei founder ci finisce per default perché sembra il percorso più sicuro. Non lo è. È il percorso che accumula in silenzio costo e rischio mentre il founder è impegnato a rivedere fatture.