Perché abbiamo detto NO a un cliente che voleva AWS

Nel B2B italiano dello sviluppo software esiste una regola non scritta: i clienti hanno sempre ragione sulla tecnologia che vogliono. Se chiedono AWS, fai AWS. Se chiedono Kubernetes, fai Kubernetes. Se chiedono una soluzione che tecnicamente non li serve, gliela costruisci comunque — e ti fai pagare il preventivo.

Per la maggior parte delle aziende di sviluppo è così, e ha senso commercialmente. Per noi, una volta, no.

Questo articolo racconta come è andata, perché abbiamo deciso di rifiutare un progetto da 90.000 €, cosa è successo dopo, e la regola interna che ne è scaturita. È un episodio di posizionamento aziendale che ci interessa rendere pubblico perché — confermato dai 14 mesi successivi — pensiamo sia il modo giusto di fare consulenza tecnica nel B2B italiano.

La richiesta del cliente

PMI manifatturiera del Nord Italia, 80 dipendenti, 35 M€ di fatturato. Ci contattano per modernizzare l’infrastruttura IT: server on-premise in fine vita, alcune VM Hyper-V, un gestionale di produzione custom .NET con SQL Server, sito istituzionale WordPress, dominio Microsoft 365 con 80 utenti, file server con 2 TB di documenti tecnici.

Il loro CTO, arrivato in azienda da 18 mesi, ci spiega da subito la sua posizione: “Vogliamo migrare tutto su AWS. È quello che usano tutti, è dove sta andando il mercato, ed è dove vogliamo essere fra cinque anni.”

Richiesta legittima. Pochi anni fa, l’avremmo presa, sviluppato il preventivo per i 5-6 workload da migrare, organizzato la roadmap in waves, gestito la migrazione con AWS Migration Hub. Capacità tecnica per farlo non ci manca. Avremmo fatto un buon lavoro su AWS — al netto di alcune sottigliezze su cui torneremo.

Il preventivo sarebbe stato attorno ai 90.000 € (assessment + migrazione + setup + supporto 12 mesi). Il cliente avrebbe firmato. Avremmo consegnato. Tutti contenti.

Non l’abbiamo fatto.

Cosa abbiamo trovato in assessment

Prima del preventivo, due settimane di assessment tecnico strutturato. Quello che abbiamo trovato non era allineato con la richiesta del CTO.

Stack già pagato in Microsoft 365: 80 licenze Business Premium, dominio configurato, Entra ID come identity provider, SharePoint come repository documentale, gestionale .NET integrato via Microsoft Graph per l’autenticazione utenti. Investimento storico nel ecosistema Microsoft: significativo e funzionante.

Licenze Windows Server e SQL Server on-premise con Software Assurance attiva: il cliente aveva pagato in passato licenze Volume Licensing con SA. Su Azure questa è la condizione di accesso ad Azure Hybrid Benefit — sconto del 40-55% sul componente licenza delle VM cloud. Su AWS lo sconto equivalente è molto più contenuto e con vincoli operativi più stringenti.

Latenza dall’Italia critica per il gestionale di produzione: 80 operatori in officina lavorano in tempo reale con barcode scanner che dialogano con il gestionale. Tolleranza alla latenza: max 50 ms round-trip. AWS in region eu-south-1 (Milano) copre il caso, ma alcuni servizi managed (database, AI services) all’epoca erano disponibili solo su region nord EU — 25-40 ms aggiuntivi che, in scenari peggiori, avrebbero richiesto architetture compensative o accettato una qualità di servizio sub-ottimale.

Compliance NIS2 in arrivo: il cliente, come molte PMI manifatturiere, sarebbe entrato in scope nel 2026. Residenza dati Italia esplicita, documentazione tecnica per audit ACN, integrazione con Microsoft Defender for Cloud — tutto disponibile su Azure Italy North con set di certificazioni AgID più completo della controparte AWS dell’epoca.

Team interno IT: due persone, entrambe con background Microsoft (Windows Server, SQL Server, qualche esperienza Azure). Zero esperienza AWS. Per gestire l’infrastruttura nuova sarebbero servite 6-12 mesi di formazione + certificazioni AWS, oppure dipendenza piena dal partner di sviluppo per ogni intervento operativo.

Nessuno di questi punti, presi singolarmente, era bloccante. Tutti insieme dicevano una cosa chiara: per questo cliente specifico, AWS non era la scelta tecnicamente migliore. Azure lo era.

Il calcolo TCO che ha aperto gli occhi

L’assessment includeva anche il calcolo TCO 3 anni sulle due ipotesi: AWS e Azure. Non come strumento commerciale — come strumento di onestà intellettuale.

