Piccolo studio o grande agenzia per un SaaS: quando conviene ciascuno

Scegliere tra un piccolo studio e una grande agenzia per un SaaS è una decisione sul perimetro del lavoro, prima ancora che sul fornitore. La chiudono tre risposte: quanti filoni di lavoro devono andare avanti in parallelo, quante persone devono approvare ogni decisione e cosa chiederà di dimostrare l'ufficio acquisti prima della firma. Le dimensioni del fornitore vengono dopo.

Qui per piccolo studio si intende un gruppo da 2 a 15 persone, in cui chi definisce il lavoro è anche chi lo progetta e lo sviluppa. Per grande agenzia si intende una struttura da 50 persone in su, con reparti separati per vendite, account, project management e delivery. Le realtà di medie dimensioni stanno nel mezzo e prendono qualcosa da entrambe. Se stai ancora decidendo tra uno studio e un singolo professionista, parti da agenzia o freelance per un MVP.

La risposta breve

Scegli un piccolo studio quando c'è un solo prodotto da progettare e sviluppare con un solo team, e vuoi parlare ogni settimana con chi ci lavora davvero. Scegli una grande agenzia quando il lavoro deve correre su quattro o più filoni in parallelo entro una data fissa, quando l'ufficio acquisti dei tuoi clienti chiede report di sicurezza e massimali assicurativi che il fornitore deve già avere, o quando serve copertura a ogni ora del giorno.

La prima versione di un prodotto web rientra nel primo caso. Un lancio su web, iOS e Android per una grande azienda, legato a una data che il consiglio di amministrazione ha già annunciato, rientra nel secondo.

Fianco a fianco: otto cose che cambiano con le dimensioni

• Con chi parli ogni settimana. Piccolo studio: il designer e lo sviluppatore che fanno il prodotto. Grande agenzia: un account o un project manager che riporta al team.
• Capacità in parallelo. Piccolo studio: uno o due filoni alla volta. Grande agenzia: molti filoni, con le persone assegnate tutte insieme.
• Approvazioni interne al fornitore. Piccolo studio: una o due persone. Grande agenzia: più livelli, per esempio delivery lead, responsabile QA e account director.
• Documenti per l'ufficio acquisti. Piccolo studio: dipende molto, e tanti non hanno né un report SOC 2 né una certificazione ISO/IEC 27001. Grande agenzia: spesso li ha entrambi, perché i clienti enterprise li chiedono.
• Dipendenza dalle persone chiave. Piccolo studio: alta, perché se va via una persona se ne va una parte grande della conoscenza. Grande agenzia: più bassa, perché i ruoli vengono coperti da altri.
• Cosa paghi in fattura. Piccolo studio: soprattutto ore di progettazione e sviluppo. Grande agenzia: account, PMO e QA compaiono come voci a sé.
• Avvio. Piccolo studio: può partire in poche settimane, e il limite è la capacità. Grande agenzia: parte più lentamente, ma una volta avviata aggiunge dieci persone in fretta.
• Ampiezza oltre il prodotto. Piccolo studio: product design e sviluppo, a volte il brand. Grande agenzia: aggiunge campagne, acquisto media, panel di ricerca e localizzazione su molti mercati.

Le dimensioni del team cambiano le probabilità di successo?

Le dimensioni del progetto sì, e i dati sono vecchi e coerenti. Fred Brooks ha mostrato in The Mythical Man-Month (1975) che le linee di comunicazione in un team crescono come n(n-1)/2. Cinque persone hanno 10 linee. Dieci ne hanno 45. Trenta ne hanno 435. Ogni linea è un punto in cui una decisione si può fraintendere o perdere tra due riunioni. Amazon ha costruito la propria organizzazione sullo stesso conto: AWS descrive i suoi team da due pizze come gruppi abbastanza piccoli da sfamarsi con due pizze, tenuti così per ridurre le linee di comunicazione e il peso delle decisioni.

Il CHAOS Report 2015 dello Standish Group ha misurato l'esito di 50.000 progetti software tra il 2011 e il 2015. I progetti piccoli sono andati a buon fine nel 61% dei casi. Quelli più grandi, la categoria che Standish chiama grand, nel 6%. I progetti piccoli gestiti con metodo agile sono falliti del tutto nel 4% dei casi. Standish ne trae una conclusione netta: alla maggior parte dei progetti software basta un team piccolo per un periodo breve.

C'è una precisazione che conta. Standish misura le dimensioni del progetto. Quelle del fornitore restano fuori dalla ricerca. Una grande agenzia può seguire un progetto piccolo con quattro persone. Un piccolo studio può accettare un progetto troppo grande per lui. I dati dicono di tenere piccolo il progetto. La scelta del fornitore viene dopo, e la risposta giusta è il fornitore la cui squadra tipica corrisponde al perimetro che resta dopo averlo ridotto.

Dove vince un piccolo studio

Un prodotto, un team, una roadmap

Un MVP, una prima versione a pagamento o il rifacimento di una web app sono lavori per un team da tre a sei persone. A queste dimensioni chi partecipa alla call commerciale è anche chi lavora sul codice. Una domanda fatta lunedì riceve risposta da qualcuno che il codice lo conosce, spesso in giornata, senza passaggi intermedi.

