Come scegliere un'azienda di sviluppo software?
Secondo Mesterséges Intelligencia Központ Kft., azienda di sviluppo software con sede a Budapest, una buona scelta dipende da tre domande: lo sviluppatore capisce l'obiettivo, la sua offerta è verificabile, e di chi saranno il codice e il sistema dopo la consegna.
In sintesi: descriva prima l'obiettivo e i requisiti irrinunciabili, e solo dopo chieda le offerte. Conviene chiedere di vedere lavori funzionanti, un processo trasparente e l'accesso al codice; le offerte vanno confrontate sulla stessa specifica voce per voce, possibilmente in base alla dimensione misurata. Nel contratto vanno fissati anche il codice sorgente e i diritti d'uso, la riservatezza, la correzione degli errori, la gestione e le modalità di uscita.
Prima l'obiettivo: che cosa deve saper fare il software?
La maggior parte delle scelte sbagliate non comincia dallo sviluppatore, ma da un incarico vago. Se non è scritto che cosa deve saper fare il software, ogni offerta significherà qualcosa di diverso, e non ci sarà nulla con cui misurare né il prezzo né il lavoro finito. Non serve una specifica già pronta (un buono sviluppatore aiuta a scriverla), ma conviene riflettere in anticipo su alcune cose:
- Obiettivo: quale problema risolve il software, e da che cosa si vedrà che ha avuto successo.
- Utenti: chi lo userà: collaboratori interni, clienti o partner.
- Requisiti irrinunciabili: ciò senza cui non può partire, tenuto separato dalle voci «sarebbe bello se».
- Sistemi esistenti: a che cosa deve collegarsi (ERP, CRM, negozio online, programma di fatturazione, banca).
- Dati: quali dati tratta, compresi i dati personali.
- Vincoli: se c'è una scadenza fissa, una regola interna, un requisito di hosting o di sicurezza.
Conviene anche decidere se serva davvero uno sviluppo su misura, o se basti un prodotto pronto, eventualmente un prodotto pronto insieme a un'estensione su misura. In questo aiuta l'articolo Software su misura o soluzione pronta (SaaS)?.
La rosa ristretta: chi conviene contattare?
Non serve contattare molte aziende; pochi candidati scelti con cura sono meglio di molte offerte superficiali. I criteri per restringere la scelta:
- Lavori simili: se ha già costruito un sistema di dimensioni e natura simili (software gestionale, negozio online, app mobile, integrazione dell'IA).
- Adeguatezza tecnologica: se lavora con le tecnologie a cui devono collegarsi i sistemi esistenti.
- Proporzioni: se la capacità dell'azienda è adatta al progetto; un sistema grande richiede più specializzazioni, un compito piccolo meno.
- Lingua e disponibilità: se è in grado di confrontarsi con la Sua azienda nella Sua lingua e nel Suo fuso orario.
Verificare lavori e referenze
La prova più forte è il software funzionante. Chieda ai candidati di mostrare un sistema che si possa anche provare, e di dire esattamente quale sia stata la loro parte. Molti lavori per i clienti sono protetti da riservatezza, perciò non sempre si possono fare nomi. In questi casi anche una descrizione anonimizzata, una dimostrazione o i prodotti propri dell'azienda dicono molto.
Se un committente precedente fornisce una referenza, conviene fare domande concrete: è stata rispettata la portata concordata, come sono stati gestiti le modifiche e gli errori, il committente ha ricevuto il codice sorgente, e lavorano ancora insieme? Un generico «siamo stati soddisfatti» dice poco; il fatto che il committente continui a gestire il sistema con loro anche dopo la consegna dice molto.
Il colloquio tecnico
Con ciascun candidato conviene tenere un colloquio tecnico, possibilmente alla presenza di un tecnico anche dalla parte della Sua azienda. Non conta la sicurezza con cui vengono date le risposte, ma se lo sviluppatore fa domande e se nomina i rischi. Buone domande:
- Come impostereste il lavoro, e quale sarebbe la prima fase?
- Come colleghereste i nostri sistemi esistenti, e che cosa dovete sapere su di essi?
- Come fate i test, e chi decide quando una parte è finita?
- Chi lavorerà al progetto, e chi sarà il nostro referente?
- Dove girerà il sistema, e chi è responsabile degli aggiornamenti di sicurezza?
- Se ci sarà anche intelligenza artificiale: quali dati finiscono dove, e che cosa succede se l'IA sbaglia?
È un segnale d'allarme se un candidato, senza fare domande, già dopo il primo colloquio indica un prezzo e una scadenza precisi.
Processo e comunicazione
Nello sviluppo software le sorprese nascono raramente nel codice, molto più spesso nella comunicazione. Per questo conviene chiedere come potrà vedere i progressi strada facendo. I segni di una buona pratica:
- Sviluppo per fasi: il lavoro è suddiviso in fasi, e alla fine di ogni fase viene mostrato software funzionante, non solo un resoconto.
- Accesso al codice: il committente vede il repository del codice fin dal primo giorno, non lo riceve solo alla consegna.
- Elenco delle attività tracciabile: attività, errori e modifiche sono visibili in un registro comune.
- Referente fisso: c'è una persona che conosce il progetto e può prendere decisioni.
- Gestione delle modifiche: l'esigenza nuova o modificata viene descritta, misurata o stimata, ed entra nel lavoro solo dopo l'approvazione.
Il confronto delle offerte
Due offerte si possono confrontare solo se riguardano la stessa portata. Per questo ogni candidato deve ricevere la stessa descrizione voce per voce, e conviene chiedere loro per quali funzioni e per quale dimensione hanno indicato il prezzo. Se lo sviluppatore misura la dimensione funzionale del software con un metodo standard, ad esempio in punti funzione COSMIC, la dimensione è verificabile partendo dalla stessa specifica; il metodo è presentato nell'articolo Che cos'è il punto funzione COSMIC?.
Se tra due offerte la differenza è grande, conviene chiedere:
| Domanda | Che cosa rivela |
|---|---|
| Per quale dimensione e per quali funzioni vale il prezzo? | se hanno prezzato la stessa portata |
| Che cosa compare come voce separata? | se sono compresi integrazione, migrazione dei dati, grafica, gestione |
| Di quali requisiti non funzionali hanno tenuto conto? | prestazioni, sicurezza, accessibilità |
| Come gestiscono le modifiche? | che cosa succede se strada facendo arriva una nuova esigenza |
| Come funziona la correzione degli errori dopo la consegna? | che cosa è compreso nel corrispettivo, e che cosa conta come lavoro a parte |
| Di chi sarà il codice sorgente, e quali diritti riceviamo? | se il sistema può essere portato avanti da qualcun altro |
| La fatturazione è a prezzo fisso o a consuntivo, in base all'impegno? | chi sopporta il rischio legato alla portata |
Il prezzo fisso funziona bene se la portata è fissata voce per voce; la fatturazione a consuntivo è più flessibile, ma il rischio legato alla portata resta al committente. In entrambi i casi conta che la portata sia misurabile e tracciabile. Come prezziamo noi lo descrive la pagina Prezzi.
I punti essenziali del contratto
Il contratto è ciò che conta in caso di controversia o di una situazione imprevista. Quanto segue è un'informazione, non una consulenza legale: conviene far esaminare il contratto anche da un avvocato.
Codice sorgente e diritti d'uso
La legge ungherese sul diritto d'autore (legge LXXVI del 1999, Szjt., in ungherese) tutela i programmi per elaboratore, sia in codice sorgente sia in codice oggetto, come opere dell'ingegno (§ 1, comma 2, lettera c)), e stabilisce che i diritti patrimoniali relativi al software sono trasferibili (§ 58, comma 3). Il committente, quindi, o acquisisce i diritti patrimoniali, o riceve un'autorizzazione all'utilizzazione (licenza); le due cose non coincidono.
Alcune regole per cui la formulazione precisa è importante: il contratto di licenza conferisce un diritto esclusivo solo se ciò è pattuito espressamente (§ 43, comma 1); se il contratto non indica le modalità e la misura dell'utilizzazione, la licenza è limitata a quanto indispensabile per lo scopo del contratto (§ 43, comma 5); se il contenuto non è univoco, va adottata l'interpretazione più favorevole all'autore (§ 42, comma 3); e il licenziatario può concedere una licenza a terzi solo con l'autorizzazione espressa dell'autore (§ 46, comma 1). Conviene quindi fissare:
- la consegna del codice sorgente completo e della documentazione, anche fase per fase;
- se il committente acquisisce i diritti patrimoniali, oppure quale licenza riceve, e di quale portata: esclusiva o no, modificabile o no, cedibile o no;
- che lo sviluppatore detiene i diritti sul codice scritto dai suoi collaboratori e subappaltatori;
- l'elenco e le licenze dei componenti open source e di terze parti utilizzati.
Riservatezza (NDA)
Se l'idea o i dati aziendali sono riservati, prima di entrare nei dettagli conviene stipulare un accordo di riservatezza (NDA). Vi indichi che cosa conta come informazione riservata, chi può conoscerla, quanto dura l'obbligo di riservatezza e che cosa succede ai materiali alla fine del lavoro.
Correzione degli errori e garanzia
Il contratto deve stabilire che cosa conta come errore (uno scostamento dal requisito concordato), come si svolge il collaudo, quali livelli di gravità esistono, e con quale rapidità lo sviluppatore reagisce a ciascun livello. Fissi anche per quanto tempo lo sviluppatore corregge gratuitamente gli errori rimasti nascosti alla consegna, e che cosa conta già come ulteriore sviluppo.
Gestione e SLA
Se lo sviluppatore gestisce il sistema anche dopo la consegna, le condizioni sono fissate da un accordo sul livello di servizio (service level agreement, SLA): la disponibilità garantita, le modalità di segnalazione dei guasti, i tempi di reazione e di risoluzione in base alla gravità, le finestre di manutenzione, i backup e i report. Ciò che non è scritto, in caso di controversia non si può pretendere.
Piano di uscita
Il piano di uscita risponde alla domanda su che cosa succede se non si prosegue con lo sviluppatore, che sia per insoddisfazione o perché lo sviluppatore cessa l'attività. I suoi elementi:
- documentazione aggiornata sull'installazione, sull'architettura e sulla gestione;
- il repository del codice, l'hosting, il dominio e gli account cloud intestati al committente, o almeno con accesso da parte del committente;
- le regole per la consegna delle password e delle chiavi di accesso;
- la possibilità di esportare i dati in un formato standard;
- la collaborazione nel passaggio di consegne a un nuovo sviluppatore.
Protezione dei dati: l'accordo sul trattamento dei dati
Se durante il lavoro lo sviluppatore ha accesso a dati personali (ad esempio perché gestisce il sistema o fa test con dati reali), ai sensi del GDPR di norma è un responsabile del trattamento, e con lui serve un accordo scritto sul trattamento dei dati (articolo 28 del GDPR). L'accordo deve stabilire tra l'altro che lo sviluppatore tratta i dati solo su istruzione documentata del committente, garantisce la riservatezza e la sicurezza, ricorre a un altro responsabile del trattamento solo con autorizzazione, alla fine del servizio cancella o restituisce i dati, e consente le verifiche.
Pratiche di sicurezza
La sicurezza non si può aggiungere al software in un secondo momento, perciò conviene chiedere come la gestisce lo sviluppatore. Un buon punto di partenza è l'OWASP Top 10, un elenco ampiamente conosciuto dei rischi di sicurezza più critici per le applicazioni web; l'edizione attuale è l'OWASP Top 10:2025 (verificato il 17 ottobre 2026). Ai primi tre posti ci sono il controllo degli accessi difettoso, la configurazione di sicurezza errata e i difetti della catena di fornitura del software. Chieda:
- Come gestite i permessi, e come verificate con i test che un utente veda solo i propri dati?
- Come aggiornate le librerie esterne che usate, e come venite a sapere se una di esse è vulnerabile?
- Dove conservate le password e le chiavi, e chi vi ha accesso?
- Fate la revisione del codice (code review) e i test automatici?
- Come vengono fatti i backup, e avete già provato a ripristinarne uno?
Freelance o azienda di sviluppo?
Entrambi possono essere una buona scelta; la questione è quanto è grande il compito e quanto a lungo vivrà il sistema.
| Criterio | Freelance | Azienda di sviluppo |
|---|---|---|
| Comunicazione | diretta, con una sola persona | tramite un referente, con più specialisti |
| Specializzazioni | le competenze di una persona | più specializzazioni: interfaccia, back end, mobile, gestione, test |
| Sostituibilità | in caso di malattia o di abbandono il lavoro si ferma | i membri del team possono subentrare l'uno all'altro |
| Capacità | per compiti più piccoli e ben delimitati | per sistemi più grandi, lavoro in parallelo |
| Contratto | direttamente con il professionista | con l'azienda, che risponde del lavoro del team |
| Gestione a lungo termine | dipende dalla disponibilità del freelance | si può garantire in modo organizzato |
Un freelance è adatto a un compito ben delimitato, soprattutto se il committente ha un proprio responsabile tecnico che dirige e prende in carico il lavoro. Se il sistema fa parte del funzionamento quotidiano dell'azienda, richiede più specializzazioni e resterà in esercizio per anni, l'azienda di sviluppo rappresenta di norma il rischio minore. Il piano di uscita e la consegna del codice sorgente sono ugualmente importanti in entrambi i casi.
Segnali d'allarme
- Prezzo e scadenza precisi già dopo il primo colloquio, senza domande.
- Nessuna specifica scritta, oppure un'offerta che non dice a che cosa si riferisce.
- Il committente non può vedere il codice, lo riceverebbe solo alla consegna.
- Una risposta vaga su chi lavorerà al progetto.
- Non è chiaro di chi sarà il codice sorgente e quali diritti riceverà il committente.
- Il rifiuto di firmare l'accordo sul trattamento dei dati o l'accordo di riservatezza.
- Nessun lavoro funzionante da mostrare.
Checklist
| Domanda | Va bene se |
|---|---|
| L'obiettivo e i requisiti irrinunciabili sono descritti? | esiste una breve descrizione compresa da tutti allo stesso modo |
| Abbiamo visto lavori funzionanti? | abbiamo provato almeno un sistema simile |
| Hanno capito il compito? | hanno fatto domande e nominato i rischi |
| Vedremo i progressi? | dimostrazioni per fasi, accesso al repository del codice |
| L'offerta è confrontabile? | si riferisce alla stessa portata voce per voce, e le voci separate sono visibili |
| La questione del codice sorgente e dei diritti è chiarita? | il contratto indica la consegna e la portata dei diritti |
| Ci sono l'accordo di riservatezza e l'accordo sul trattamento dei dati? | firmati dove necessario |
| La correzione degli errori e la gestione sono fissate? | livelli di gravità, tempi di reazione, SLA |
| C'è un piano di uscita? | documentazione, accessi, esportazione dei dati |
| Abbiamo chiesto della sicurezza? | risposte concrete su permessi, aggiornamenti, backup |
Domande frequenti
Freelance o azienda di sviluppo?
Per un compito ben delimitato e di dimensioni minori anche un freelance esperto può essere una buona scelta, soprattutto se l'azienda ha un proprio responsabile tecnico. Se il sistema fa parte del funzionamento quotidiano, richiede più specializzazioni e resterà a lungo in esercizio, l'azienda di sviluppo è il rischio minore, perché il lavoro non dipende da una sola persona.
Come confrontare due offerte?
Si possono confrontare solo offerte formulate sulla stessa specifica voce per voce. Chieda a entrambi gli offerenti per quale dimensione e per quali funzioni hanno indicato il prezzo, che cosa compare come voce separata e come gestiscono le modifiche. Se la dimensione è stata misurata con un metodo standard, ad esempio in punti funzione COSMIC, è verificabile partendo dalla stessa specifica.
Che cosa deve contenere il contratto?
La portata (la specifica voce per voce), il prezzo e la pianificazione, la consegna del codice sorgente e la portata dei diritti d'uso, la riservatezza, le regole del collaudo e della correzione degli errori, la gestione e lo SLA, il piano di uscita e, se sono coinvolti dati personali, l'accordo sul trattamento dei dati. Si tratta di un'informazione, non di una consulenza legale.
Che cosa succede se lo sviluppatore sparisce?
Se il codice sorgente, la documentazione e gli accessi sono presso il committente, un altro sviluppatore può prendere in carico il sistema. Per questo conviene vedere il repository del codice fin dal primo giorno, tenere l'hosting e il dominio a nome della propria azienda e fissare nel contratto un piano di uscita. Se mancano, portare avanti il sistema può essere difficile e lento.
Di chi sarà il codice sorgente?
Di chi ne ha diritto secondo il contratto: secondo la legge ungherese sul diritto d'autore i diritti patrimoniali relativi al software sono trasferibili, ma non automaticamente. Nel contratto conviene fissare che il committente riceve il codice sorgente completo e quali diritti esattamente acquisisce su di esso. Anche da noi il codice sorgente e i diritti d'uso sono regolati dal contratto.
Come possiamo aiutarLa?
Noi lavoriamo così: la prima consulenza è gratuita, scriviamo insieme la specifica, misuriamo la dimensione del software in punti funzione COSMIC e su questa base prepariamo l'offerta e la pianificazione. Lo sviluppo procede per fasi, con una dimostrazione alla fine di ciascuna; su richiesta firmiamo un accordo di riservatezza (NDA) e dopo la consegna ci occupiamo anche della gestione e della manutenzione. Il codice sorgente e i diritti d'uso sono regolati dal contratto. I passi sono descritti nella pagina Come lavoriamo, il metodo di determinazione del prezzo nella pagina Prezzi.
Attualmente stiamo sviluppando un grande sistema ERP e CRM; i nostri progetti, che si possono provare, sono presentati nella pagina I nostri lavori, sull'azienda si può leggere nella pagina Chi siamo, e alle domande frequenti risponde la pagina Domande frequenti. Se cerca uno sviluppatore, ci scriva ai recapiti indicati nella pagina Contatti.