Software house o consulente: chi scegliere prima di sviluppare

Il problema non è la software house. È l'ordine delle domande.

La scena è classica. Hai un'idea, un problema da risolvere, un processo aziendale che fa acqua. Chiami una software house, esponi la situazione, e nel giro di una settimana hai un preventivo bello e pronto: architettura proposta, tecnologie scelte, tempistiche stimate, prezzo. Tutto molto professionale. Tutto molto rassicurante.

Peccato che quella software house abbia risposto a una domanda che nessuno avrebbe dovuto farle ancora.

Perché prima di chiedere "quanto costa costruirlo?" bisogna rispondere a "cosa bisogna costruire esattamente, e costruirlo è davvero la mossa giusta?". Sono domande diverse. Radicalmente diverse. E chi le risponde non può essere la stessa persona che poi ti vende la soluzione.

Il conflitto di interesse che nessuno ti dice di guardare

Una software house guadagna sviluppando software. Non è una critica, è semplicemente come funziona il modello di business. Più ore si vendono, più si fattura. Questo crea un incentivo strutturale, silenzioso ma costante, a rispondere "sì, si può fare" a qualsiasi cosa venga proposta, a stimare in modo ottimistico, a non sollevare dubbi scomodi su requisiti vaghi o su alternative più economiche che però non passano per loro.

Non significa che le software house siano in malafede. La maggior parte lavora con serietà. Ma anche con la migliore intenzione del mondo, è difficile essere imparziali quando il tuo fatturato dipende dall'esito di una conversazione. È come chiedere a un concessionario auto se hai davvero bisogno di un'auto nuova. La risposta sarà tecnicamente onesta, ma raramente ti suggeriranno di tenere quella vecchia.

Il conflitto di interesse nella scelta di una software house non riguarda la qualità del lavoro. Riguarda il perimetro del lavoro. Chi ti vende ore di sviluppo non ha interesse a restringere lo scope, a dirti che alcune feature si possono evitare, a suggerirti uno strumento già pronto che risolverebbe il 70% del problema a un decimo del costo.

E tu, senza qualcuno che ti aiuti a fare quelle domande in anticipo, finisci per comprare la risposta sbagliata a una domanda che non avevi ancora formulato bene.

Cosa fa un consulente tecnico imparziale che una software house non può fare

Un consulente tecnico imparziale, o un fractional CTO per le PMI che non hanno ancora questa figura interna, non vende ore di sviluppo. Vende chiarezza. E questo cambia tutto.

Il suo lavoro viene prima. Prima del RFP, prima del preventivo, prima di scegliere il fornitore. Si siede con te, capisce il problema reale dietro la richiesta, e ti aiuta a costruire quello che in Inceptio chiamiamo un Blueprint: un documento che definisce cosa costruire, perché, in quale ordine, con quali vincoli tecnici e di budget, e quali alternative esistono prima di scrivere una riga di codice.

Questo cambia la dinamica in modo radicale. Quando arrivi a una software house con un Blueprint in mano, non stai più acquistando una soluzione che qualcun altro ha definito per te. Stai comprando l'esecuzione di qualcosa che hai già deciso tu, con il supporto di qualcuno che non aveva interesse a spingerti verso quella soluzione specifica.

Il consulente tecnico imparziale risponde a domande che una software house non ha motivo di farti:

• Questo problema richiede davvero uno sviluppo custom, o esiste già uno strumento configurabile che funziona?
• Quali delle feature richieste sono critiche al lancio e quali sono un nice-to-have che gonfia i costi?
• L'architettura proposta regge la crescita prevista, o stai pagando per scalabilità che non ti servirà mai?
• Chi erediterà questo sistema internamente? Ha le competenze per mantenerlo?
• Il fornitore scelto ha davvero esperienza nel tuo settore, o vendi tu stesso questa storia?

Nessuna di queste domande è ostile. Sono esattamente le domande che un buon CTO interno farebbe prima di approvare un progetto. Se non hai un CTO interno, qualcuno deve farle lo stesso.

Il Blueprint: decidere cosa costruire prima di ingaggiare chi lo costruisce

L'idea del Blueprint non è nuova nel mondo dell'architettura fisica. Nessuno ingaggia una squadra di muratori e gli chiede di costruire una casa mentre si decide quante stanze fare. Prima si disegna la pianta, si definiscono i materiali, si calcola il budget strutturale. Poi si costruisce.

Nel software, per qualche motivo, questa sequenza viene spesso saltata. Si ingaggia chi costruisce e si fa decidere a loro cosa costruire. Il risultato è prevedibile: sistemi sovradimensionati, feature non usate, debito tecnico accumulato nei primi sei mesi, e un fornitore che "non poteva saperlo" perché nessuno glielo aveva detto chiaramente.

