Come scegliere una software house per il suo progetto

Scegliere una software house è una decisione che pesa più del preventivo. Il partner che seleziona determinerà la qualità del prodotto, ma anche la facilità con cui potrà farlo evolvere tra due anni, cambiare fornitore o internalizzare lo sviluppo. Molti progetti falliscono non perché il codice sia scritto male, ma perché le aspettative non erano allineate, i requisiti erano vaghi o nessuno aveva chiarito a chi appartenesse cosa. In questa guida trova un metodo pratico per scegliere un'azienda di sviluppo software: come prepararsi, quali alternative esistono, quali domande fare, quali segnali d'allarme riconoscere e quali clausole contrattuali non vanno date per scontate.

Prima di cercare: chiarisca che cosa le serve

Il primo errore è iniziare dal fornitore anziché dal problema. Prima di contattare chiunque, metta per iscritto poche cose, anche in una pagina:

• Obiettivo di business. Che cosa deve cambiare grazie al software? Più ordini, meno lavoro manuale, un nuovo canale di vendita, un servizio per i clienti?
• Utenti. Chi userà il prodotto, da quale dispositivo, con quale frequenza?
• Funzioni indispensabili e funzioni rimandabili. Una distinzione netta tra ciò che serve al primo rilascio e ciò che può arrivare dopo riduce budget e rischio.
• Vincoli. Integrazioni con sistemi esistenti (gestionale, contabilità, magazzino), requisiti di sicurezza, scadenze legate a una campagna o a una stagione.
• Budget indicativo. Dichiararlo non la svantaggia: permette al fornitore di proporre un perimetro realistico invece di un preventivo che poi lievita. Se non ha ancora un ordine di grandezza, le nostre guide su quanto costa un sito web professionale e su quanto costa sviluppare un'app mobile mostrano come si ragiona.

Non serve una specifica tecnica. Serve una descrizione chiara del problema: un buon partner la trasformerà in requisiti e proposte, e la qualità di quella traduzione è già un primo criterio di valutazione.

Le alternative: freelance, software house, team interno

Non esiste una scelta giusta in assoluto. Dipende da dimensione, continuità e rischio del progetto.

Esiste anche una via mista: un partner esterno che avvia il prodotto e lo documenta, mentre un referente interno ne assume la titolarità. Funziona bene se il contratto prevede da subito passaggio di consegne, documentazione e accesso completo al codice e ai server.

Il punto non è se un freelance sia «meglio» di un'agenzia o viceversa: è se la persona o la squadra che ha davanti ha già risolto problemi simili al suo e se può garantirle continuità per la durata che le serve.

I criteri che contano davvero

1. Prove verificabili, non slogan

Chieda esempi concreti di lavori simili al suo, con una descrizione di che cosa è stato fatto e di quali scelte tecniche sono state compiute. Un portfolio serio spiega il problema, la soluzione e i vincoli, non si limita a mostrare screenshot. Per prodotti già pubblicati, può verificarli di persona: scarichi l'app, navighi il sito, ne controlli velocità e comportamento su telefono.

Diffidi di referenze che non può controllare e di numeri sbandierati senza contesto («aumento del 300% delle vendite») se non sono accompagnati da un'indicazione di come siano stati misurati. Un partner onesto distingue ciò che ha realizzato da ciò che è stato risultato del cliente.

A titolo di esempio, nella nostra sezione lavori descriviamo con il livello di dettaglio tecnico che riteniamo corretto progetti come Flash-Destock, un marketplace mobile per offerte lampo locali con pass QR e pannello per i commercianti, oppure Cachet, un'app per fatture e preventivi che funziona offline. Il metodo è quello da chiedere a qualsiasi fornitore: che cosa avete costruito, con quali tecnologie, e quali risultati sono misurabili.

2. Un processo chiaro

Chieda come lavorano, dalla prima analisi alla pubblicazione. Un processo maturo ha, in forme diverse, questi passaggi:

1. Scoperta e analisi: domande sul business, non solo sulle funzioni.
2. Proposta con perimetro definito: che cosa è incluso e che cosa no.
3. Rilasci intermedi: lei vede il lavoro avanzare, non solo alla fine.
4. Test: chi verifica, con che strumenti, su quali dispositivi.
5. Pubblicazione e passaggio di consegne: documentazione, accessi, formazione.
6. Manutenzione: chi risponde quando qualcosa si rompe, con quali tempi.

Se l'interlocutore non sa descrivere il proprio processo, o ne descrive uno identico per un sito vetrina e per una piattaforma con pagamenti, è un segnale da annotare.

3. Comunicazione e interlocutori

