Se sai già cosa deve essere costruito, una software house o un freelance possono essere la scelta giusta.
Se invece hai ancora soprattutto un'idea, non sai quale architettura serva, non riesci a valutare un preventivo o temi di dipendere completamente da chi dovrà venderti lo sviluppo, può avere senso inserire prima una figura tecnica indipendente.
Non esiste un fornitore universalmente migliore. Esiste il ruolo giusto per la fase in cui ti trovi.
E nel 2026 c'è una domanda in più da fare: non soltanto chi scriverà il codice, ma chi prenderà le decisioni tecniche mentre quel codice viene scritto.
01 ·Prima domanda: in che fase sei?
Prima di scegliere qualcuno, prova a capire che tipo di problema devi risolvere.
Se dici:
"Ho un'idea per un'app, ma non so ancora bene quali funzioni servano, quanto possa costare e come debba essere costruita."
hai un problema di definizione.
Se dici:
"Ho scope, flussi, requisiti e architettura abbastanza chiari. Ora mi serve qualcuno che la realizzi."
hai un problema di delivery.
Se dici:
"Ho ricevuto tre offerte molto diverse e non so capire chi sia realmente competente, cosa manchi nei preventivi e dove rischio lock-in."
hai un problema di selezione e governance del fornitore.
Se dici:
"Il progetto è strategico, durerà mesi e mi serve qualcuno che continui a prendere decisioni tecniche durante la realizzazione."
hai un problema di direzione tecnica continuativa.
Sono quattro esigenze diverse. Affrontarle tutte con la stessa figura può funzionare, ma non è automatico.
Se sei ancora nella prima situazione, parti da: Ho un'idea per un'app: da dove partire prima dello sviluppo?
02 ·Quando ha senso un freelance?
Un freelance può essere un'ottima scelta quando il perimetro è chiaro e il lavoro è compatibile con una persona o con un piccolo gruppo di specialisti.
Per esempio:
- sviluppo di un'app circoscritta;
- una specifica integrazione;
- frontend o backend già definiti;
- una funzione specialistica;
- prototipazione tecnica;
- interventi su un prodotto esistente.
Il vantaggio è spesso una relazione diretta con chi lavora realmente sul progetto, una struttura più leggera e la possibilità di coinvolgere competenze molto specifiche.
Il limite non è "essere freelance". Il limite nasce quando il progetto richiede contemporaneamente competenze che una singola persona non può coprire con sufficiente profondità: UX, backend, mobile, cloud, sicurezza, DevOps, data engineering, AI, QA, compliance, gestione del progetto.
Un ottimo freelance che conosce i propri confini è molto più affidabile di un fornitore più grande che promette tutto senza avere realmente le competenze necessarie.
03 ·Quando ha senso una software house?
Una software house ha senso quando vuoi affidare a un unico soggetto una parte consistente della progettazione e della delivery.
Può mettere insieme più professionalità, organizzare il lavoro nel tempo, offrire continuità e assumersi una responsabilità realizzativa più ampia.
È spesso la scelta naturale per un prodotto che richiede:
- più sviluppatori;
- competenze frontend e backend;
- mobile;
- UX/UI;
- QA;
- DevOps;
- integrazioni;
- supporto dopo il rilascio.
Il fatto che una software house partecipi anche alla definizione del progetto non è un problema in sé.
Va solo riconosciuto che analisi e vendita della delivery sono nello stesso soggetto.
Questo significa che, se tu non hai sufficiente competenza tecnica interna, diventa più difficile distinguere tra:
- ciò che il progetto richiede davvero;
- ciò che il fornitore preferisce costruire;
- ciò che il suo stack rende più semplice vendere;
- ciò che viene incluso per ridurre il rischio del fornitore;
- ciò che invece manca dal preventivo.
La software house non è il nemico. Spesso è esattamente ciò che ti servirà.
La domanda è se sia già il momento di sceglierla e se sei in grado di valutarne la proposta.
04 ·Quando serve un consulente tecnico indipendente?
Serve soprattutto quando devi ancora definire cosa comprare o quando vuoi una valutazione tecnica che non dipenda economicamente dalla quantità di sviluppo venduta.
Può aiutarti a trasformare problema e obiettivi in:
- scope;
- flussi utente;
- requisiti;
- architettura target;
- integrazioni;
- decisioni build vs buy;
- roadmap;
- criteri di accettazione;
- ordine di grandezza economico;
- materiale utilizzabile per chiedere offerte.
L'obiettivo non è sostituire per sempre chi svilupperà.
È arrivare alla delivery con un progetto più definito e con la capacità di distinguere meglio una proposta solida da una proposta soltanto convincente sul piano commerciale.
Questo ruolo può anche concludere che non serva software custom, che lo scope debba essere ridotto o che prima vada validata un'assunzione.
05 ·Un CTO può aiutare anche a scegliere il fornitore?
Sì. Ed è uno dei punti più sottovalutati.
Una figura tecnica senior dalla parte del cliente non serve soltanto a produrre diagrammi di architettura. Può valutare se il team che hai davanti possiede davvero le competenze necessarie per assumersi la responsabilità del progetto.
Non significa fare un esame accademico ai fornitori.
Significa riuscire a capire se sanno:
- spiegare le decisioni tecniche che propongono;
- descrivere trade-off e alternative;
- individuare failure mode realistici;
- ragionare su dati e integrazioni;
- progettare sicurezza e permessi;
- definire una strategia di test;
- parlare di deployment e rollback;
- spiegare come osserveranno il sistema in produzione;
- gestire dipendenze e aggiornamenti;
- pianificare manutenzione e handover;
- riconoscere ciò che non sanno.
Una demo ben fatta dimostra che qualcuno è riuscito a costruire una demo.
Non dimostra automaticamente che sappia progettare, distribuire e mantenere un sistema affidabile.
06 ·Come riconoscere un fornitore tecnicamente solido
Una valutazione seria non dovrebbe basarsi soltanto sul portfolio o sulla qualità della presentazione commerciale.
Alcuni segnali utili sono molto concreti.
Sa fare domande prima di proporre soluzioni
Un buon fornitore non dovrebbe aver già deciso tecnologia e architettura dopo dieci minuti di call.
Dovrebbe voler capire utenti, flussi, dati, integrazioni, vincoli, requisiti di sicurezza, aspettative operative e incognite.
Sa spiegare perché propone una scelta
"Usiamo questa tecnologia perché la usiamo sempre" è una risposta diversa da:
"Per questo caso la sceglierei per questi motivi, accettando questi svantaggi."
La competenza emerge spesso dalla capacità di descrivere i compromessi.
Sa dire no
Chi promette ogni funzione, ogni deadline e ogni integrazione senza introdurre rischi o condizioni dovrebbe farti fare qualche domanda in più.
La seniority tecnica include la capacità di riconoscere limiti e incertezza.
Parla anche di ciò che succede dopo il codice
Testing, CI/CD, logging, monitoraggio, backup, rollback, sicurezza, manutenzione e documentazione non sono dettagli opzionali quando il sistema deve andare in produzione.
Il codice e la conoscenza restano trasferibili
Repository, accessi, account cloud, documentazione, dipendenze, procedure operative e decisioni architetturali non dovrebbero esistere soltanto nella testa del fornitore.
Se cambiare partner significa dover ricostruire tutto da zero, hai un problema di lock-in anche se il contratto dice che il codice è tuo.
07 ·E se il fornitore usa ChatGPT, Claude, Codex o altri coding agent?
Non è un problema.
Nel 2026 sarebbe anzi strano valutare la competenza di un team sulla base del fatto che usi o non usi strumenti AI.
Team molto competenti possono usare gli agenti in modo intensivo e ottenere più velocità, più test, più documentazione e cicli di delivery più brevi.
Il problema nasce quando l'AI non amplifica la competenza, ma la sostituisce.
La domanda quindi non è:
"Usate AI per programmare?"
La domanda è:
"Chi prende le decisioni e chi verifica che l'output sia corretto?"
Un team che lavora bene con agenti dovrebbe saper spiegare almeno:
- quali parti del lavoro vengono delegate agli agenti;
- quali decisioni restano sotto responsabilità umana;
- come viene revisionato il codice generato;
- quali test devono passare prima di integrare una modifica;
- come vengono gestiti segreti e credenziali;
- come vengono controllate dipendenze e vulnerabilità;
- come si evita che ogni task cambi architettura o convenzioni;
- chi approva modifiche a schema dati, API e component boundaries;
- come viene verificato il comportamento oltre l'happy path;
- come viene mantenuto il contesto tecnico nel tempo.
L'uso di un coding agent non è una red flag.
L'incapacità di spiegare perché il sistema è fatto in un certo modo può esserlo.
08 ·Perché l'architettura conta ancora di più con gli agenti
Quando produrre codice diventa più economico e veloce, aumenta il valore delle decisioni che guidano quel codice.
Se un team umano o agentico riceve soltanto:
"Costruisci un gestionale per X"
può generare rapidamente moltissimo software.
Ma ogni task può introdurre una nuova libreria, modificare un pattern, duplicare responsabilità, cambiare lo schema dati o risolvere localmente un problema senza considerare il sistema nel suo insieme.
Per questo una buona architettura target non dovrebbe essere una gabbia immutabile.
Dovrebbe essere un insieme sufficientemente chiaro di confini e decisioni che permetta a persone e agenti di lavorare senza reinventare il sistema a ogni iterazione.
Può includere:
- componenti e responsabilità;
- ownership dei dati;
- contratti tra servizi o moduli;
- API e interfacce principali;
- decisioni architetturali registrate;
- convenzioni di repository;
- dependency policy;
- security boundaries;
- strategia di test;
- Definition of Done;
- criteri di accettazione;
- deployment e rollback expectations;
- regole su quali decisioni richiedano approvazione tecnica.
In un processo agentico questo materiale diventa anche contesto operativo.
Non serve soltanto a spiegare il progetto a un fornitore. Serve a mantenere coerenza mentre il software viene prodotto rapidamente.
L'AI può accelerare enormemente la delivery. Non sostituisce la responsabilità tecnica.
09 ·Quali domande fare a una software house prima di affidarle il progetto?
Non servono cinquanta domande. Ne bastano alcune che costringano la conversazione a diventare concreta.
Per esempio:
- Quali sono secondo voi le tre maggiori incognite tecniche del progetto?
- Quali parti comprereste invece di sviluppare?
- Quali decisioni architetturali prendereste subito e quali lascereste aperte?
- Come gestite test automatici e code review?
- Come cambia il vostro processo se usate coding agent?
- Chi approva modifiche architetturali importanti?
- Come gestite CI/CD, staging, deployment e rollback?
- Come gestite logging, error tracking e monitoraggio?
- Quali account e asset restano intestati al cliente?
- Cosa consegnate alla fine oltre al codice?
- Come gestite dipendenze, aggiornamenti e vulnerabilità?
- Come rendete possibile un handover a un altro team?
- Quali elementi del preventivo dipendono ancora da assunzioni non verificate?
- Come gestite change request e variazioni di scope?
- Come definiamo insieme quando una milestone è realmente accettata?
Non esiste una risposta standard corretta.
Ti interessa soprattutto vedere se il team ragiona in modo coerente, riconosce i trade-off e sa assumersi responsabilità sulle proprie scelte.
10 ·Quando serve invece un Fractional CTO?
Una consulenza pre-sviluppo o una selezione del fornitore sono interventi puntuali.
Un Fractional CTO ha senso quando la necessità continua anche dopo la scelta.
Per esempio se:
- il progetto è strategico;
- durerà molti mesi;
- ci sono più fornitori;
- l'architettura continuerà a evolvere;
- ci sono integrazioni importanti;
- devi prendere continuamente decisioni build vs buy;
- servono revisioni tecniche periodiche;
- devi controllare qualità, rischi e debito tecnico;
- non hai internamente una figura senior che possa governare la delivery.
Il suo compito non è sostituire gli sviluppatori.
È mantenere una responsabilità tecnica lato cliente mentre la delivery procede.
11 ·Come scegliere quindi a chi rivolgerti?
Puoi usare questa regola semplice.
Hai ancora soprattutto un'idea?
Prima chiarisci problema, fattibilità e MVP.
Sai già cosa costruire e il progetto è circoscritto?
Valuta freelance o software house adatti al perimetro.
Hai più proposte e non sai quale sia tecnicamente solida?
Serve una valutazione indipendente del fornitore e delle condizioni tecniche.
La delivery sarà lunga e strategica?
Valuta una direzione tecnica continuativa.
Il percorso può quindi diventare:
Se stai ancora cercando di capire il budget, leggi: Quanto costa sviluppare un'app nel 2026?
12 ·Arrivare dal fornitore sapendo cosa chiedere
ContinDigital lavora dalla parte del cliente prima e durante le decisioni tecniche.
Con Idea & Product Feasibility puoi capire se vale la pena costruire e quale sia il minimo prodotto sensato.
Con MVP Blueprint puoi trasformare il progetto in scope, architettura target, roadmap, criteri di accettazione e materiale vendor-ready.
Quando arrivano le offerte, Vendor Governance serve a confrontare fornitori, architetture, costi, lock-in, condizioni tecniche e capacità reale di delivery.
Se il progetto richiede poi una guida continuativa, il ruolo può evolvere in Fractional CTO.