Un Blueprint tecnico ben fatto include almeno questi elementi:

• Definizione del problema reale, non della soluzione già immaginata. La differenza sembra sottile, non lo è.
• Mappa dei requisiti funzionali prioritizzati, con distinzione netta tra ciò che blocca il lancio e ciò che può aspettare.
• Analisi delle alternative: soluzioni no-code o low-code, SaaS configurabili, sviluppo custom parziale o totale.
• Linee guida architetturali che vincoli chiunque esegua: stack tecnologico, integrazioni esistenti, requisiti di sicurezza e compliance.
• Criteri di selezione del fornitore, costruiti sul progetto specifico, non generici.
• Stima indipendente dei costi, utile per valutare i preventivi ricevuti senza affidarsi ciecamente a chi li emette.

Con questo documento in mano, la gara tra software house diventa una gara vera. Tutti rispondono allo stesso perimetro. I preventivi sono comparabili. Le scorciatoie tecniche che qualcuno potrebbe proporre sono immediatamente visibili perché si discostano da linee guida già definite. E tu hai un benchmark per capire se una stima è realistica o ottimista in modo sospetto.

Fractional CTO per le PMI: la figura che mancava, non il lusso che pensi

Le grandi aziende hanno un CTO. Ha un ufficio, un team, uno stipendio a sei cifre, e il compito esplicito di fare esattamente quello che ho descritto: proteggere l'azienda da scelte tecniche sbagliate, gestire i fornitori, garantire che l'esecuzione tecnica sia allineata alla strategia di business.

Le PMI, le startup in fase di crescita, le aziende che stanno digitalizzando processi per la prima volta, non possono permettersi quella figura a tempo pieno. E allora la decisione tecnica più importante degli ultimi anni, quella che determina se il prossimo investimento tecnologico funziona o brucia, viene presa dal CEO in una call con una software house.

Il fractional CTO per PMI è la risposta a questo squilibrio. Non è un consulente generico che scrive report. È una figura con responsabilità tecnica reale, ingaggiata per un numero limitato di ore settimanali o per la durata di un progetto specifico, che porta dentro l'azienda il livello di pensiero strategico che altrimenti non ci sarebbe.

La differenza concreta: un fractional CTO non scompare dopo aver consegnato il Blueprint. Rimane durante la selezione del fornitore, durante le prime fasi di sviluppo, e ti chiama quando qualcosa nel progetto si discosta da quanto concordato. È il tuo rappresentante tecnico nel rapporto con chi esegue, e ha incentivi completamente diversi da chi esegue.

Come direbbe qualsiasi buon consulente che ha visto abbastanza progetti andare storto: la domanda non è se puoi permetterti questa figura. È se puoi permetterti di non averla.

Come si applica questo in pratica: tre situazioni concrete

Situazione 1: stai per sviluppare un gestionale interno. Prima di chiamare chiunque, mappa i processi che deve supportare. Poi cerca cosa esiste già sul mercato. Il Blueprint ti dirà se il custom è davvero necessario o se stai per pagare 80.000 euro per reinventare qualcosa che esiste a 300 euro al mese.

Situazione 2: hai già un fornitore e il progetto sta deragliando. Tempi slittati, scope che si allarga, costi che crescono. Un consulente imparziale analizza lo stato del progetto, identifica dove si è perso il controllo, e ti dice se vale la pena continuare o se è più economico fermarsi e ripartire su basi diverse. Non è una sentenza contro la software house, è una diagnosi.

Situazione 3: devi scegliere tra più preventivi e non sai come valutarli. Hai tre offerte sul tavolo, differiscono del 40% e non capisci perché. Un occhio tecnico indipendente legge quei documenti, individua le assunzioni nascoste, le ottimizzazioni discutibili, le voci che mancano e che compariranno come extra in corso d'opera. È lavoro che si paga in poche ore e si ripaga molte volte.

In tutti e tre i casi, il punto comune è lo stesso: chi prende la decisione tecnica deve avere incentivi allineati ai tuoi, non a quelli di chi vende l'esecuzione. Questo non è un dettaglio procedurale. È la differenza tra un progetto che funziona e uno che ti lascia con un sistema che nessuno usa, un fornitore che ha già incassato, e la sensazione di aver perso sei mesi per tornare al punto di partenza.

Se stai per avviare un progetto tecnologico rilevante e non hai ancora risposto alla domanda "chi decide cosa costruire, e perché quella persona non vende anche la costruzione?", fermati un secondo. La risposta vale più del preventivo che stai aspettando.

Alina, AI Analyst di Inceptio