Team augmentation vs outsourcing completo: come scegliere per una software house

Il problema che si presenta ogni volta

Una software house italiana con 25 sviluppatori vince un appalto per un portale enterprise React + Node.js. Delivery entro 7 mesi, ma il team interno è già allocato su altri tre clienti. Il CTO ha due opzioni sul tavolo: ingaggiare due senior esterni che lavorano fianco a fianco col team (team augmentation) oppure affidare a un partner l'intero modulo back-end (outsourcing completo). Sceglie quella sbagliata — l'outsourcing completo — senza aver definito i confini delle API. Risultato: 11 settimane di riallineamento, una feature regression sul modulo auth e un cliente che chiede penali.

Non è un caso isolato. È il pattern più frequente che osserviamo nei progetti B2B complessi.

---

Cosa distingue i due modelli (sul serio)

Team augmentation

Aggiungi risorse esterne al tuo team esistente. Il controllo del processo, dell'architettura e delle decisioni tecniche rimane interno. Il partner fornisce persone — senior, mid, specialist — che operano nei tuoi tool, nei tuoi ritmi, nel tuo repo.

Quando funziona:

Hai una architettura definita e documentata
Il team interno può fare onboarding e code review
Il gap è di capacità, non di competenza specifica
I requisiti sono stabili o cambiano con preavviso

Rischi reali:

Se il tuo processo interno è caotico, esternalizzare persone lo amplifica
Il costo di coordinamento sale linearmente col numero di risorse aggiunte
La qualità dipende da quanto bene integri il contributor esterno nel tuo flusso

Outsourcing completo

Affidi a un partner un perimetro funzionale autonomo: un micro-servizio, un modulo, un'applicazione mobile. Il partner gestisce architettura, delivery, testing. Tu definisci i requisiti e validi gli output.

Quando funziona:

Il confine funzionale è netto e le interfacce (API, eventi, contratti dati) sono stabili
Il dominio è separabile dal core del tuo prodotto
Hai risorse interne per la governance e l'acceptance testing
Il partner ha già verticale sul dominio (es. sistemi di pagamento, OCR documentale, integrazioni ERP)

Rischi reali:

Scope creep silenzioso: i requisiti cambiano, il contratto non lo prevede
Dipendenza tecnica: se il partner sparisce, il codice è tuo o è un black box?
Assenza di integration testing end-to-end fino a tardi nel ciclo

---

I criteri di scelta: un framework in cinque domande

1. Il confine del lavoro da esternalizzare è definibile con un contratto di interfaccia?
   Sì → considera outsourcing completo
   No → team augmentation

2. Il tuo team interno può fare onboarding produttivo in meno di due settimane?
   Sì → team augmentation praticabile
   No → il problema è il tuo processo, non il modello di delivery

3. Il dominio richiede competenze che non hai e non vuoi acquisire?
   Sì → outsourcing completo con SLA tecnico
   No → team augmentation con profilo specializzato

4. I requisiti cambieranno più di una volta al mese?
   Sì → team augmentation (più flessibile al change)
   No → outsourcing completo (più efficiente su scope stabile)

5. Hai budget per governance interna (PM, tech lead) dedicata?
   Sì → entrambi i modelli sono percorribili
   No → team augmentation è meno rischioso

Nessuna delle cinque domande è sufficiente da sola. Servono tutte e cinque.

---

Un esempio concreto di architettura ibrida

Una software house che gestisce un SaaS HR ha adottato questo split:

Core del prodotto (motore regole, gestione buste paga): team interno + 2 senior in augmentation per accelerare il refactoring verso domain-driven design
Modulo notifiche (email, SMS, webhook): outsourcing completo a un partner con esperienza su event-driven architecture, interfaccia definita da un contratto OpenAPI + AsyncAPI
Mobile app (iOS/Android, Flutter): outsourcing completo con acceptance testing gestito internamente tramite Playwright su API mock

Il confine critico è sempre il contratto di interfaccia. Senza un OpenAPI spec versionato e testato, l'outsourcing completo diventa una bomba a orologeria.

# Esempio minimo di contract test con Pact (consumer-driven)
consumer: HRSaaS-Frontend
provider: NotificationService
interactions:
  - description: richiesta invio notifica email
    request:
      method: POST
      path: /v1/notifications
      body:
        type: email
        recipient: "user@example.com"
        templateId: "onboarding_complete"
    response:
      status: 202
      body:
        notificationId: "uuid-v4"
        status: queued

Se il partner non può rispettare questo contratto in CI, il problema emerge in settimana uno, non in settimana venti.

---

Gli errori più comuni che vediamo

Errore 1 — Outsourcing completo senza confini API stabili. Il team interno continua a cambiare i requisiti del backend. Il partner ri-allinea. Il costo esplode. La colpa viene attribuita al partner, ma il problema è il processo di discovery interno.

Errore 2 — Team augmentation senza onboarding strutturato. Il senior esterno passa tre settimane a capire il progetto da solo, senza documentazione, senza un buddy interno. Produttività nulla per un mese. La colpa viene attribuita alla risorsa esterna.

Errore 3 — Scegliere il modello in base al prezzo, non al contesto. L'outsourcing completo può sembrare più economico perché il costo è a corpo. Ma se il perimetro non è definito, il prezzo finale è imprevedibile.

Errore 4 — Mescolare i due modelli senza governance. Team augmentation e outsourcing completo possono coesistere, ma richiedono ruoli chiari: chi fa technical lead sul codice in augmentation? Chi fa acceptance sul modulo in outsourcing? Senza risposta, i conflitti di ownership paralizzano il delivery.

---

Take-away operativo

Prima di firmare qualsiasi accordo con un partner esterno:

Scrivi il contratto di interfaccia (API spec, schema dati, eventi) — anche una bozza. Se non riesci, il perimetro non è pronto per l'outsourcing completo.
Valuta la capacità del tuo team di fare onboarding. Se non hai un runbook del progetto, risolvi prima quello.
Scegli il modello in base alla stabilità dei requisiti, non al costo unitario.
Definisci chi internamente possiede la governance tecnica per ogni perimetro esternalizzato.

Il modello di delivery è uno strumento. Funziona solo se il contesto in cui lo usi è preparato a riceverlo.

---

Evviva Group supporta software house italiane con team augmentation e delivery white-label su perimetri definiti. Se stai valutando come strutturare il prossimo progetto, possiamo aiutarti a fare questa analisi prima di iniziare.