Con un team che lavora a distanza, come accade sempre più spesso anche per clienti italiani, la comunicazione è parte del servizio. Chieda in anticipo:

• chi sarà il suo referente e se resterà lo stesso per tutto il progetto;
• con che frequenza riceverà aggiornamenti e in che forma;
• in che lingua e in che fuso orario si lavora, e quali sono gli orari di risposta;
• come vengono gestite le richieste di modifica a progetto in corso.

Il lavoro a distanza non è un problema in sé: lo diventa quando non ci sono regole di comunicazione. Per un cliente italiano è ragionevole aspettarsi documenti, demo e riunioni nella propria lingua e ritmi di aggiornamento stabiliti per iscritto.

4. Competenze tecniche adatte, non la tecnologia di moda

Un buon fornitore le spiega perché propone una tecnologia, quali alternative ha scartato e quali sono i compromessi. Se il progetto è un sito di contenuti, una scelta come WordPress può essere la più sensata; se è un prodotto con logiche complesse, può servire sviluppo su misura. Ne parliamo in WordPress o sviluppo web personalizzato. Anche per le app la risposta cambia da caso a caso, tra nativo e multipiattaforma.

Un segnale positivo è un fornitore che, davanti a una richiesta, la mette in discussione con garbo: «Ha davvero bisogno di un'app, o basta un sito ben fatto?». Un segnale negativo è chi dice sempre sì a tutto.

5. Qualità: test, sicurezza, prestazioni

Domande utili e verificabili:

• Come testate il software prima del rilascio? Test automatici, test manuali, entrambi?
• Come gestite aggiornamenti di sicurezza e dipendenze?
• Come misurate le prestazioni del sito o dell'app? Quali strumenti usate e quali soglie considerate accettabili?
• Come vengono eseguiti i backup e quanto è semplice ripristinarli?

Non serve che l'interlocutore sia un ingegnere, ma deve rispondere con precisione, non con generalità.

Contratto e proprietà: ciò che si scopre troppo tardi

Molte controversie nascono da clausole mai lette. Prima di firmare, chieda per iscritto:

• Titolarità del codice e dei contenuti. Il codice sviluppato per lei diventa suo, oppure ottiene solo una licenza d'uso? Sono cose diverse, con conseguenze diverse se vuole cambiare fornitore. Chieda anche quali componenti di terzi o riutilizzabili sono inclusi e con quale licenza.
• Accesso a tutto. Repository del codice, hosting, domini, account degli store (App Store e Google Play), servizi cloud: devono essere intestati a lei, non al fornitore. È la verifica più semplice e più trascurata.
• Perimetro e variazioni. Cosa succede se le esigenze cambiano? Un contratto sano prevede come si valutano e si approvano le modifiche.
• Pagamenti legati a risultati. Un piano a tranche collegate a rilasci verificabili protegge entrambe le parti.
• Garanzia e manutenzione. Per quanto tempo il fornitore corregge i difetti emersi dopo la consegna? Che cosa è incluso e che cosa si paga a parte?
• Riservatezza e dati personali. Se il fornitore accede a dati di suoi clienti o dipendenti, tratta dati per suo conto. Il GDPR, all'articolo 28, prevede che il titolare si affidi solo a responsabili che offrano garanzie sufficienti e che il rapporto sia regolato da un contratto scritto, con l'obbligo di trattare i dati soltanto su istruzione documentata. Chieda quindi un accordo di nomina a responsabile del trattamento e informazioni su dove risiedono i dati.
• Uscita. Come avviene il passaggio a un altro fornitore? Documentazione, tempi di consegna del materiale, eventuale assistenza.

Per le questioni legali di dettaglio, si rivolga al suo consulente: qui interessa che le domande vengano poste prima, non dopo.

Segnali d'allarme

Alcuni comportamenti, da soli, non squalificano nessuno; in combinazione conviene fermarsi a riflettere.

• Preventivo molto più basso degli altri senza spiegazione. Capisca che cosa è stato escluso o stimato in modo ottimistico.
• Preventivo generico. Una cifra unica, senza elenco di attività, ipotesi e consegne, è difficile da verificare e da contestare.
• Pressione a decidere subito. Sconti validi «solo oggi» non si addicono a progetti che durano mesi.
• Nessuna domanda sul suo business. Chi inizia a parlare di tecnologie senza chiederle che problema vuole risolvere sta vendendo, non progettando.
• Rifiuto di nominare le tecnologie o di spiegare le scelte.
• Hosting, domini o account intestati al fornitore senza una ragione dichiarata.
• Garanzie assolute. Promettere il primo posto su Google o risultati certi di vendita non è una promessa che un fornitore serio possa mantenere.