I numeri, arrotondati:

Differenza: ~28.000 € su 3 anni a favore di Azure. Circa il 30% di TCO infrastrutturale in meno, prima ancora di considerare la qualità superiore di integrazione con Microsoft 365 / Entra ID già in casa.

Il calcolo non era una microspesa — era la differenza fra un’infrastruttura cloud sostenibile per i prossimi 3-5 anni e un’infrastruttura nuova che sarebbe stata oggetto di review entro 18 mesi per i costi non giustificati.

E qui è stato il punto di rottura interno.

Perché abbiamo detto NO

Abbiamo presentato l’assessment al cliente. Onestamente, con i numeri chiari. La nostra raccomandazione era esplicita: Azure è la scelta tecnica corretta per il vostro caso. AWS è una scelta valida in astratto, ma non per voi.

Il CTO ha mantenuto la sua posizione. Voleva AWS. Ha spiegato che le scelte tecnologiche di lungo periodo dovevano essere indipendenti dal vendor di produttività (Microsoft 365), che AWS gli sembrava più “neutrale”, che il team era pronto a formarsi. Comprensibile come posizione strategica.

A quel punto avevamo due opzioni.

Opzione A: fare quello che il cliente chiedeva. Preventivo da ~90.000 €, AWS, consegna in 6 mesi, supporto 12 mesi. Avremmo lavorato bene tecnicamente. Avremmo fatturato. Il cliente sarebbe stato — almeno apparentemente — soddisfatto.

Opzione B: rifiutare il progetto.

Abbiamo scelto la B. La motivazione: non saremmo stati in grado di difendere quel preventivo in coscienza verso noi stessi, verso il cliente, verso il mercato. Consegnare AWS quando Azure era oggettivamente meglio significava farsi pagare per costruire qualcosa che il cliente avrebbe poi pagato il doppio per mantenere e ottimizzare. Significava far passare il fatto che la nostra raccomandazione tecnica valeva zero quando il cliente premeva nella direzione opposta.

Il messaggio finale al cliente, parafrasato: “Crediamo che la vostra scelta tecnologica sia sbagliata per il vostro caso. Ve l’abbiamo dimostrato con i numeri. Se confermate la decisione AWS, è una scelta che rispettiamo, ma non ci sentiamo i partner giusti per implementarla. Vi consigliamo di rivolgervi a un altro fornitore con expertise AWS specifica per PMI italiane.”

Abbiamo riconsegnato l’assessment al cliente come deliverable autonomo, regolarmente fatturato (4.500 €), senza vincoli successivi. E ci siamo salutati.

Cosa è successo dopo (la parte che non avevamo previsto)

Quattro mesi dopo il cliente ha firmato con un’altra società che ha implementato AWS. Tutto regolare, nessun rancore da nessuna delle parti.

Quattordici mesi dopo l’abbandono iniziale, il CTO di quella PMI ci ha contattato di nuovo. La prima frase, riportata letteralmente con il suo permesso: “Avevate ragione voi.”

Cosa era successo nel frattempo:

• Costi infrastrutturali superiori del 35% rispetto al TCO Azure previsto nel nostro assessment, causa workload reali leggermente più alti del previsto + minore disponibilità di sconti Reserved sostenibili
• Latenza del gestionale di produzione su eu-south-1 accettabile ma con picchi superiori ai 50 ms in orari di rete satura, gestione complicata
• Team interno rimasto in modalità “operativa apprendista” su AWS, dipendenza forte dal partner di sviluppo per ogni intervento non standard, con costi di consulenza ricorrenti molto sopra le previsioni
• Nessun vantaggio tangibile rispetto allo stack Microsoft 365 che continuavano comunque a usare, e qualche attrito di integrazione (autenticazione utenti su due sistemi separati)

La richiesta del CTO era: ci aiutate a migrare da AWS ad Azure? Risposta: sì.

Lo abbiamo fatto. Migrazione in 7 mesi, costi totali aggiuntivi sostenuti dal cliente di circa 75.000 €, downtime in finestra contenuta. Oggi il cliente è su Azure stabile, in compliance NIS2, con il team interno autonomo sui task operativi quotidiani.

Il costo “psicologico” della migrazione doppia AWS → Azure non è uscito dalla porta. Il CTO ha gestito internamente il riconoscimento dell’errore strategico. E ha imparato — l’abbiamo verificato in conversazioni successive — che “la tecnologia che usano tutti” non è sempre la tecnologia giusta per la tua azienda specifica.

La regola interna SynSphere: quando rifiutiamo un progetto

Dall’episodio è nata una regola interna formale, che applichiamo in fase di pre-vendita su tutti i progetti di consulenza tecnica significativa. Tre criteri sequenziali. Se uno solo si applica, dichiariamo onestamente al cliente che non siamo il partner giusto e rinunciamo al progetto.