Design e codice che devono andare di pari passo

Quando il prodotto e il suo design system crescono insieme, ogni passaggio tra un reparto design e un reparto sviluppo è un'occasione perché i due si allontanino. In un piccolo studio le stesse poche persone disegnano la schermata e scrivono il componente, quindi una modifica a un token o a un pattern arriva in entrambi i posti nello stesso giro.

Budget in cui si vede ogni ruolo

Leggi l'elenco dei ruoli di qualsiasi proposta e conta quanti di questi disegnano schermate o scrivono codice. Su un budget di qualche centinaio di migliaia di euro, uno strato di coordinamento può assorbire una quota che preferiresti spendere sul prodotto. Un piccolo studio, per come è fatto, ne ha meno. Per le cifre, vedi quanto costa sviluppare un SaaS nel 2026.

Continuità dopo il lancio

Chi ha sviluppato la versione 1.0 è anche chi risolve la prima segnalazione di bug e rilascia la 1.1. Nessuno deve passare il sistema a un team di manutenzione che l'ha visto per la prima volta la settimana prima.

Dove vince una grande agenzia

Filoni in parallelo con una data fissa

Web app, due app native, una pipeline di dati e un sito marketing, tutti online per una fiera a marzo: sono cinque filoni da coprire nello stesso momento. Un piccolo studio dovrebbe metterli in fila, e mettendoli in fila salta la data. Un'agenzia da 80 persone può assegnare un team a ogni filone nella stessa settimana.

Un ufficio acquisti che chiede prove prima di cominciare

Le grandi aziende mandano spesso un questionario di sicurezza prima ancora del primo workshop. Alcune chiedono un report SOC 2, cioè un'attestazione secondo gli standard AICPA sui Trust Services Criteria, in cui il criterio Security è obbligatorio. Altre chiedono una certificazione ISO/IEC 27001, massimali assicurativi o bilanci certificati. Nei servizi finanziari l'asticella la fissa la legge: con il regolamento europeo DORA, in vigore dal 17 gennaio 2025, banche, assicurazioni e altri soggetti finanziari devono tenere un registro di tutti i contratti con fornitori di servizi ICT, e quei contratti devono prevedere strategie di uscita. Un piccolo studio può soddisfare questi requisiti. Se il tuo team di sicurezza vuole un report già pronto dal primo giorno, chiedilo prima della presentazione, perché per ottenerne uno servono mesi.

Reperibilità e sostituzioni

Un prodotto che deve rispondere a un incidente alle tre di notte di domenica ha bisogno di turni di reperibilità, e i turni richiedono persone. Una grande agenzia assorbe anche le uscite: quando qualcuno se ne va, subentra un collega con lo stesso ruolo.

Lavoro oltre il prodotto

Campagne, acquisto media, panel di ricerca in otto paesi, traduzioni in venti lingue. Quando il brief va molto oltre design e sviluppo, una grande agenzia può prendere il posto di diversi fornitori piccoli e del coordinamento tra loro.

Quattro domande prima di firmare

1. Quanti filoni devono andare avanti insieme nei prossimi sei mesi? Uno o due fanno pensare a un piccolo studio. Quattro o più fanno pensare a una grande agenzia, oppure a dividere il lavoro.
2. Cosa deve già avere il fornitore prima che l'ufficio acquisti firmi? Chiedilo ai team sicurezza e legale questa settimana, prima della shortlist. Un report mancante fa saltare un accordo tardi, dopo settimane di workshop.
3. Con chi parlerai ogni settimana, e quelle persone disegnano o scrivono codice? Chiedi i nomi nella proposta, poi chiedi di conoscerli. Nella nostra guida alla scelta di uno studio di product engineering trovi le domande da fare in quella call.
4. Se la persona di riferimento se ne andasse domani, cosa ti resterebbe? La risposta giusta è il codice in un repository della tua azienda, documentazione scritta e una clausola sulle persone chiave nel contratto. Le clausole da cercare sono in otto clausole da controllare nei contratti.

Si può dividere il lavoro tra un piccolo studio e una grande agenzia?

Sì, e i dati CHAOS vanno in questa direzione: Standish stesso consiglia di spezzare i programmi grandi in più progetti piccoli. Una divisione frequente affida il prodotto web principale e il suo design system a un piccolo studio, e le app native o la campagna a una struttura più grande. Il prezzo della divisione è l'integrazione. Nomina un solo responsabile per il contratto delle API e uno per i design token, e dai a ogni fornitore il proprio SOW sotto un contratto quadro, come spiegato in SOW e MSA. Una breve fase di discovery a pagamento è il punto più economico per tracciare quel confine.

Da che parte stiamo

Siamo un piccolo studio, quindi leggi questa sezione tenendolo presente. Prendiamo brief in cui un solo team progetta e sviluppa un prodotto e continua a seguirlo dopo il lancio. Quando un brief richiede molti team in parallelo entro una data fissa, o documenti che il tuo ufficio acquisti deve vedere dal primo giorno, lo verifichiamo nella prima call. Così entrambi risparmiamo un giro di proposte.