Come confrontare le proposte

Chieda a due o tre fornitori la stessa cosa, con lo stesso materiale di partenza, e confronti le risposte con una griglia semplice.

Il prezzo più basso raramente è il più economico. Un costo iniziale ridotto può nascondere test assenti, documentazione mancante o un perimetro che si allargherà con varianti a pagamento.

Una prova pilota prima dell'impegno grande

Se il progetto è importante e il budget consistente, una fase di analisi o un piccolo prototipo a pagamento è un modo economico per conoscere il fornitore. In poche settimane vede come comunica, come stima, come gestisce i dubbi e che cosa consegna. Se la collaborazione funziona, il lavoro svolto non è sprecato; se non funziona, ha speso poco per scoprirlo.

È una pratica utile anche per progetti su misura complessi: un'analisi iniziale fissa il perimetro e permette di richiedere preventivi confrontabili per la realizzazione. Se vuole approfondire questo tipo di lavoro, trova una panoramica nella pagina sullo sviluppo di software personalizzato.

Dopo il lancio: la manutenzione fa parte della scelta

Un software non finisce alla consegna. Browser, sistemi operativi, librerie e servizi di terzi cambiano; senza aggiornamenti, anche un prodotto ben fatto invecchia. Quando valuta un fornitore, valuti anche chi lo manterrà.

Un esempio dal nostro lavoro: per Kachouri, un negozio tedesco di consegna bevande, la migrazione da Shopware 5 a WooCommerce con 812 prodotti ha portato il CLS mobile da 0,44 a 0. Il punto non è il numero in sé, ma il principio: le prestazioni si misurano e si correggono, non si dichiarano.

Chieda quindi:

• se esiste un contratto di manutenzione e che cosa copre;
• in quanto tempo vengono gestite le segnalazioni urgenti;
• se riceverà report periodici su aggiornamenti, backup e prestazioni;
• come si gestisce l'evoluzione del prodotto (nuove funzioni, nuove versioni degli store).

Checklist finale prima di firmare

• Il problema da risolvere è scritto e condiviso con il fornitore.
• Ho visto progetti simili e ho potuto verificarne almeno uno di persona.
• Il preventivo elenca attività, consegne, ipotesi ed esclusioni.
• Codice, domini, hosting e account degli store saranno intestati a me.
• Il contratto chiarisce proprietà intellettuale, garanzia e uscita.
• Se vengono trattati dati personali, è previsto l'accordo ex art. 28 GDPR.
• So chi sarà il mio referente e come si comunica.
• Sono chiari manutenzione e costi dopo il rilascio.

Domande frequenti

Meglio una software house italiana o una che lavora da remoto?

La nazionalità conta meno della capacità di comunicare, documentare e rispettare i tempi. Un team a distanza che lavora in italiano, con riunioni regolari e demo frequenti, può funzionare bene quanto uno locale. Conta che l'azienda sia trasparente su dove si trova, chi lavora al suo progetto e come si risponde in caso di problemi.

Quanto tempo serve per scegliere un fornitore?

Per un progetto medio, da due a quattro settimane tra raccolta delle proposte, colloqui e verifiche sono un ordine di grandezza ragionevole. Affrettarsi su questa fase tende a costare di più nel resto del progetto.

Conviene chiedere più preventivi?

Sì, due o tre, a condizione di inviare a tutti lo stesso materiale. Confrontare preventivi basati su informazioni diverse porta a conclusioni sbagliate.

Posso cambiare fornitore a metà progetto?

È possibile, ma costoso se codice, documentazione e account non sono in suo possesso. Per questo la proprietà e l'accesso vanno definiti prima di cominciare.

Che differenza c'è tra preventivo a corpo e a ore?

A corpo, il prezzo è fissato per un perimetro definito: dà certezza di spesa, ma richiede requisiti chiari. A ore, paga il tempo effettivamente impiegato: è flessibile quando i requisiti evolvono, ma richiede controllo e rendicontazione regolari. Molti progetti usano una combinazione, con un perimetro iniziale a corpo e le evoluzioni a ore.

Conclusione

Scegliere un partner di sviluppo software significa valutare competenza, metodo e affidabilità, non solo il prezzo. Parta dal problema, confronti proposte omogenee, verifichi i lavori precedenti e pretenda chiarezza su proprietà, accessi e manutenzione. Se vuole confrontarsi sul suo progetto, può scriverci: le faremo anche le domande scomode, perché è così che si evitano le sorprese. Se sta valutando un'app o un sito, trova le nostre pagine su sviluppo di app mobile e creazione di siti web.