Criterio 1 — Non difendibile tecnicamente. Se l’assessment dice chiaramente che la scelta del cliente è tecnicamente inferiore a un’alternativa, e il cliente non accetta di rivedere la posizione, il progetto è “non difendibile”. Possiamo eseguirlo, ma non possiamo difenderlo nel tempo né verso il cliente né verso il mercato. Il caso AWS/Azure raccontato sopra rientra esattamente qui.

Criterio 2 — Vincolo etico o normativo. Se il progetto richiede di ignorare un vincolo normativo (GDPR, NIS2, FatturaPA), se trasferisce dati personali in giurisdizioni non conformi senza basi giuridiche valide, se costruisce capability AI che decidono su utenti senza DPIA quando necessaria — non lo facciamo. Costo per il cliente di scoprire dopo che era illegale: molto superiore al ricavo per noi.

Criterio 3 — Fuori dalle nostre competenze profonde. Se il progetto richiede expertise dove noi siamo “passabili” ma non eccellenti — esempio storico per noi: integrazioni SAP HANA on-premise, mobile gaming, blockchain enterprise — preferiamo dichiararlo e indirizzare il cliente a partner specializzati. Eseguiremmo male un lavoro che altri farebbero molto meglio.

La regola non si applica quando il cliente vuole semplicemente uno stack tecnologico mainstream diverso dal nostro consiglio per ragioni di preferenza, vincoli organizzativi, scelte strategiche aziendali che capiamo e rispettiamo. Nel caso AWS/Azure raccontato, se il CTO avesse detto “Capiamo che Azure costa meno, ma abbiamo deciso AWS per indipendenza di lungo periodo dal vendor di produttività” — quella sarebbe stata una scelta strategica difendibile, e l’avremmo eseguita senza problemi.

La regola si applica quando la scelta del cliente è oggettivamente subottimale per il caso specifico e il cliente non riconosce i tradeoff. Allora rifiutiamo.

Cosa significa per chi sta valutando un partner

Tre considerazioni rapide, per chi sta facendo procurement IT in una PMI italiana.

1. Le società che dicono sempre di sì sono raramente i partner giusti. Un partner di sviluppo che accetta tutto quello che chiedi senza mai metterti in discussione è un fornitore. Un partner che ti dice “no” quando serve è un consulente. La differenza fra le due cose si vede a 18 mesi dal go-live.

2. L’assessment iniziale è il vero deliverable di pre-vendita. Un partner serio ti consegna un assessment con calcoli onesti anche se questo significa raccomandarti una tecnologia che lui non implementa. È il singolo segnale più affidabile di onestà professionale che esista nel B2B IT. Vedi anche Scegliere un partner di sviluppo: 15 domande pre-vendita per le altre domande chiave.

3. La trasparenza commerciale è un asset competitivo. Lo abbiamo applicato anche pubblicando il configuratore software su misura — il primo nel mercato italiano dello sviluppo. Lo applichiamo nel confronto Azure vs AWS raccomandando esplicitamente Azure per la maggior parte delle PMI italiane, riconoscendo onestamente i 3 casi in cui AWS resta la scelta giusta. Lo applichiamo nei calcoli TCO/ROI che mettiamo a disposizione del mercato come framework riusabili.

Una PMI italiana ha più bisogno di consulenti onesti che di esecutori veloci. Il caso AWS/Azure raccontato sopra ci è costato 90.000 € di mancato fatturato nel 2024 e ce ne ha portati 75.000 € di fatturato reale 14 mesi dopo. Il vero ritorno è stato un altro: la fiducia di un cliente che ha imparato a chiamarci prima delle decisioni strategiche IT, non dopo.

CTA

Se sei un decision-maker PMI che sta valutando una decisione cloud, infrastrutturale, di sviluppo software — e vuoi un secondo parere onesto prima di firmare:

• Assessment tecnico: scrivici dalla pagina contatti. Il primo colloquio è sempre gratuito; un assessment formale con TCO comparativo costa 1.500-4.500 € a seconda della complessità, e te lo consegniamo come deliverable autonomo riusabile anche se non lavori con noi.
• Confronti tecnologici: per le decisioni più frequenti abbiamo già pubblicato i confronti — Azure vs AWS, Custom vs SaaS, In-house vs partner esterno, Power Apps vs .NET full custom.
• Range di prezzo: per stime indicative su software custom, il configuratore è online e gratuito.

Se cerchi un partner che ti dice sì sempre, non siamo noi. Se cerchi un partner che ti dice no quando serve, allora ci troviamo.